<snip, snip> > Since computers like to work in portions, ripping audio from > a CD can > cause the requests to start and stop, instead of constantly stream. > But the format is not designed to gracefully handle that. This can > cause errors (repeated data or lost data) which differ with > each rip, > due to conditions not necessarily being the same each time (and of > course a single bit error will cause a different hash). > > This is why CD paranoia exists. CD paranoia reads back a little with > each new portion of the stream read and then tries to find where the > overlapping data at the end of the previous stream matches the > beginning of the new stream. It then joins them so that there should > hopefully be no repeated or lost data, discarding the redundant data > in the process. The use of CD paranoia will increase the chances of > getting the same hash from a rip, but it can only do the best with > what it is given from the drive under variable conditions. > > Also, CD audio data has weaker error detection/correction than CDROM > data, so marginal reads have a greater chance of giving differing > results. Combine the random nature of noise with marginal data and > weak error detection and that noise can colour the output in an > unpredictable fashion which is not constantly repeatable.
Or you could find a drive with a good implementation of C2 error correction. Reed-Solomon code used for storing raw CD data is almost capable of miracles. > It would not surprise me if you could get exact same hashes on > subsequent rips, but it also would not surprise me if you did not. Enter EAC (as I said it's Windows only but it allows bit-perfect rips). I'll quote some things from the EAC's website[1]: >>In secure mode, this program reads every audio sector at least twice. That is one reason why the program is so slow. But by using this technique non-identical sectors are detected. If an error occurs (read or sync error), the program keeps on reading this sector, until eight of 16 retries are identical, but at maximum one, three or five times (according to the error recovery quality) these 16 retries are read. So, in the worst case, bad sectors are read up to 82 times! But this will help the program to obtain best result by comparing all of the retries. If it is not sure that the stream is correct (at least it can be said at approx. 99.5%) the program will tell the user where the (possible) read error occurred. The program also tries to adjust the jitter artefacts that occur on the first block of a track, so that each extraction should be exactly the same. On drives found to have the "accurate stream" feature, this is guaranteed.<< And in order to get the same hash on different drive models or even a bit identical CD-R copy of the pressed CD it supports read/write offsets: >>'Sample Offset' is another new feature of EAC, it will help to always get the same WAVs compared to a different reader and to prevent generation losses. Nearly all drives can not position the head correctly. That means if the program tells the drive to read block 10000 it will probably read data somewhere in block 9998 instead. But this is not visible to the reading program, it won't know if it is really the data it wanted. Usually the head will be set always to a fixed offset before or after the correct read position. So it is possible to detect this offset once and use it for all CDs coming afterwards.<< [1] http://www.exactaudiocopy.de/
