Auomated Dump via ImgBurn: Batch file(s) for mass ripping of optical media (CD and DVD).
GitHub Description of advib
This will be part 1 of a multi-part series fully exploring the code and functionality of advib. You can find the part 2 (and eventually more parts) as well as any other advib-related entries under the advib tag.
Sure, it might seem like me being the original author of said program would make this task some how easier but…it’s not going to be easy even for me. The author.
The eventual goal of this exercise is to document and explore the code, the functionality as it exists as well as find what is incomplete and doesn’t work. This way when I start the re-write I can add any missing functionality as as additional features to make a much more complete version. It will be a combination re-rewrite and refactor in other words.
As mentioned elsewhere, I wrote this when I decided (wisely?) to rip my entire collection of PS1 and PS2 games. At the time I had 150+ games for both consoles so I already knew it was going to take a long time to do even with with multiple optical drives going at once.
I actually tried quite a large number different programs that claimed to have really great ripping abilities. Even the ones that cost a lot of money had less than impressive results.
Then I found the free (as in beer) ImgBurn. I (by which I mean ImgBurn) still had some issues with multi-track PS1 games (more on this later).
You see PS1 games are in a standard CD format called “Compact Disc Digital Data” which was a very common format in the 90s with CD-ROMs. Really they were audio CDs (the kind you stick in an audio system) with data on them: a game for instance would use “Red Book audio” for for music and sound effects. If you stick one these “Compact Disc Digital Data” discs – a PS1 disc, PC game disc, whatever – into a CD audio player and it starts playing that would be Compact Disc Digital Data. This is how game consoles like PS1 or SegaCD were able to produce impressive surround sound: audio CD technology. I learned a lot of this stuff as I was writing advib. I may have known it previously and forgot or it could be I never realized it. This CUE/BIN thing is true across other disc types like karaoke CDs since they are audio tracks with some graphics..
This is also why for the life of me I couldn’t rip a PS1 game into anything other than cue/bin format. That means each and every PS1 game MUST be ripped to two files: a cue file and a bin file. The cue file is actually just a text file describing the audio tracks (where each begins and ends) while the bin file is a rather large “binary blob” containing the data. An emulator will not load a game without both files being present, the file names matching each other (a test-drive-5.cue for a test-drive-5.bin).
PS2 games on the other hand were a little different: the PS2 lifespan was so long it actually had games released in both CD and DVD formats. In fact at some point PS2 games came on dual layer DVDs also requiring two files. I think games in the earlier part of the PS2’s life games came out on CD – there were known issues with blue-bottomed discs with some consoles – and later as DVD media became cheaper it seemed to have gone out of style.
I seemed to be able to rip PS2 games with much more consistency than PS1 games. PS2 games mainly seemed to fail when there was a rather glaring scratch on a disc or other obvious physical flaw. DVDs (with data) don’t seem to have any issue at all being converted into ISO files.
As a last step I have ImgBurn do a verify of the ripped bin/cue and ISO files against the original disc that is still in the drive. I learned that ImgBurn actually wants to be pointed at the CUE file not the bin file for the verify step. This is an important detail in how advib works.
Since I’m publishing this before any of the other advib-related entries I’ll just point you do the the advib tag to get to part 2 and anything else I happen to come up with.
Tildes on the side 