1 (edited by MikuroK 2012-10-31 19:28:02)

I'm getting erratic results trying to dump games with audio tracks, i feel like i'm still missing something... just now i'm trying to dump the games MDK, Ridge Racer, and Rollcage (PSX).

ridge racer and rollcage give matching tracks to the ones listed in the database, but not all of them match, mdk doesn't match with any tracks listed.

all disks are in pretty good shape, with only ridge racer causing retries in my dumper (and the tracks that did give warnings, happened to match the DB)

I'm using rubyripper in linux, with the correct combined offset for each disc (else i would get no matches at all), and i have it set to copy/test each track at least 3 times

i've even tried using another cd reader, with a different read offset, my results are all the same, but some tracks still don't match the DB

let me know if you need more details (hash listings?), and thanks for your time

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.

According to this info: http://wiki.hydrogenaudio.org/index.php … Rubyripper, that ripper doesn't take advantage of C2 pointers, so that it is somewhat possible that Rubyripper is ripping a constant error, which always returns the same data, and cannot detect it because doesn't use C2 pointers.

I use this utility in Windows, also available for Linux, the GUI is named qpxtool. It can controls diverse functions of real Plextor drives, shows the number of inserted discs and time spent reading/writing for that drives. The most important function is to scan discs, to detect E32 errors, and supports many types of drives for that (I have tested it in Lite-On Mediatek based drives, and Pioneer NEC based drives).
http://qpxtool.sourceforge.net/

And, are you sure that Rubyripper is detecting the correct gaps, and gaps are appended to next track?

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

usurper wrote:

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

pablogm123 wrote:

And, are you sure that Rubyripper is detecting the correct gaps, and gaps are appended to next track?

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)

5 (edited by pablogm123 2013-09-29 20:21:07)

LITE-ON - DVDRW SOHW-812S: This kind of drives can usually overread into pregap and lead-out, but the app used has to read directly the required lead-out sectors, PF do this. EAC reads in a burst the last sectors of program area and required lead-out sectors to overread, and these drive refuse that.

The DVDRW SOHW-812S drive should be pretty good for PF, if you can run PF (to verify rips obtained by Rubyripper) using Wine and this drive can overread, but these drives have usually a bug: In the data-->audio transition, they skip the first two sectors of audio zone, and reads the two first sectors of lead-out. To compensate this, you have to apply this offset correcion: ([EXPECTED OFFSET CORRECTION] + [-1176 samples]). Also, they sometimes read very slow (at more or less 1,5x) the data tracks of some PS1 discs. Yet in general, they are good drives for ripping, and can read the last sector of data tracks of multitrack noEDC discs.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

6 (edited by MikuroK 2012-10-29 15:58:23)

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?

7 (edited by pablogm123 2012-10-29 16:17:55)

True, CDs are more complex than DVDs, specially the ones which combines data + audio.

Use the fff program:
http://www.mediafire.com/?ld1nfy4fbgb09a1

It's a program that will brute force a huge set of offset corrections until find the correct one to apply.

The Lite-On drives (LTR-52246S and LH-20A1P, and both suffers from that bug) I own are listed as +6 in AcccurateRip list. Perhaps the yours, +12, has a Mediatek chipset of another older generation, unaffected by that bug. That bug only affects rips made by programs which rip data + audio in a go, and read subs on the fly: CloneCD, PerfectRip... EAC and others pure audio extractors aren't affected.

And your CD is in good shape, there are no E32 errors.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

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.

PS3Dec (decrypt ps3 images), PS3DumpCheck (check integrity), GetKey (dump PS3 metadata), DatSplit (split redump dats), GPack (compress related images together)

In fact, the tracks which contain just digital silence are tricky. My Ridge Racer CD gave me lots of E32/C2 errors in the last track, which is pure digital silence, until I fixed it resurfacing. But, I was getting matching hashes because drives interpolates unrecoverable errors, replacing bad values by the arithmetic mean of previous sample and next sample, and 0+0/2=0, so nothing changed.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

10 (edited by MikuroK 2012-11-02 17:31:36)

jamjam wrote:

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

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.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

pablogm123 wrote:

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

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

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

14 (edited by MikuroK 2012-11-02 17:31:55)

pablogm123 wrote:

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.

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

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

pablogm123 wrote:

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.

17 (edited by pablogm123 2012-10-29 18:52:04)

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.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

18 (edited by MikuroK 2012-10-30 05:17:05)

pablogm123 wrote:

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

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

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?

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

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

21 (edited by Jackal 2012-10-30 12:14:19)

MikuroK wrote:

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

Well, there's your problem.. You're not using the appropriate tools.. Rubyripper appears to have problems.. Perfectrip won't do you any good without a plextor drive.. So your only real option is Wine + EAC.. Then there's also the trurip 0.43 source code but I don't know if it has all the files that are needed for compiling into a native linux binary (I don't think anybody else has tried it yet): http://vigi.dremora.com/trurip_v0_43_alpha_source.rar

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

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

23 (edited by MikuroK 2012-10-30 17:04:15)

Alright, I've installed and setup EAC, dumped track 2 with my SOHW-1213S.

It matches.. but EAC put the pregap at the *end* of the track, I looked around but couldn't find a way to make it preprend gaps (how does this even happen when I don't let it detect gaps?).

I verified it by stripping 2 seconds from the end of the track, appending 2 seconds to the start, then checking the md5.

The drive supports C2 error reporting, so that's nice.

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.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

25 (edited by MikuroK 2012-10-30 17:31:05)

Yes, it caches audio, but it's going at ~6.4x, which is fine with me.

I found the setting you mentioned a moment ago, and so far things are going well, but track 2 still has the pregap at the end of the file.

Edit: finished the disc, tracks 2, 13, and 14 are non-matching, less than before, but 2 is only wrong because the pregap is in the wrong place, and it somehow messed up 14.. which is a blank track...