Ys Utopia.net
Main => General => Topic started by: NightWolve on Apr. 19, 2006, 05:28:21 PM
-
Updated: XX/XX/2019!
The Demo Shots:
(https://www.ysutopia.net/images/TurboRip01.png)
(https://www.ysutopia.net/images/TurboRip02.png)
(https://www.ysutopia.net/images/TurboRip03.png)
(https://www.ysutopia.net/images/TurboRip04.png)
The Introduction:
I got the idea for this program some time after working on my translation
project for "Ys IV: The Dawn of Ys" and releasing the first patch. It was
based on many factors, one of them being that a project member was planning
on creating English dubs for the Japanese audio tracks used in the game. Now
to replace those audio tracks with English replacements, one would need to
rip their Ys IV disc in a special way. The required image format is what's
referred to as ISO/WAV/CUE. In this format, unlike formats such as CDRWIN's
BIN/CUE, Nero's NRG, or Alcohol 120%'s MDS, etc., every track file is ripped
to a separate file when dealing with a mixed mode CD (which is what all
PC Engine/TG-16 CDs are). This has many advantages, since audio tracks are
ripped to wave files, they can individually be compressed by special audio
compression programs to greatly reduce the storage space required.
So anyway, the purpose of this program is to rip/extract any PC Engine/TG-16
CD-ROM that you might have directly into an ISO/WAV/CUE image format. It
will guarantee the same size of every track file across all CD-ROM devices
because it will enforce the PRE/POST-GAP rules for transitions between track
types, something even GoldenHawk's CDRWIN program will not do, nor any other
professional software of that nature. I wanted a perfect extraction of every
track so every ISO and WAV file will come out to be the same size on every
machine out there. So eliminating size inconsistencies in ripping results is
another reason why I felt this program needed to exist.
While this program is intended for use with PC Engine/TG-16 discs, it can
also detect and rip MODE2/2352 discs such as CD-I/PlayStation ones. So it is
a general purpose command-line ripping program for various discs. But here's
the neat thing that makes it unique to PC Engine/TG-16 discs: This program
is compiled with a TOC Database of all PC Engine/TG-16 discs, so when you
insert an original PC Engine/TG-16 disc, it'll detect and verify its
authenticity and use the default title stored within to name the track
files. You'll see what I mean after you try the program and it correctly
names the image based on the disc you inserted.
So, what else can TurboRip do for you? It can produce an ISO/MP3 image
archive that is ready for use on Sony's PSP portable system with the PCEP
emulator or even X-BOX's Hugo-X emulator. If you have an audio CD, you can
just use the /mp3 parameter, set the bitrate and a few other controls, and
it'll rip just audio tracks. It should be faster than anything commercial
software has to offer for audio extraction to boot! I also added support for
the Monkey's Audio codec for lossless image backups too. If the initial
release of this application is well received by the community, I will add
support for more audio codecs such as OGG, and possibly FLAC.
Well, good luck, and do lemme know how this program works out for you!
- NightWolve
The Features/Change Log (really):
Version 1.42 (X/XX/2019):
+ Update: The basic /normalize feature was revisited and improved. The main
loop for processing a WAVE file was rewritten in pure x86 Assembly, the
volume multiplier precision was increased from a 4-byte float variable to
an 8-byte double, switched to faster float-to-int rounding, and even more
speed was achieved by skipping zero/null/silent 16-bit samples (an obvious
no-brainer, previously every 16-bits of a WAVE were read/written blindly).
+ Bug fix: The /xbox option produced a CUE file with wrong MP3 filenames...
Thanks to pceslayer @ PCEngine-FX.com forums for the bug report!
(The CUE format is matched to the old cddissect app by Xport which most
XBOX PCE emulators expect I figure, so that's what I used for reference.)
+ Bug fix: Compatibility improvements. More CD/DVD devices under Win7++ work!
Some Windows® 7 versions can't read CD data sectors using SPTI that lack an
an ISO9660 file system like all previous NT versions and the security level
varies... It's confusing, but I had to rewrite the function that reads data
sectors to try using the normal method of building a SCSI command packet
with the SCSI_READ10 (0x28) opcode first, and if that fails, try the
Microsoft SPTI method to let the OS mostly handle it. The prescribed SPTI
ReadFile() method is no longer enforced as other Windows® 7 builds required
AND it stopped working on PC Engine game CDs as they have no file system...
The other issue is the CD device rejecting opcode 0x28 to read data sectors.
As a result, I increased compatibility by adding the MMC1 0xBE opcode as a
3rd option when the other 2 fail! That newer opcode is used for reading
sectors raw, but by setting the appropriate flag in the command packet, it
will return only the "cooked" user data just as the READ10 opcode does.
Anyway, thanks to Chris Covell again for another bug report!
+ Bug fix: A 64-bit version of Windows® creates a separate registry view for a
32-bit app under the "Wow6432Node" key that prevented the "AllocateCDRoms=1"
string from being properly set. Thanks to ImgBurn for this tip/info! If that
registry value can be set, it may allow CD/DVD reading to occur under User
Rights, but you need to merge a .reg file with the contents below:
e.g. "CDReadRightsNT.reg"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"AllocateCDRoms"="1"
Note: Following investigation of virustotal.com and false virus flagging, I
no longer compile TurboRip to set this HKLM registry value to reduce 1 false
virus report, so I include 2 .reg files to do it yourself...
+ Bug: CTRL+BREAK/C not working 100% correctly (still fixing this...).
Version 1.41 (10/15/2016):
+ Update: New parameter option: /auto which simply scans all drives for the
first game CD detected in the TOC database and rips it without prompt! ^_^
Try: "/auto /turbo" for max, automatic ripping of the first Turbo CD found.
+ Update: New parameter option: /normalize which will auto-normalize/amplify
wave files afer ripping them. Given low preamp levels in some CDs making 'em
very hard to play loudly on your sound system, this will be useful to some!
+ Update: I switched to the TOC CDDB checksum standard for identifying game
discs. This reduced TurboRip's size by 200KB, and allowed me to use the much
quicker binary search algorithm to find a CD title whereas before I used a
basic linear search. This also prepares TurboRip for a future upgrade, to
look up the CDDB ID at www.freedb.org to conveniently title music discs.
+ Update: Alignment of 64KB SCSI buffer. Alignmask of CD/DVD drive processed.
Switched from dynamic memory allocation to static - this more guarantees no
memory fragmentation or trouble. I noticed more general stability this way!
+ Update: Error messages are now printed in red for fun, also some yellow is
used for status/info messages. :)
+ Update: MNKyDeth has an original copy of "Dungeon Master - Theron's Quest"
that wasn't in the PCE/TG-16 TOC database, so it appears another factory
pressing was discovered. I added it under its catalog/reference #TGXCD1041.
+ Update: Full [re]testing on Windows® 95/98/ME/NT4/2000/XP/Vista/7/8/10 was
performed to 100% verify TurboRip's compatibility, no assumptions this time!
+ Update: TurboRip now automatically centers its working CMD window.
+ Bug fix: Fixed total epic failure for Windows® 7 that required major rewrite!
TurboRip is now officially certified for Windows® 7 support even though I
said it was prior to this release without actually testing it on!!! :)
*Better trapping of SPTI errors after SCSI command packet sent.
*Using prescribed SPTI method for raw read of audio sectors - Win7 required!
*Using prescribed SPTI ReadFile method for data sector reads, the ONLY Win7
permissible way for MODE1 sectors due to security/policing of SCSI reads!
*Win7 security changes led to this!
Audio sectors - check!!!
Data sectors - check!!!
Thanks to johnnykonami for the bug report which also led me to do complete
genuine Windows® platform tests and find/fix the bug for NT 4.0 as well.
+ Bug fix: Setting thread priority to 'highest' on Windows® 95/98/ME caused
buggy input handling at the Command Prompt, sometimes even crashes! It took
hours of testing on Windows® 95 to figure this out, removed one unneeded
line of code to fix... Quite pesky...
+ Bug fix: Getting a SPTI CD/DVD drive handle on Windows® NT 4.0 (SP6) failed!
Now works both with User or Administrator Rights! Why bother making sure it
can work all the way back to such old Windows versions ?? Just because! :)
I started my software developer career on Windows® NT4 Workstations and it's
just nice to know that TurboRip can work on them. It lets me know the code
is simple enough and most appropriately makes use of the Windows API as well
as handle some of its quirks where one or two lines of code or flags can
make or break software between different OS versions.
+ Bug fix: Wrongly displayed US TurboGrafx CD type for Japanese PC Engine CDs.
This may have actually caused crashes for some people. Bug Report: It did!
tbone3969 @ PCEngine-FX.com reported crashing on his Windows 10 machine which
was subsequently solved by this fix! :)
Version 1.40 (8/7/2015 - 8/24/2015):
+ Uses the Native NT SCSI Library for NT/2K/XP/Vista/7/8/10 platforms! No more
dependency on an ASPI DLL and none of the problems associated with it!!!
+ Certified, tested, approved for use all the way back to Windows 98SE for the
"retro" in you, as well as all the way to the present with the new arrival
of Windows 10!!!! Even I find it hard to believe it works in all of them!!!
+ Improved skipping of unreadable data sectors near postgap area transition.
If you had trouble reading some PC Engine/TG-16 discs, this should help.
+ Major Command Prompt interface enhancement: TurboRip can now be fully run by
double-clicking it anywhere in Windows Explorer! The user no longer has to
first open a Command Prompt window and then CD to the folder where it is
located in order to enter parameters! User will be prompted for parameters
if none were detected when TurboRip is executed/double-clicked!! A troll on
the Ancient Land of Ys forums once barked, "How do you use this F#!K1NG!
PROGRAM?!?!?!?!" having never encountered command-line programs before and
not knowing how to first open a Command Prompt before using it... Short of
a future Windows GUI version, this enhancement solves that issue! Of course
you can't fix stupid nor those who couldn't bother to read instructions...
+ By request, the TOC CD-ROM data of NEC PC-FX videogames (50 out of 80) were
added to coincide with the release of the "Tyoushin Heiki Zeroigar" English
fan translation patch on 8/8/2015!! Only games such as Zeroigar (a shooter)
were added that "OBEY" the standard mixed-mode CD-ROM rules which can
accurately be ripped by TurboRip (The next version will have all 80!).
+ Added CD-TEXT support! Some music audio discs can have track file names and
other info such as artist, composer, genre, etc. burned into the "Lead-in"
area of the disc. Unfortunately, it's rare to find discs using this feature
because it arrived towards the end of the CD format's life, but I thought
I'd add support for it nonetheless! You still have CDDB of course. (You can
think of this feature as CDDB BTW, but that the album data/info is actually
burned into the disc so you don't need a program to do a CDDB look-up over
the Internet to obtain it.)
+ Added CD-EXTRA support! If your music audio disc carries an "Enhanced CD"
label, then it's really a multi-session disc that comes in three possible
forms, both with audio tracks and a MODE2 data track that can include music
videos, interviews with the band, whatever, etc. So, I've added support for
ripping the one format that I know of for now. I happen to have some of
these discs, so I wanted to make TurboRip work with them. Unlike with
CD-TEXT, music audio discs such as these are more common.
+ Various performance enhancements in interface, behavior, coding were made to
really make this app as great as it should be!! However, index/gap detection
by reading the "Q" subchannel failed to make it in this version. Stay tuned!
+ To reduce the size of TurboRip, all third-party components for MP3 (LAME)
and APE are now zipped within TurboRip and extracted/unzipped on demand.
+ When using the /APE parameter for perfect CD backups, support files are now
extracted to easily decompress APE files back to WAVE when needed! Simply
double-clicking the "APE_TO_WAVE.bat" batch file will do the trick!
+ The default 3.9.9.0 (2004) Monkey’s Audio (APE) codec no longer requires the
Unicode layer to work on Windows 98SE, so TurboRip fully works with both its
APE and MP3 codecs on a clean install of all Windows flavors!!! :)
+ Bug fix: I noticed on Windows XP that as TurboRip read sectors from a CD/DVD
drive connected via USB or FireWire, it could actually lose the connection!!
This could happen consistently when you ALT+TAB'ed to switch to another app!
I found the solution was to raise the Process Priority of TurboRip to HIGH!
Normally, disc burning software will raise the Process Priority to HIGH as
well when *burning* a disc which makes sense, and so with all that, I now
ALWAYS set TurboRip's priority to HIGH to avoid the bug with external drives
AND speed up the ripping time - it might as well live up to its name!! :)
+ Bug fix: Fixed a drive selection bug in Windows 98SE when selecting a drive
number from the prompt menu.
+ Fixed issue that caused "Linda ³ (J)" to be excluded from the TOC database.
Squaresoft74's use of the fancy superscript "3" was the culprit...
+ If all CD tracks are audio, it's a music CD (not videogame!) so messages
like "Note: No videogame CD-ROM was detected." were eliminated.
+ The track file-naming style was changed to put the track # (01-99) first.
This is better for sorting and viewing the CD image file set I think.
+ TurboRip no longer installs its own ASPI layer for Win9X/ME, it instead just
relies on the default Adaptec ASPI layer. Compatibility is still maintained!
+ TurboRip sets the TOP_MOST flag 'on' of the Command Prompt window so it can
never be hidden behind other windows until it is closed or minimized.
+ Bug fix: Fixed a minor bug that caused the /name parameter to be overwritten
when the last parameter specified was /useaspi or if any other text was
mistakenly typed at the Command Prompt.
Version 1.00 (4/19/2006):
+ Integration with the PC Engine/TG-16 TOC database so as to detect a valid,
original PC Engine/TG-16 disc if inserted, and warn you if not.
+ Can detect CD/DVD devices connected to your system via Firewire/USB!
+ Independent executable that provides its own copy of components if missing.
You'll only ever need the executable and not have to worry about other
missing dependent files as they'll be extracted on demand.
+ As of this release, LAME MP3 Library version 1.32 [Engine 3.98] (2/19/2006)
was compiled with the executable for all your MP3 encoding needs. If you have
a better/newer DLL, you can always replace LAME_ENC.DLL in the same folder
as the executable and it'll use that instead.
+ As of this release, MAC APE Library version 3.9.9.0 (2004) was compiled
with the executable for all your APE encoding needs. If you have a
better/newer DLL, you can always replace MACDll.dll in the same folder as
the executable and it'll use that instead. MAC=Monkey's Audio Codec is
lossless audio encoder. Use this if you want a perfect backup of your CD!
+ Can rip your disc directly into an ISO/MP3 format that is usable by PCEP
(a PC Engine/TG-16 emulator for Sony's portable PSP system) or HUGO-X (a
PC Engine/TG-16 emulator for Microsoft's X-BOX console system).
+ Generates a default reliable CUE file for use with Daemon Tools or any CDRW
burning software that supports CDRWIN's CUE format.
+ Generates a TOC dump in PCEP usable format.
+ Support for three data track modes (MODE1/2048, MODE1/2352, & MODE2/2352).
That means you could rip a game disc from other systems such as Sega CD,
NeoGeo CD, PlayStation, etc. PlayStation games can only be ripped in RAW
mode so your drive must support reading RAW sectors.
+ Code is highly optimized. The default VC++ runtime engine is not used.
Instead, I use a small custom runtime engine I prefer to compile with that
results in a much smaller and quicker executable, along with the fact that I
sacrifice ANSI portability by calling Windows APIs directly for speed gains.
+ I would argue TurboRip is probably faster than any audio ripper out there
when used to rip a regular audio disc. Many of the libraries commercial
software use are quite bloated while TurboRip was written with the bare
minimum of what's needed to read from a MMC-Capable device. Their advantage
of course is more compatibility with specific drives, etc. and support for
Jitter Correction if your drive isn't "CD-DA Stream Accurate." TurboRip
being command-line and not having to deal with controlling a Windows GUI
also provides a speed advantage.
+ Accurate track file sizes with 9X% of PCE/TG-16 CD-ROMs, ensuring consistency
in ripping results.
The Download: Latest TurboRip.zip (v1.42) (https://www.ysutopia.net/get.php?id=TurboRip)
Fully works now on Microsoft Windows 95/98/ME/NT4/2K/XP/Vista/7/8/10 believe it or not!!!! :)
>> For Windows VISTA or 7 and up Users, Download BETA Version <<
No need for that broken beta anymore I'm happy to say! Version 1.42 and on works on damn near every Windows version Microsoft ever released! :)
(Some past history on issues with old versions is below just for reference - ysutopia.net/forums/index.php?msg=3668 (https://www.ysutopia.net/forums/index.php?topic=69.msg3668#msg3668))
Feel free to leave feedback here and lemme know how it's working for you preferably with original CD-ROMs. If you have ideas for improvements/enhancements or find bugs, do lemme know! Keep on ripping! :)
Tracker URLs to other forums I posted this to check for feedback:
https://www.pcengine-fx.com/forums/index.php?topic=1604.0
http://forums.magicengine.com/en/viewtopic.php?t=1560
-
It's a great program. Nice to see it moved out of beta.
-
If anybody has a Sony PSP, try out the /pcep option to create an ISO/MP3/TOC archive for use with the PCEP emulator on that portable. That's something I can't test out, but last I checked, David Shadoff reported it works out fine for him.
Also, if you know of other pce/tg16 forums/communities, please spread the word. I'd like as many as possible getting their hands on this.
-
I have a PSP, unfortunately I also have upgraded the firmware (I wanted WPA. ::sniffle::) Has there been progress in homebrew so I can run this? And if so, where do I go? I'd be glad to try it out.
-
Another great job on another project. Keep up the great work. By the way is there any chance (since you brought it up) that we may yet see a Dawn of Y's patch with the dubs that someone was working one...thanks again and keep up the great work...
-OnImpulse-
-
TurboRip v1.00 works like a charm. Thanks, NightWolve. :)
-
By the way is there any chance (since you brought it up) that we may yet see a Dawn of Y's patch with the dubs that someone was working one...
-OnImpulse-
Beats me. I doubt it.
-
Very nice. I want to try this using the PCE PSP emulator next chance I get. I don't own one myself, but a friend was letting me borrow his for a bit. Perhaps next time.
-SkyeWelse
-
Hello NightWolve ^^ being as this is my first post ever i though ide say HI! Im looking at this new soft you made. but what I really wanted to know is how you edited the data on your ys IV patch? Im ive seen lots of ways to rip cd's to iso's including this here. Im looking to start a small group of fan translators myself and being as Im a video and sound editor/operator I can remake audio without a hitch. what I dont know is what I need to be looking for for recoding things in english text IE like your TGCD of ysIV ^_^ Im sure there is another forum about this somewhere I just cant find it so I hope you dont mind me posting this Q here. Thanks
-
Well, if you're talking about the text in Ys IV, it's compressed, so it would be beyond the scope of this post to explain how to "edit it." To edit data in general though, you start with a hex editor that can view S-JIS (Japanese text encoded with the S-JIS charset). Hexecute (http://www.zophar.net/utilities/hexutil.html) is one such editor. That helps with games when the text is not compressed. Beyond that, to make systematic updates across the whole data track programmatically, I made my own custom tools to insert blocks and update sections to achieve the desired results. Though, I can't really help you if this is your starting point, let alone one post with the query, "Um, how do you do it???"
Anyway, TurboRip will dump you a good image with all tracks properly sized, so you'll wanna use this for any hacking projects. You'll be certain that you're working with a properly sized data track which is important and were you to succeed in making a patch someday, it'll make it easier for your users to run TurboRip and then patch the results, etc.
-
I would argue TurboRip is probably faster than any audio ripper out there
when used to rip a regular audio disc.
I'd argue that too. Very handy program this has turned out to be.
-
I guess TurboRip is a success as there are multiple downloads of it daily server logs show. Unfortunately, I didn't get the level of feedback I was hoping for judging by this and all the other threads I made on some other NEC related boards. Oh well.
So far, I have at least one enhancement planned for the updated version BTW. There are special music CDs that carry an "Enhanced CD" label. These particular discs conform to a CD-EXTRA standard and currently will fail with TurboRip.
I happen to have a few and noticed the last audio track fails to be accurately ripped. Basically, they work by having two sessions, where the first is just the audio tracks, and the 2nd one has one MODE2 data track. Artists can include videos, interviews, shit like that. You've probably noticed you can access files when you insert these particular discs in your PC drive. Amazingly, by having the audio tracks in the first session, ALL (past and present) CD-ROM hardware will recognize them as regular CD-DA audio discs and ignore the last data track. Kinda neat. Full backwards compatibility with even the earliest of CD-ROM hardware out there.
Anyhow, I think I basically need to read the session number from the TOC and if it's 2, instead of 1 like a regular burned disc, I'll know it's a CD-EXTRA disc. But yeah, I will have to research a bit more to be sure what are all the factors/conditions to look for in order to accurately detect such discs. Obviously this enhancement doesn't have much to do with the application's "intended" purpose, but I'm picky like that and would like to make TurboRip handle what is likely a minor consideration that would make it work with these discs.
Well, it'll be a couple of months before I get to work on that, so no biggie. I did rather enjoy the 7 weeks I spent developing the current version I must say. It was a fun nerdy project for something purty cool. A GUI version down the road would be fun to work on also.
Alrighty, see you folks later.
P.S. One bug fix. Squaresoft's PC is French and he sent me his TOC files from it. For the game "Linda 3", he's using the superscript "3" character, which English/US machines don't appear to like. So what happened is Linda 3 was excluded from TurboRip's TOC database of PC-Engine discs unfortunately. I caught this problem last time for TocFixer, but he updated me again with all the TOC files and I missed it this time when I built TurboRip. So basically, TurboRip doesn't detect a Linda 3 disc. It's already been fixed, but a new release will have to wait for something a little more important like the CD-EXTRA enhancement I talked about.
I was also thinking about detecting CD-TEXT (if you've ever stuck a regular audio disc (CD-DA pure redbook, not MP3, etc.) in like your car's MP3/WMA/CD player and noticed that every track file showed the song title when played as well as the artist's name, that's via CD-TEXT support), but it's so rarely used in the music industry for audio discs, it's probably not worth the trouble. The CD-TEXT feature, like CD-EXTRA, produces an audio disc that is still backwards compatible with all old CD-ROM hardware, just that new hardware is able to detect the song title/artist name stuff per audio track. (I learned how to burn one myself in fact, then I went and tested it with a car stereo CD/WMA/MP3 player at Bestbuy -- which has them on display and operational -- to see if it would work. Heh.)
-
I still haven't had a chance to use TurboRip, otherwise I would have given you feedback :)
But, if I may, I would request that you retain the CD-Text feature! I think it is really kool! I know I may be in the minority... but if possible, keep it.
:)
I learned how to burn one myself in fact, then I went and tested it with a car stereo CD/WMA/MP3 player at Bestbuy -- which has them on display and operational -- to see if it would work. Heh.
Very, very kool. I am going to look up the history of CD-TEXT, do you have any juicy links that I might not find with an average search?
I am primarily interested in when CD-TEXT was introduced and what players support the feature. It sounds like CD+G to me ... a neat idea that was never really utilized. I know, you can laugh about CD+G, but I thought it was pretty kool back in the day (and I am still trying to find some CD+G music albums! All I have are a few samplers...)
-
Yeah with music CDs with the "enhanced CD" label, I always had to rip by individual track instead of the whole disc with another ripping program. I always thought CD-text was neat myself... but it just so rarely gets used.
-
But, if I may, I would request that you retain the CD-Text feature! I think it is really kool! I know I may be in the minority... but if possible, keep it.
Well, it's not actually supported right now. My thoughts in the previous post were about adding it later on when I get the chance.
I don't have much history on CD-TEXT really. It's a neat and slight enhancement they added later on so you could name every track basically. Certainly newer MP3/WMA recorded discs and players support that by default, but CD-TEXT lets you do it with a regular CD-DA recorded disc and it'll still work with older drives all the same as I mentioned.
Anyway, hurry up and try TurboRip already then. :)
-
I have tried to rip Seiya Monogatari a few times but it when the data track gets to 99.9%, it always says that there is an read error and closes yet there is not a singlt scrath on the disc. Any advice?
-
Thanks for the feedback.
Hm. Well, that's usually related to an issue with some drives having trouble reading the end of a DATA track right near the 2 second POSTGAP area that precedes an audio track. If it's detected as best as possible, you'll see this:
(https://www.ysutopia.net/forums/index.php?action=dlattach;topic=69.0;attach=101;image)
It's because an unreadable "POSTGAP area" is present due to a track type transition, such as DATA track to AUDIO track or the last DATA track and you have the transition to the "Lead-out." Now, no drive can read in the POSTGAP area, but unfortunately, I found that some drives will report a read error if you try to read one or two sectors right before where the POSTGAP area officially begins. That's been the problem. In essence, the unreadable POSTGAP area is slightly longer than the default of 2 seconds (150 sectors) for these drives.
Well, one thing to try is increasing the DATA read retry count. Add "/readretry=99" to the commandline along with any other parameters you're using. If that doesn't help, I wonder if I need to adjust how I detect being near the end of a DATA track based on the different behavior of your drive. I'd like to get in touch with you online through AIM or MSN if you're available to get more info and to have you try possible fixes with me. If you have another CD or DVD drive, using that instead would be a workaround to this, but I'm more interested in fixing the problem for the drive you're using of course. Just saying.
-
Anyway, hurry up and try TurboRip already then. :)
Well, as I mentioned in the other thread, the only PC I have to play with is Oldie. My wife won't let me touch her brand new laptop, unfortunatley.
Next time I'm home I'll give TurboRip a whirl :)
-
Hello NightWolve or anyone that can help...
I am using Turborip and am trying to use the PCEP option but the program just makes .wav files..
Any suggestions?
Thank you for this great program and for Turbofix!!!!!!!!!
The J Man
-
Howdy. Well, my first guess is you just haven't typed the parameter properly. Make sure you're using the forward slash. Example:
TurboRip /speed=max /pcep
The above command is all you need. You should then notice the MP3 library being extracted and loaded. Also, the files will be named in the following manner: 01.mp3, 02.iso, 03.mp3, etc. just as the PCEP emulator expects them to be.
I take it you didn't examine any of the example commands in the ReadMe??
-
Hello Again,
Before I posted I tried several times and only got .wav files using the examples in the ReadMe ex. TURBORIP /1 /PCEP. I also tried TurboRip /speed=max /pcep and TurboRip just closes. Any ideas? Thank you for your time!
Other combinations I tried
TurboRip /1 /speed=max /pcep (still produced .wav)
1 /pcep
Thank You
See attached pics
-
Got it working!!!!!
Thank you for the help!!!
-
How much people are there still ripping PcEngine Isos ? I wonder...
What about .ape encoding as a new feature ? :)
-
I have to say NightWolves TurboRip utility puts Cdrwin to shame.
-
Got it working!!!!!
Thank you for the help!!!
Yeah, hehe. I already saw the problem in your screenshot with you putting in the parameters too late, when prompted for just a drive letter. It's too late at that point as you've already started the program, and it's in the wrong place as you can clearly see I'm asking for a drive number, but you already figured that out... Congrats. You're not a commandline program kind of guy, eh? You gotta not be impatient and just read things clearly.
What about .ape encoding as a new feature ? :)
I wonder if anybody is taking advantage of its APE support.
-
I have for music CDs but not Turbo games...
-
I guess CDDB Internet lookups would be another feature to consider if it gets used a lot for music CDs to name the tracks. That would be an "extra-mile" feature to consider adding of course, way down the road.
-
I wonder if anybody is taking advantage of its APE support.
Oh god, it already does :-X
What about other consoles support ? (Sega Saturn, SegaCD,... what else ?)
-
Nightwolve,
Does the PCE CD format have zero pre/post gap for the data track when its the second track? The format looks very close to Yellow Book standard, except for the pre/post gaps.
Also, do know if a mixed-mode CD is the samething thing as Yellow Book standard with the data track being the first with no pregap? Shapeshifter appears to have the data track as the first track and I was wondering if it adhere'd to a legal Yellow Book format.
The reason I ask is that I trying to gather as much info on the PCE CD format before making rounds with the replication houses.
-Rich
-
Sorry for taking so long to reply but I got Snatcher yesterday (wow the music really sucks after playing the M-CD version for so many years :P ) and it too did the same thing so I am least relieved to know that it was not my Seiya Monogatari disc. I will try the 99 retry count and see what happens. Also, with the pre-gap problem, should it mention it in the error message? Because all it says is that there is an unreadable error. Thanks again.
-
Nope, same result :( It says "Read Error: Unrecovered read error"
Stupid piece of crap drive >:(
-
Oh god, it already does :-X
I thought you were joking. I could've sworn I tested the APE support with you before I released the first public version... But yeah, it's compiled with the latest APE DLL although it was a BETA version. It was new and releases are rare, so I went with that. All compression modes are supported and it works pretty much flawlessly.
What about other consoles support ? (Sega Saturn, SegaCD,... what else ?)
It does Sega CD, or should, same with PSX, maybe Saturn if it obeys default gap rules. Squaresoft tested for me and commented about this:
Dump any PC-FX, Saturn, PSX, Sega CD, etc.. disc, assuming its structure is respecting the pregaps rule that follows :
00:03:00 for a data track following an audio one.
00:02:00 for an audio track following a data one.
Since most NeoGeoCD games do NOT respect this rule, TurboRip in its current release is NOT suitable to make accurate Iso/Wav/Cue sets of these games.
So he knows for sure TurboRip is not suitable for use with Neo Geo CDs.
Does the PCE CD format have zero pre/post gap for the data track when its the second track? The format looks very close to Yellow Book standard, except for the pre/post gaps.
Also, do you know if a mixed-mode CD is the same thing thing as Yellow Book standard with the data track being the first with no pregap? Shapeshifter appears to have the data track as the first track and I was wondering if it adhere'd to a legal Yellow Book format.
OK, I assume you read what I put in the ReadMe concerning this? I'll paste it anyway:
When dealing with mixed-mode discs, TurboRip follows the
standard set forth by the industry as follows (verbatim from a MMC document):
**** 6.2.11.6. Pre-gap ****
If a Data track is preceded by a different mode of track (such as an audio
track) or if the mode number of CD-ROM changes, this Data track starts with
an extended pre-gap. A pre-gap is placed at the head of a Data track, also
is belonging to the Data track. A pre-gap does not contain actual user data.
The pre-gap is encoded as "pause."
An extended pre-gap is divided into two parts. The first part of the
extended pre-gap has a minimum 1 second of data, and it is encoded according
to the data structure of previous track. The second part has a minimum 2
seconds data, and this data track is encoded according to the same data
structure as the other parts.
**** 6.2.11.7. Post-gap ****
If a Data track is followed by another kind of track (such as an audio
track), this Data track ends with a post-gap. A post-gap is placed at the
end of a Data track, and is part of the Data Track. A post-gap does not
contain actual user data. The minimum length of post-gap is 2 seconds. The
drive does not perform any action for a Post-gap.
What this means is that if a Data track is followed by an Audio track, the
CUE file will have a "PREGAP 00:02:00" line to in effect cause a post-gap of
2 seconds for the prior Data track. If an Audio track is followed by a Data
track, you will see a "PREGAP 00:03:00" line. Now because I follow these
rules and assume the factory where the disc was burned/made follows them, I
will subtract off sectors accordingly to avoid these gap/pause sectors.
This is why TurboRip will work with a PC-Engine/TG-16 disc without errors.
Also, this general rule should apply to all mixed-mode discs as well.
OK, as far as I know, since MMC is a standard for getting CD/DVD devices to support universal commands and so forth, and alot of such documents actually pull info from things like the Yellow Book standard, I believe this particular 2/3 second rule for track type transitions is legal. Whatever the case, PC-Engine discs are complying with what I pasted above.
Now, lemme answer your questions directly. Your first question shows that some explaining is needed. Any "gap" is only needed when there is a transition of track types, either when you go from audio to data or from data to audio. So, if there is only one data track in the session for the disc, there is no pre/post gap that the CD maker has to account for. Notice when there are a series of audio tracks, one after the other, there is never a pre/post gap line. Only when there is a transition to another track type do we have to worry about gaps.
So, as to your 2nd question, since Shapeshifter starts with a data track, there is NO PREGAP line found in the CUE, because it's the first track and it did not follow an audio track. No forced gap is needed. Most any other PCE CD starts with an audio track, and THEN you have a transition with track 2, because it's a data track, a track of a different type. When you transition from AUDIO to DATA, you add a 3 second PREGAP, so that's why you see PREGAP 03:00 in that case, and you don't see it when the DATA track is the first track. Makes sense? Pregaps are only an issue when you're changing the track type, going from one to another. (There are only two types of course, audio and data.)
(Oh, one more thing, whether pregap or postgap, they're the same thing really. POSTGAP commands in CUE files weren't always supported well, but if you simply put a PREGAP line with the next track, that achieves the same thing as a POSTGAP with the prior track, so the result is the same. I imagine that's why CDRWIN only used PREGAP commands when creating its CUEs. I explained this in the last quote paragraph above btw.)
Well, this is where my research led me. You have to pay to gain access to the Yellow Book standard, while the MMC documents pre-ANSI approval are free which contain bits and pieces of what one might need. You want the good stuff you have to buy it from Phillips, ANSI, etc.
-
Nope, same result :( It says "Read Error: Unrecovered read error"
Stupid piece of crap drive >:(
Yeah, I needed the exact error message or a screenshot would've been better (and/or if you could paste everything from the DOS box here). Anyway, it seems your drive returns a different error message when dealing with this issue than my two drives. I can trap this particular error message as well and that would fix it, I guess. It will be included in the next release whenever that happens. In the meantime, I can give you a private copy to test with, but you must never share it as I don't want unofficial copies I might hand out in circumstances like these to spread since I haven't updated the ReadMe, version number, etc. Check you PM for a link and lemme know how it works out.
-
When you transition from AUDIO to DATA, you add a 3 second PREGAP, so that's why you see PREGAP 03:00 in that case, and you don't see it when the DATA track is the first track.
So the first 1 s of sectors in the pregap is audio mode(or previous track mode if not audio), followed by a 2 s pregap in data mode. Wouldn't this be a post-gap of 1 s on the preceeding audio track, followed by a 2 s pre-gap on the data track - by my assumption that pre/post-gaps are just sectors with blank data(0x00) in the data/audio part of sector?
I've burned a few test CD's without any pre-gap for the second data track following an audio track in the que, they booted fine in the SCD system. I wonder if NERO is adding/correcting the pre-gap before burning.
Also, I was looking at the ECMA-130 doc and it states that if a data track preceeds the lead-out, that no pre-gap is used. Do PCE games with a last track as a data track follow this rule?
Thanks for the info,
Rich
-
What about other consoles support ? (Sega Saturn, SegaCD,... what else ?)
It does Sega CD, or should, same with PSX, maybe Saturn if it obeys default gap rules. Squaresoft tested for me and commented about this:
Of course, but it can't recognize the name of such games. :P
-
This program is excellent for backing up PC-Engine and Turbo grafx/duo CDs ;) Audio CDs are also a plus. Other programs can do other types... I'm kind of paticuliar... for instance as much as Disc Juggler sucks, I prefer .cdi images for Dreamcast games.
-
So the first 1 s of sectors in the pregap is audio mode(or previous track mode if not audio), followed by a 2 s pregap in data mode. Wouldn't this be a post-gap of 1 s on the preceeding audio track, followed by a 2 s pre-gap on the data track - by my assumption that pre/post-gaps are just sectors with blank data(0x00) in the data/audio part of sector?
I don't quite understand your first statement to be honest. But a gap is supposed to be unburned/unreadable sectors, technically. However, burner software might burn blank zero data or even garbage as appears to be the case with PCE discs for the pregap of a data track following an audio track. The 2 second postgap of a data track preceding an audio track (or 2 second pregap of an audio track after a data track) appear to always be unburned/unreadable sectors for PCE discs.
So, for a standard PCE disc with the warning audio track, data track and one or more other audio tracks following it, I can read the whole first audio track. But, if I don't subtract off 3 seconds from the end, I'll hear garbage. The sectors are readable (I won't be stopped by the CD/DVD hardware when reading them with some error). Now if you look at those sectors, they appear to be garbage data sectors arranged improperly, not starting correctly, etc. On the other hand, if I try to read the whole data track, I will get a read error if I don't subtract off the 2 seconds for the postgap, which was added since a transition to another audio track is occuring.
I see what you were getting at, though, with the 1s + 2s making 3s of pregap for the audio to data transition. But yeah, seems with a PCE disc, all 3 of those seconds are readable. That is what I guess the quote from the doc I referred to calls an "extended pregap," but it just looks continuous. Since the TOC points to the data track right where it starts, it's conceptually better and technically a postgap, since this "gap" occurs at the end of the audio track. Anyway, I think you understand that calling it a pregap or postgap is relative to whose frame of reference you want to consider/value more, whatever.
I've burned a few test CD's without any pre-gap for the second data track following an audio track in the que, they booted fine in the SCD system. I wonder if NERO is adding/correcting the pre-gap before burning.
Well, that's understandable. But there are situations that will cause problems. The last data track in PCE discs has 3 seconds of zeros and I think a postgap of unreadable sectors is added when you burn the disc between it and the lead out. I burned an Ys IV disc without the last track. I found that when you fight the last boss, the last audio track was not played, instead another one was. Same problem with Dracula X. So, I found the solution was to add a POSTGAP 03:00 in the CUE file to fix the problem or readd the last backup track. So like for Ys IV, the CUE looks like this:
FILE "YS IV-THE DAWN OF YS (J-RIGG) [SUPER CD-ROM2]-31.WAV" WAVE
TRACK 31 AUDIO
INDEX 01 00:00:00
POSTGAP 00:03:00
Plus, with a PCE disc, sector starting offsets are important, so if you screw around and remove the proper pregap lines, all audio tracks will begin at a different offsets and when the game code attempts to play a particular track, it'll be off by however many seconds the pregaps are equal to, that is if the game doesn't crash... You'd be creating the MP3 problem basically.
Also, I was looking at the ECMA-130 doc and it states that if a data track preceeds the lead-out, that no pre-gap is used. Do PCE games with a last track as a data track follow this rule?
Ah, yeah, that was another handy doc I found as well. OK, if it says the last track then - since it's the last track that would precede a lead-out obviously - then no, because the last data track is usually preceded by an audio track, so the transition rule is followed and you'll see a PREGAP 00:03:00 line in the CUE file when you rip it. It's no big deal really, so I wonder if you read that correctly from the doc or I would guess the transition rule takes precedent. Anyway, it really only affects the 2nd-to-the-last audio track. If I rip that 2nd-to-the-last audio track, reading all its sectors, I'll get garbage noise for the last 3 seconds. Well, whatever.
-
Plus, with a PCE disc, sector starting offsets are important, so if you screw around and remove the proper pregap lines, all audio tracks will be at a different offset and when played, will be off by however many seconds the pregaps are equal, if the game doesn't crash. You'd be creating the MP3 problem basically.
Yeah, from the tests I've done, the audio track layout is very finicky. It appears the PCE/game is playing the audio based on the exact sector address instead of track number, but this doesn't appear to be the case with the data tracks. I have one CD were the first track(data) has a 47s +9frame pregap and the system is oblivious to it - all the sector addresses are based off index 01 for a data track (with index 00 containing the pre-gap), but the pre-gaps in the data track effect the LBA of the audio starting point to be played by the game.
Thanks NightWolve ;D
Rich
-
Hey NightWolf, I just found your old rigg web page for ripping PCE/DUO rom, which I want to thank you. I'm new to this, so can I only follow instructions of CDRWin step by step and other
information provided by authoritative guide to rippimg. Is this another
form of the turboripv.1.00 pc/tg16 cdrom iso/wav/cue. Are the command lines /programming needed to rip the roms. Can copy/back-up games
be played on turbo 16cd/duo system with modifications.
one more thing, devices/supported features is the cd+g always unchecked and the tracklist mode 1 is always number 2 and rest
audio
-
Is this another
form of the turboripv.1.00 pc/tg16 cdrom iso/wav/cue.
Huh?
Are the command lines /programming needed to rip the roms.
The "programming" has already been done. See the ReadMe file for instructions on using TurboRip.
Can copy/back-up games
be played on turbo 16cd/duo system with modifications.
A TurboGrafX 16 CD system or TurboDuo system does not need modifications.
one more thing, devices/supported features is the cd+g always unchecked and the tracklist mode 1 is always number 2 and rest
audio
Unchecked. Correct.
-
Yeah, from the tests I've done, the audio track layout is very finicky. It appears the PCE/game is playing the audio based on the exact sector address instead of track number, but this doesn't appear to be the case with the data tracks.
Right, the sector offsets of every audio track are hardcoded. The game code in most games does not dynamically fetch the LBA from the TOC for any particular audio track. But there are exceptions like the Ys IV disc, however. That's one example that I know of.
There are two TOCs of Ys IV btw; two different Ys IV discs were pressed at the factory. The only difference was some audio tracks had more nulls making them bigger, etc. Dunno what happened, why they did it, but it shows that the Ys IV game code stores the track number it wants to play, and with that it fetches the LBA from the TOC always. I guess it's a slightly longer operation, but doing it this way guarantees proper play as opposed to having hardcoded the LBA/sector offset with the game code. Obviously though, most developers took into account that it wouldn't be an issue since once they were finished with the disc and ready to release it, nothing in the TOC would be changing.
-
Hey NightWolf, I just found your old rigg web page for ripping PCE/DUO rom, which I want to thank you. I'm new to this, so can I only follow instructions of CDRWin step by step and other
information provided by authoritative guide to rippimg.
Forget my old Authoritative Guide to Ripping. Try using TurboRip instead. With the disc image in ISO/WAV/CUE form, you have many more advantages than with CDRWIN's BIN/CUE, so it's better to just learn how to use TurboRip right now.
-
Sorry, I assumed he was trying to learn both. But yeah, definately just use TurboRip ;) As NW says, the CDRwin method is outdated.
-
Neat thing this program, used it and got working images from my PCE games. I have one question though about the R-W subcode. My burner apparently doesn't support it but I forced it to rip anyway. Ripping went witout a hitch and tocfixer says it's a correct rip and as mentioned it works flawlessy and sounds good when I play the tracks. It warns about not being a completly 1:1 rip and I wonder just what might difer.
-
It's possible that detection of R-W support is failing and so you're OK. This is due to so many CD devices being made without there being THE ultimate final authoritative standard to follow. MMC is one such standard, but it came later in the game. All modern drives have come to follow it for the most part, but it's not always perfect.
Oh, and here are some of the upcoming features I'm currently working on in my leisurely:
+Multi-session support so as to correctly rip CD-EXTRA music audio discs.
+CD-TEXT support.
+Correct detection of Indexes (INDEX 00, 01, 02, etc.) which will increase compatibility with game discs from other systems (NeoGeo CD probably, if Squaresoft74 is correct). TurboRip is currently hardcoded with PREGAP 03:00 & PREGAP 02:00 for track type transitions which is based on the assumption of a PC-Engine/TG-16 disc. Of course, not all discs are gonna obey those transition rules, but it turns out you can correctly detect Indexes by reading the Q-subchannel information of a sector, to be technical. Anyway, this will make TurboRip more like CDRWIN with its subcode analysis feature. I can appreciate CloneCD a little more now with its separate ripping of all the subchannel data into a separate .sub file. It's a far better program for duplicating a disc.
I've grown quite fond of this little program of mine I have to say. When that happens, the work towards improving it is quite enjoyable. I'm in the mood where even when I'm working on other things, I keep thinking about how to advance it. Fun stuff, ya know? ;)
-
This may be a newbie problem, because I don't know. I was going through my PCE CDs and playing them on ME. I noticed in some of my games during the intermission sequences, the sound seems to be behind the animation, like when someone is talking you'll see there lips move and 2 seconds later you have the actual audio.
These are not original discs, and they are probably nonRIGG. Is there a way to correct this?
-
Yeah. If they were MP3 rebuilds, you can use TocFixer. If MagicEngine shows a game CD title at the bottom left when you select boot CD, that means the game has a valid TOC and will not have issues such as the cinemas being out of sync, of course, it's not perfect with an emulator, but if it's as bad as 2 seconds, than yeah, it's probably a MP3 rebuild (That's when someone expands an ISO/MP3/CUE image file set to ISO/WAV/CUE, burns it to CD-R, rips it back to BIN/CUE or something, then decides to share that...). Anyway, here's what to do:
1) Rip the CD-R with TurboRip to an ISO/WAV/CUE image file set.
2) Run TocFixer, browse to where you ripped the image file set, and select any one of the files, either ISO or WAV. Then click Repair.
Note: If TurboRip detects the game title after trying to rip it, that means you're wasting your time and the game is OK. If it can't identify the disc, and you know it's a pce/tg16 game, then it is bad and so proceed with the rip and use of TocFixer afterwards.
TocFixer link: https://www.ysutopia.net/index.php?ind=downloads&op=entry_view&iden=4
-
Thank you very much! ^_^
One other quicky. >.>
One of the games that is "flawed" is Star Parodia. TurboRip made 25 tracks, but Toc Fixer says theres suppose to be 24 only. >.>
One of the track size is waaaaaay off, but it sounds like its part of the game. I'm not sure what to do. m(_ _)m
-
Well, either get a new image or knock one track file off that doesn't belong. The last track should be a data track, same for track 2. The rest should be audio tracks. Not much else I can say. Though, another possibility is you've not correctly identified the game to pick. Make sure that 25 tracked game really is Star Parodia - Load the game again in the emulator. Actually, that's likely the problem. I'd say you're not correctly identifying what you have there, and so you're picking the wrong title in TocFixer's list. You should also check there that is no other wave or iso file in the same folder from something else that you did that's being counted, thus throwing TocFixer off.
-
I loaded the game in my TG-16 machine, it still says Star Parodia. o.o
Maybe someone will have the sound tracks posted somewhere on the web, or I'll have to hunt down an original somewhere.
Changing the subject for a bit, I noticed beefing up the cdrom cache size and cdda buffers did the trick in hopefully solving the cinema/audio delays. Hopefully that will be a permament solution for any other games that are like that. ^o^;
-
Anyone else have problems with the TGCD not being able to play CD-R's? Is there a way to fix it? I can play them fine in Magic Engine. I'm not trying to pirate or anything, I just want to backup my TGCD's so I don't scratch them etc... My TGCD starts to play CDR's but after awhile it freaks out...
-
Not much to say about that other than TGCD units can be picky about the media brand you're using. Try other CD-R manufacturers. I use cheap PNYs and they work fine. Try verbatim, whatever. Something other than what you're using now. You can also try lubricating the pole that the CD lens slides on with something like vaseline using a q-tip. That *might* be useful or random advice I just threw out there... Anyhow, that's about it unless you wanna send the unit off to one of those TGCD repair guys that are out there to make adjustments to the laser/lens that can improve its handling of CD-Rs in general.
-
I recommend Memorex CD-Rs. They work good in my TurboDuo.
-
Even though it'll be a while before I work on the new version, possibly next year, I wanted to make this known to current users. Please make sure you do not use TurboRip with any of the 7 Games Express discs nor any PC-FX discs!! I know for sure now that there are discs in those cases with tracks that have indexes over one and TurboRip does not account for them. Also, I would avoid using it for game discs with other systems. Just use it with regular PCE discs for now to be safe, until the new version is released which will detect q-subchannel data and therefore account for pregaps and indexes greater than one properly. Most music CDs are safe for now as well.
Well, that's the only news update I have for now. Last I worked on TurboRip, I completed the first feature I mentioned, that being multi-session support, so it does now rip some CD-EXTRA music audio discs correctly (that I've tested with). I was in the middle of CD-TEXT support and playing around with the Q-subchannel stuff when I quit and went back to my translation projects, though. So, that's that. I will get back to working on this eventually though, so you'll have that needed update one day!
-
Yeah black memorex disks seem to work the best.I think you can get like thirty for ten bucks.I remember I had a heck of time tring to get Xak III to play correctly on my dou.
That was back when I was using cdr-win though.
-
Yeah I still use an old version of Fireburner to burn stuff for the Duo... CDRwin didn't always act right for some reason.
-
NightWolve...
While I was ripping my originals tonight, I noticed that a couple more discs still had read errors near the end, and that they weren't "filled with zeores"... what do you use for your threshold to determine whether it's a regular error near the end of disc, or a should-be-fatal error ? Is it a percentage of the track size, or a number of sectors ?
Also, it improperly recognized my J.B. Harold Murder Club (American version) as the Japanese version (the Japanese version was properly recognized as the Japanese version though).
- Dave
-
Here's another funny one for you...
It didn't recognize my Japanese original "Wonderboy III in Monster Lair" disc....
Not sure if this is a new TOC or a transposition error... or even something in TirboRip (probably the TOC database).
-
While I was ripping my originals tonight, I noticed that a couple more discs still had read errors near the end, and that they weren't "filled with zeores"... what do you use for your threshold to determine whether it's a regular error near the end of disc, or a should-be-fatal error ? Is it a percentage of the track size, or a number of sectors ?
Well, there should be at least one sector, the last one, that is zeroed out if you got a read error (i.e. the last 2048 bytes of the track should be zero). If that is not the case, the drive actually read the sector, then raised an error.
As for the detection of this condition, I check if a) a read error was raised, b) it's a data track, and c) if there are 27+5 sectors left to read. I can't tell you how many sectors weren't read without changing the read size to 1 or something, and going one by one when it gets that close to the postgap/lead-out. But from my experience, it's usually about 1-3 sectors. The reason I have to do 27+5 is because of how I setup the reading process. If there are 28 sectors left to read, let's say, and the loop is at the point where it's going to read the next 27, I could get an error at the 27th. The loop will then continue for the last sector, the one left, and generate another error. In those cases, you'll see that "notice" message about zeroed out sectors printed twice.
So, what happens is, if there are < 27+5 sectors left, I null out the read buffer (27 sectors in size) before executing the read. The drive will read as many sectors as it can and write them to the buffer. If it fails to read the last one or two sectors, it will have nothing to write, and the buffer will have nulls for where no writing was done obviously. (In all other cases, I don't null out the buffer for speed, since I expect all 27 sectors to read.)
Anyway, I wanna be sure for the case that you're talking about, you had at least the last 2048 bytes of the data track in question being zero when you saw the error. If so, then there was nothing unusual. But yeah, check that and lemme know.
Also, it improperly recognized my J.B. Harold Murder Club (American version) as the Japanese version (the Japanese version was properly recognized as the Japanese version though).
Thanks. Square didn't tell me about odd cases such as this. I looked at the TOC database site, and it reveals both the US and JPN versions have the same TOC. He has recorded a CRC32 for both data tracks to identify them however. But as we now know, even using that is a problem since some drives fail to read the last few sectors which will fail to guarantee a reliable CRC32.
(Same problem with Wonderboy III in Monster Lair BTW and it looks like he didn't read the CRC32. Anyway, I think I know a way to detect these discs, but I might need your help for that. Usually, in the beginning of the data track, many developers leave the actual game title there. It's right after "NEC Home Electronics, Ltd.". Anyhow, I could certainly use that instead of a CRC32 to differentiate.)
-
I'm still ripping the originals... I've actually lost track of which discs failed to read fully, but I'm sure I can find at least one to answer your question above.
Other strange behaviours I have seen:
- Once, the DLL was somehow locked on a single machine (I was not locking it by using a second process anywhere on my network). This went away and never happened again - I don't think I can repeat it.
- There are "bad" (non-ASCII) characters in the TOC names of several titles - notably, the RomRom2 Karaoke (the 2 is superscripted) and Ranma 1/2 titles (the 1/2 is a single character). I know you didn't build the TOC, but I figured if they were going to use characters like those, they might as well have gone with the Japanese titles.
- "Emerald Dragon Taikenban + Guidebook" was not recognized
-
OK, here's some crucial information about differences:
- Monster Lair (US) and (J) are NOT the same TOC. But they are the same until the leadout.
US: Leadout: 40:34:20 LBA 182420
JPN: Leadout: 40:34:23 LBA 182423
As for the name after the 'NEC Home Electronics' blurb:
US: MONSTER LAIR 891012
JPN: MONSTER LAIR 890812
J.B. Harold doesn't have nice differences like those, though.
The TOC is the same, and there is no name at that point in the data track.
As I recall, this game had both languages built in from the beginning, so it's probably just one byte that's different.
(after actually running such a compare...)
Well, the data tracks are significantly different.
Offset 0x1001 is the first difference.
(J) 0xB0 0x53
(U) 0x78 0x62
-
OK, here's some crucial information about differences:
- Monster Lair (US) and (J) are NOT the same TOC. But they are the same until the leadout.
US: Leadout: 40:34:20 LBA 182420
JPN: Leadout: 40:34:23 LBA 182423
Hmmmm... OK, I didn't notice that. But now, either we got a problem here in Square's TOC or there is another print of the disc. Here's what I got:
US: Leadout: 40:34:20 LBA 182420
JPN: Leadout: 40:34:22 LBA 182422
The JPN disc is off by one. You said it didn't recognize your JPN disc, right? That's what should've happened because the Leadout track's LBA is used to ID the disc. Well, looks like Squaresoft74 needs to know about this.
Here's the TOC for "Emerald Dragon Taikenban (J)":
Track (01) audio 00:02:00 LBA=000000
Track (02) data 00:49:71 LBA=003596
Track (03) audio 10:54:54 LBA=048954
Track (04) audio 15:19:13 LBA=068788
Track (05) audio 17:14:25 LBA=077425
Track (06) audio 19:18:46 LBA=086746
Track (07) audio 21:25:45 LBA=096270
Track (08) audio 23:35:43 LBA=106018
Track (09) audio 25:42:53 LBA=115553
Track (10) audio 27:00:29 LBA=121379
Track (11) audio 29:22:21 LBA=132021
Track (12) audio 33:07:68 LBA=148943
Track (13) audio 34:05:31 LBA=153256
Track (14) audio 35:03:70 LBA=157645
Track (15) audio 37:35:15 LBA=168990
Track (16) audio 39:56:31 LBA=179581
Track (17) audio 41:30:54 LBA=186654
Track (18) audio 42:48:59 LBA=192509
Track (19) audio 44:12:32 LBA=198782
Track (20) audio 45:13:65 LBA=203390
Leadout: 45:23:01 LBA 204076
I bet we'll have a similiar issue if you check this against the TOC file you dumped.
-
Aha !
My mistake, when I ripped it.
The title is:
Kaze no Densetsu Xanadu Taiken Play CD-ROM
The TOC is this:
Track 01 Audio 00:02:00 LBA=000000
Track 02 Data 00:52:53 LBA=003803
Track 03 Audio 04:02:74 LBA=018074
Track 04 Audio 04:55:34 LBA=022009
Track 05 Audio 09:45:04 LBA=043729
Track 06 Audio 14:36:20 LBA=065570
Track 07 Audio 17:16:42 LBA=077592
Track 08 Audio 21:23:59 LBA=096134
Track 09 Audio 21:59:04 LBA=098779
Track 10 Audio 27:48:60 LBA=125010
Track 11 Audio 32:42:46 LBA=147046
Track 12 Audio 35:19:16 LBA=158791
Track 13 Audio 40:16:09 LBA=181059
Track 14 Audio 45:02:24 LBA=202524
Track 15 Audio 50:42:64 LBA=228064
Track 16 Audio 55:56:20 LBA=251570
Track 17 Data 56:20:03 LBA=253353
Leadout: 57:52:73 LBA 260323
Well anyway - this TOC was not recognized.
In the PCECP, it is listed as "Kaze No Densetsu Xanadu Taikenban + Guidebook", but the actual title on the disc is closer to the one I gave above.
-
Hm, it looks like Square doesn't have this. All I have in the TOC database that begin with 'Kaze no' are:
Kaze no Densetsu Xanadu - Sample Disc (J)
Kaze no Densetsu Xanadu (J)
Kaze no Densetsu Xanadu II (J)
He'll have to be informed of this when I get back to working on TurboRip. You've given me a lot of issues I'll have to remember that'll need to be resolved, that's for sure... :P
-
Well, I made it through the whole collection.
Nothing too serious.... let me know when you get back to looking at it.
-
Oh, wait... there are several versions of Tokimeki Memorial as well, and it only recognized one. I was pretty sure that I had at least 2 of them, and the TOC's were probably different.
On the other hand, it might've been the data tracks... and I just wanted to finish the job of ripping.
I'll look at this again when you get back to working on TurboRip.
-
Hi Nightwolve and Dave :)
I just came accross that thread so i guessed i could stop by.
Dave could you mail me the TOCs of your games that aren't recognized yet using TocReader (and different drives just to make sure you don't have any issue that side) aswell as their respective serial written on the disc's hub.
Nightwolve you have my MSN so let's see there if/when you want to chat about that.
In the meantime i'm going to see with the people from my board who own Monster Lair if any of them have a print that differ from the one listed on Necstasy.
As for the games that do share the same TOC, it's true that TurboRip currently can't make any difference between a version and another and might report the first TOC it has in its database that matches with the disc.
-
Hello,
I've been a member of your forums for awhile but I don't normally post. I just came across this thread and was amazed at this tool that you created (I'm surprised I haven't heard of it before). I think it's a great tool and I hope you continue to release future versions of it. I just donated to your site because you deserve it for the hard work you've put into the patches and this tool. The second reason I donated is because I really hope you decide to continue work on this tool (It hasn't been updated in a while) it has great possibilities and I hope that it will soon be able to rip other systems as well. Since I'm a collector I have a large library of CD based games that I would like to catalogue I hope this software will help me achieve that. I own Sega CD, PC engine, PC-FX, CD-I, 3DO, Saturn, & PSX.
Anyway thanks for providing the community with the services that you do!
Psycho DeuceBag your also greatly appreciated as well!
-
Thanks for that. It put you in the Top 16 Donators category.
As for TurboRip, I was working on it some time back and had improved it a great deal. A lot of enhancements were already done, but I stopped just as I was about to work on gap detection issues. The gap issue was the most important thing and I didn't wanna release an update without having had that included. But other duties called. I went back to work on translation projects like ED6 and then Felghana if I'm not mistaken (last year). Anyhow, I can't say for sure when/if I'll get back to it. It's not in the cards at the moment.
-
No problem, I hope the donation helps!!! And I look forward to your next release, whether it be this tool or another translation!
I do have a question about this tool in it's current form though. Since their were timing issues with the tracks, should I use another program for dump my PC-Engine CD's or can I still use this to create a 1:1 copy? If for the time being I should use another program, do you have any suggestions? I'm looking for the best possible method to create 1:1 copies. Thanks in advance for any information!
-
It works fine except for the 7 Games Express discs, and PC-FX discs. There are a few very rare discs, 4-5, that are not named/identified properly as well. If it works with your drive (ie, is able to extract the data track up to the last sector), then you're OK.
-
Thanks for the info!
-
Yo! I just downloaded TurboRip, and it doesn't detect my drive! Is there anything that can be done?
I'm running Windows Vista and my drive is an ATAPI DVD A DH16A1L.
Translation: It's a CD-RW/DVD-R drive that came with my new Compaq PC.
Is there anyway I can solve this problem? If not, would it be possible to make a new version of TurboRip?
It would mean a lot to me if I were able to rip Ys 4 so I could try that translation of yours on my actual system!
-
Yeah, it needs an update for Vista. I was recently annoyed about this and found a workaround. I guess I can share it, though it's too early so don't spread it. Here ya go, attached:
EDIT: With more users moving to Vista/7/8, and no real problems with this version, it's OK/safe to share it everywhere. I set the links up with TurboRip to where if you click on version 1, it downloads this version, a quiet update, but yeah, it's been done. FYI.
I still have plans for the new version, which has already been upgraded to work with SPTI, so never again will it have problems because of the stupid ASPI DLL, which is what caused this issue between XP and Vista/7/8. SPTI is Microsoft's native method for communicating with CD/DVD devices via SCSI, so going direct means faster responses and no compatibility issues. Too bad I hadn't learned this when I released the first version...
Broken BETA now obsolete, get the latest'n'greatest with v1.40!!!!
https://www.ysutopia.net/get.php?id=TurboRip
-
YES! It works! Much appreciated, NightWolve! I'm sorry about all the shit I said about you on THAT forum. That was uncalled for, considering that it was based around a simple misunderstanding. :-[
-
Wow... awesome stuff! Just checked it out on my old copy of Ys I & II for the TG-16. Being a media freak I tend to like renaming and categorizing my media. However, this little app happened to know what disc I had stuck in. I read that the program can test the legitimacy of the disc using a TOC Database? One hiccup I noticed is that it didn't seem to recognize my copy of Ys III for the old TG-16? Ys I and II was labelled properly on the track output, but Ys III wasn't? Is this maybe because we had to import it from Japan at the time? Maybe Hudson changed some things when they ported it over here? Or do you have the Japanese Titles in that db inside the app?
-
YES! It works!
Great!
I'm sorry about all the shit I said about you on THAT forum. That was uncalled for, considering that it was based around a simple misunderstanding. :-
Well, it was forgiveable considering you were a $50 donator, a very very rare breed indeed - I wouldn't have bothered otherwise.
Most of those that were bitching were the usual freeloading suspects, so their opinions are of little to no use, in other words, mostly useless, but to have seen you and what you said was a bit troubling, plus I knew it was something that could easily be corrected, that is, assuming you weren't doing it on purpose (something I couldn't initially tell)...
Anyway, as I'm the big, bad, evil NightWolve, all that kind of stuff comes with the territory, ya know? ;)
I read that the program can test the legitimacy of the disc using a TOC Database?
Yeah, basically a French fellow named Squaresoft74 collects the TOC from someone with an original PCE/TG-16 silver by giving them a little application (pcerip) to read it. He stores all the collected data on a website, here (http://www.necstasy.net/). I came up with the idea of using that data to identify the title of the disc after having seen it in action with the Magic Engine emulator.
One hiccup I noticed is that it didn't seem to recognize my copy of Ys III for the old TG-16?
Hm, it should. Are you using an original silver, and not some burned CD-R ? Lemme see the TOC data that TurboRip produces when reading that disc.
Ys I and II was labelled properly on the track output, but Ys III wasn't? Is this maybe because we had to import it from Japan at the time? Maybe Hudson changed some things when they ported it over here? Or do you have the Japanese Titles in that db inside the app?
Yeah, it normally works since everything is in there, so something is up.
-
Tadaima!
Would you recommend using Alcohol (clonecd format) for making backup images of original CDs and for burning as well?
-
Hi Sanhime, long time no see!
I use Alcohol basic just for mounting, although it does have image ripping features. Seems to work OK.
You want the best freeware that I know of at present for burning software, that's gonna have to be ImgBurn: http://www.imgburn.com/
-
Hey guys, I just went live with a new version of TurboRip v1.40 that fixed/improved several things and added new TOCs for the NEC PC-FX to coincide with the release of the Zeroigar English fan translation patch by elmer and SamIAm!! Hoping to see feedback from people with original CD-ROMs of PCE or PCFX games!
What's trippy for me is after I got it working on Windows 98SE, I went to my Winbook 7" tablet that I just upgraded to Windows 10, plugged in my USB hub, a DVD drive connected via USB, brought TurboRip over on a USB memory stick, started it, and with a Xak III CD-ROM, I always able to rip it however I wanted, ISO/WAV/CUE, or encoded to MP3 just to listen to the audio tracks, or even in ISO/APE/CUE for archival/backup purposes! :) Same behavior on Win98SE to WinVista and on to Win10, etc.! Just hard to believe it could be coded universal enough and work on all Windows flavors, past, and right up to the present! And it's coded in "C" and some Intel x86 Assembly like real men used to code, not in some slow ass Java crap!!! :P
This will be the universal download link: https://www.ysutopia.net/get.php?id=TurboRip (https://www.ysutopia.net/get.php?id=TurboRip)
And here's a look at the changelog:
Version 1.40 (8/8/2015):
+ Uses the Native NT SCSI Library for NT/2K/XP/Vista/7/8/10 platforms! No more
dependency on an ASPI DLL and none of the problems associated with it!!!
+ Certified, tested, approved for use all the way back to Windows 98SE for the
"retro" in you, as well as all the way to the present with the new arrival
of Windows 10!!!! Even I find it hard to believe it works in all of them!!!
+ Improved skipping of unreadable data sectors near postgap area transition.
If you had trouble reading some PC Engine/TG-16 discs, this should help.
+ Major Command Prompt interface enhancement: TurboRip can now be fully run by
double-clicking it anywhere in Windows Explorer! The user no longer has to
first open a Command Prompt window and then CD to the folder where it is
located in order to enter parameters! User will be prompted for parameters
if none were detected when TurboRip is executed/double-clicked!! A troll on
the Ancient Land of Ys forums once barked, "How do you use this F#!K1NG!
PROGRAM?!?!?!?!" having never encountered command-line programs before and
not knowing how to first open a Command Prompt before using it... Short of
a future Windows GUI version, this enhancement solves that issue! Of course
you can't fix stupid nor those who couldn't bother to read instructions...
+ By request, the TOC CD-ROM data of NEC PC-FX videogames (50 out of 80) were
added to coincide with the release of the "Tyoushin Heiki Zeroigar" English
fan translation patch on 8/8/2015!! Only games such as Zeroigar (a shooter)
were added that "OBEY" the standard mixed-mode CD-ROM rules which can
accurately be ripped by TurboRip (The next version will have all 80!).
+ Added CD-TEXT support! Some music audio discs can have track file names and
other info such as artist, composer, genre, etc. burned into the "Lead-in"
area of the disc. Unfortunately, it's rare to find discs using this feature
because it arrived towards the end of the CD format's life, but I thought
I'd add support for it nonetheless! You still have CDDB of course. (You can
think of this feature as CDDB BTW, but that the album data/info is actually
burned into the disc so you don't need a program to do a CDDB look-up over
the Internet to obtain it.)
+ Added CD-EXTRA support! If your music audio disc carries an "Enhanced CD"
label, then it's really a multi-session disc that comes in three possible
forms, both with audio tracks and a MODE2 data track that can include music
videos, interviews with the band, whatever, etc. So, I've added support for
ripping the one format that I know of for now. I happen to have some of
these discs, so I wanted to make TurboRip work with them. Unlike with
CD-TEXT, music audio discs such as these are more common.
+ Various performance enhancements in interface, behavior, coding were made to
really make this app as great as it should be!! However, index/gap detection
by reading the "Q" subchannel failed to make it in this version. Stay tuned!
+ To reduce the size of TurboRip, all third-party components for MP3 (LAME)
and APE are now zipped within TurboRip and extracted/unzipped on demand.
+ When using the /APE parameter for perfect CD backups, support files are now
extracted to easily decompress APE files back to WAVE when needed! Simply
double-clicking the "APE_TO_WAVE.bat" batch file will do the trick!
+ The default 3.9.9.0 (2004) Monkey’s Audio (APE) codec no longer requires the
Unicode layer to work on Windows 98SE, so TurboRip fully works with both its
APE and MP3 codecs on a clean install of all Windows flavors!!! :)
+ Bug fix: I noticed on Windows XP that as TurboRip read sectors from a CD/DVD
drive connected via USB or FireWire, it could actually lose the connection!!
This could happen consistently when you ALT+TAB'ed to switch to another app!
I found the solution was to raise the Process Priority of TurboRip to HIGH!
Normally, disc burning software will raise the Process Priority to HIGH as
well when *burning* a disc which makes sense, and so with all that, I now
ALWAYS set TurboRip's priority to HIGH to avoid the bug with external drives
AND speed up the ripping time - it might as well live up to its name!! :)
+ Bug fix: Fixed a drive selection bug in Windows 98SE when selecting a drive
number from the prompt menu.
+ Fixed issue that caused "Linda ³ (J)" to be excluded from the TOC database.
Squaresoft74's use of the fancy superscript "3" was the culprit...
+ If all CD tracks are audio, it's a music CD (not videogame!) so messages
like "Note: No videogame CD-ROM was detected." were eliminated.
+ The track file-naming style was changed to put the track # (01-99) first.
This is better for sorting and viewing the CD image file set I think.
+ TurboRip no longer installs its own ASPI layer for Win9X/ME, it instead just
relies on the default Adaptec ASPI layer. Compatibility is still maintained!
+ TurboRip sets the TOP_MOST flag 'on' of the Command Prompt window so it can
never be hidden behind other windows until it is closed or minimized.
+ Bug fix: Fixed a minor bug that caused the /name parameter to be overwritten
when the last parameter specified was /useaspi or if any other text was
mistakenly typed at the Command Prompt.