redump.info Forum

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?

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)

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.

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?

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.

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.

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.

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