[SOLVED] Help dumping PSX games with audio tracks. (Page 1 of 2)

If no track matches, you prolly not using the correct offset.
Does you drive support overreading? if not, this could be an issue as well.
If you provide additional information (what drive you use) and also your EAC logs, we could provide help.

I don't have windows installed, nor do I want to install it. I am using isobuster in wine to find offsets until i find a native tool to do this.
i can provide rubyripper logs, though

yes, the detected pregaps were always the same as in the database, so were the filesizes, gaps are prepended to the current track, but this can't be an issue, as i mentioned some tracks *are* matching, if the pregap method was wrong, none of them would match.

the drives i'm using right now are; Slimtype - eSAU208 4 (+6), and LITE-ON - DVDRW SOHW-812S (+12), i have access to a couple others, if needed

I'll check out that tool, looks like my lite-on drive is on the supported drives list for it, maybe i should use that drive more (i'm using the slimtype mainly atm)

cd's are not a very simple format, are they?

i tried the qpxtool on both drives with my MDK disc, results are attached.
if it's any use, the firmware on my lite-on drive is "US0N"

I'm looking into PR (PerfectRip, I presume?) now.

if the offset it incorrect, how is it i'm able to get some correct tracks?

Are the matching tracks just filled with zeroes? It's the only likely way an incorrect offset could yield matching tracks so it's worth checking.

no, they are tracks containing music, i'm aware of blank tracks, as they were the only ones i could dump accurately before learning about offset compensation.
For example, Rollcage tracks 4 through 15 match those in the redump DB, leaving only the first two (2,3) and the last one (16) audio tracks incorrect (data (1) is also matched), this was dumped from the slimtype drive.

@pablogm123
Seems perfectrip can't find my disc drive when run in wine, it's probably trying to use Aspi. isobuster works in wine, because it can be set to SPTI, which wine supports.

>others pure audio extractors aren't affected.
fyi, rubyripper only works on audio data, it doesn't support data track ripping. I use cdrdao to dump the data track (and split the result with bchunk), which works well for me so far.

I'm not sure what I'm expected to use fff.exe for...

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;
http://redump.org/disc/922/
http://redump.org/disc/989/
http://redump.org/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.

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.

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.

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

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

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...

It seems that EAC is the only realistic option, and another program to extract the data track.

Generally speaking, there is no way to determinate the exact write offset of pure audio CDs, because audio lacks of syncs header. However, it is possible that many audio CDs have -12, 0 and +222 write offset. I own two CDs protected by Key2Audio, which has scrambled data sectors in pregap of first track, but marked as audio, and I have to apply -12 write offset so that scrambled sectors are aligned. Also, I have CDs whose non-zeroed sample is the last of image with 0 write offset, and other with a data track, with +222.

The clever approach is apply standard offset correction of AccurateRip, and apply a customized offset correction only if needed to rescue non-zeroed samples pushed to lead-out zone or pregap zone. For example, the miniCD bundled with Tenbu - Mega-CD, the correct offset correction to apply is the standard + [+13].

But very likely caches audio, and that slows down the secure ripping of EAC. The ideal is a drive which doesn't cache audio data and reports C2 errors, or a real Plextor drive which can use FUA to defeat fastly and easily the drive cache.

You have to detect gaps (F4 hotkey), and after detect gaps choose append gap to next track. Try the three modes of detection offered by EAC, and choose the one which is faster and detect proper and expected gaps.