[SOLVED] Help dumping PSX games with audio tracks.

[pablogm123]

Perhaps, you software/drive cannot overread into pregap or lead-out, and your dump is missing a few of bytes replaced by zeroes. If combined offset is negative, you could miss data of first audio track (at the beginning), if positive of last audio track (at the end). Do you own the very same versions from the DB? Which tracks of Ridge Racer can you match?

By now, forget the fff utility.

[MikuroK]

Perhaps, you software/drive cannot overread into pregap or lead-out, and your dump is missing a few of bytes replaced by zeroes. If combined offset is negative, you could miss data of first audio track (at the beginning), if positive of last audio track (at the end). Do you own the very same versions from the DB? Which tracks of Ridge Racer can you match?

By now, forget the fff utility.

Rollcage is -647 (so -641 was used in rubyripper, on the slimtype (+6)), the other two are +2 (+8 used in rr)
As far as I can tell, the versions are identical, all have matching data tracks, region, serial, and edition all match

As for Ridge Racer, out of 14 tracks, i have matching results for tracks 1,4,5,8,9,10,11,12,14 (unmatching 2,3,6,7,13)

the three discs are;
https://redump.info/disc/922/
https://redump.info/disc/989/
https://redump.info/disc/1178/
rollcage is not one i'm concentrating on right now, as it only has one dump in the DB, so it itself could be inaccurate.

Other drives I've found lying around are,
LG Electronics - CD-ROM GCR-8521B     -24
COMPAQ - CRD-8322B     -24
LITE-ON - DVDRW SOHW-1213S     +12
Incase you happen to know anything about them.

[pablogm123]

The drives with -24 offset correction are interesting to dump the last track of many discs if combined offset is negative, so you don't need a drive which can overread.


I have uploaded a par2 file of tracks of non-matching Ridge Racer tracks. Run the verify function of any par2 program, and drag and drop to its window the tracks you have. Then, compare the files using a hex-editor, to determinate differentes.
http://www.mediafire.com/?d2289fjqb46zy4f

[MikuroK]

drives with -24 offset correction are interesting to dump the last track of many discs if combined offset is negative

Very interesting

As for the par2 files, I have used quickpar just once before, quite recently. I presume you want me to attempt to repair the dumps I have using your files, then post a diff of the original and repaired files?

In anycase, I need to dump those tracks again, won't take too long.

[pablogm123]

Of course, if there are no many differences, you could match the files and compare.

[MikuroK]

Of course, if there are no many differences, you could match the files and compare.

Alright, so I now have repaired versions of those tracks (which now match the DB), but how should i go about comparing them? what information could i find out that can help me?

In anycase, I'm going to sleep for now (3:34AM here!), in the morning I will try out those other cd-rom drives to see what results I get. I may also try PerfectRip in a windows VM.

Thanks for the help thus far, much appreciated.

[pablogm123]

Understood. Check if both are aligned. For example, use any hex editor, open both files and check if non-zeroed samples starts at the same offset. If so, do a binary comparison, which reveals differences. If not so, try fff -crc=$[The CRC32 of DB] -size=[Size according to DB] [INPUT FILE] [OUTPUT FILE, any name you want]. If success, your dump is the same of DB, but shifted. Perhaps, your drive fails sometimes to be accurate stream (just a hypothesis, nowadays this is really very weird, an accurate stream drive is a drive with constant read offset, as expected nowadays) and reads that track with another offset.

[MikuroK]

Understood. Check if both are aligned. For example, use any hex editor, open both files and check if non-zeroed samples starts at the same offset. If so, do a binary comparison, which reveals differences. If not so, try fff -crc=$[The CRC32 of DB] -size=[Size according to DB] [INPUT FILE] [OUTPUT FILE, any name you want]. If success, your dump is the same of DB, but shifted. Perhaps, your drive fails sometimes to be accurate stream (just a hypothesis, nowadays this is really very weird, an accurate stream drive is a drive with constant read offset, as expected nowadays) and reads that track with another offset.

Well huh. I loaded track pairs 2 and 3 into a hex editor, and the versions are exactly 352800 bytes (aka, the pregap length) apart, the fixed one with the pregap silence, and the broken one with no pregap silence.

Looking closer at the rubyripper pregap detection, I notice that tracks 2 and 3 (note, rubyripper counts tracks starting from first *audio* track) aren't detected as having gaps, so that would explain those two tracks

Code: Select all

Silence detected for track 3 : 150 sectors
Pregap detected for track 3 : 150 sectors
Pregap detected for track 4 : 150 sectors
Pregap detected for track 5 : 150 sectors
Pregap detected for track 6 : 150 sectors
Pregap detected for track 7 : 150 sectors
Pregap detected for track 8 : 150 sectors
Pregap detected for track 9 : 150 sectors
Pregap detected for track 10 : 150 sectors
Pregap detected for track 11 : 150 sectors
Pregap detected for track 12 : 150 sectors
Pregap detected for track 13 : 150 sectors
Pregap detected for track 14 : 150 sectors
Pregap detected for track 15 : 150 sectors

Track 6 is even weirder, it appears to have several seconds of track 5 at the start, then the pregap, then track 6...

The first two appear to be an issue with rubyripper, and the others seems to be like you said, the drive isn't staying true to it's +6 offset during track changes, I'll give those other drives a go, and find out if there's a way to get rubyripper to detect all track pregaps.

Edit: I converted track 6 of both versions to flac and played them, the broken track 6 does indeed have ~6 seconds of the end of track 5, then pregap, then track 6 at the start

[pablogm123]

6 seconds are 264,600 stereo samples, really a huge jump. Perhaps it's a software problem (which detected wrong range), because I cannot believe that a drive can jitter so much, when supposedly any modern drive is free of jittering problems. To discard a drive issue, you could rip the Ridge Racer without detecting gaps at all. For my personal music collection of audio tracks extracted from Saturn/Mega-CD/PS1 games I rip discs without detecting gaps, so that I have the expected hashes, last track is not included because contains just silence:

http://img547.imageshack.us/img547/5167/ridgeracer.png

And, is there any chance to run EAC by Wine?

[MikuroK]

EAC is known to work in Wine, but i'd rather stick to native/free software if possible.

I'm about to try the other drives now (probably won't bother with the compaq one though, it's from 1999). I'll try EAC, and also see how cdrdao by itself fares (it dumps cd's to a single image, from start to finish, which i can then split into tracks afterwards).

On a mostly unrelated note, do pure audio cd's have a write offset that I should be aware of? I imagine it would be trickier to manually find such an offset...