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