Jitter correction & comparison ripper

[sbooth]

There have been a few requests for the addition jitter correction to the comparison ripper. I'm honestly not sure that this type of error correction even applies in this case. I've been trying to think about how it could be implemented. It seems to me the general approach to jitter correction (overlap detection) would be:

• Read the sector of interest with some amount of padding on either side
• Determine if the block shares common data with the previous sector
• If so, assume the new sector starts where the old one stops and continues for 2352 bytes
• If not, something is very wrong!

So my initial question would be- how do you get a "good" value for the first sector? One could simply read it and assume it is good, and base subsequent reads off of it. I suppose this is where offset correction of some sort would come in to play.

Specifically for the comparison ripper, at what level would the jitter correction be applied? Currently an array of Rips is maintained, where each rip contains a contiguous block of sectors read from the disc. The ripper iterates through each rip, comparing sector data or hashes to determine if they are equal. If the required number of matches is met, that sector is saved to the output Rip.

It doesn't seem feasible to add jitter correction at the comparison level, because the whole premise behind the ripper is to compare the raw data coming off of the disc to determine how accurate it is. If it was adjusted for overlap, what would be the point of comparing it?

So it seems to me that to apply jitter correction really requires a sector-based ripper that re-reads sectors as required. Sounds like cdparanoia all over again! I could write an overlap-detecting ripper that cleared the cache between reads, but I can't imagine how slow it would be. Also, I'm not sure what other types of manipulation paranoia performs on the data besides simple overlap detection.

Any thoughts?

[krmathis]

First I want to say that this is WAY above my knowledge level. But I like to place a comment anyway...

What I want is a secure way to rip scratched CD's. A ripper which is on par with the MS Windows application EAC (Exact Audio Copy).
I really don't know what "magic" it perform on the ripped data, but the users seem to rank it above all other rippers.

EAC support some kind of 'Jitter correction', but I don't know how.

Features:
Hidden sector synchronization (jitter correction)

For what I know Max with the current comparison ripper, and the new C2 error detection, already match up with EAC. I really don't know!

[ye]

I think this FAQ article is quite informative regarding jitter and the strategy to correct it used by this program
http://www.feurio.com/English/faq/faq_v ... tter.shtml

On the other hand there is a list of CD drives on the same site
http://www.feurio.com/English/cd_roms/f ... t_ide.html
which among others shows which drives perform the jitter correction internally. So for these drives a software jitter correction is useless. The drive of my Mac and all that of recent Macs, I can remember, have internal jitter correction due to this list.

[sbb]

thanks good info!