I've hacked together a command-line ripper for OS X that basically:

1. Reads a contiguous set of sectors one at a time off of a CD and saves them to a temporary file
2. Re-reads the same set of sectors and saves them to a different file
3. Compares the two files sector by sector (2352 bytes at a time)
4. Writes matching sectors to a third file, and zeroes out non-matching sectors
5. Prints out any differences it finds

This is the beginnings of Legg's method outlined in this thread.

This was more of a proof of concept than anything. And here is the interesting part- I am unable (in my short testing cycle) to get different read results! It makes no sense to me. First I tried ripping just a single track a few times. When this failed to cause any problems, I ripped a ton of sectors (207943 to be exact). I got this:



Maybe I need to try with some old scratched-up CDs, but nonetheless I was surprised. I don't quite see how not even one byte could be different in two files this large that were read off a cd using ioctl().



I'll be happy to share the code if anyone wants to take a look at it.

Would reading the sectors one at a time cause any different result than reading a larger chunk? I imagine that, regardless of the read size, the drive will fill its buffer in anticipation of further reads.

Drive caching perhaps?

Doubtful its drive caching. Pressuming a sector is 2352 bytes and 1024 bytes to a KB etc then the large rip of 207943 sectors gives:



At least i think i worked that out correctly, feel free to tell me i got it all wrong lol


I guess its just not a very scratched disc If you PM the code, if it's C or Java, or send a ppc binary, then i could try it on some of my VERY scratched discs lol. I swapped my drive for a Pioneer K06 drive in my powerbook the other day, so may have different results.

Cheers,

Kristian

//edit -- try running md5 check on both the files to double check they are the same.