[guygee]

Originally Posted by Quux2112

As others have said, as long as the checksums match, the track was ripped perfectly.

However, I have heard that EAC can report "Copy OK" and still have non-matching checksums. I've never seen this happen, just heard that it can. Whether it's true or not, it's probably always a good idea to compare the checksums and not just rely on the "Copy OK" message.

What I have seen happen though, is EAC rip a scratched track, report copy OK, give matching checksums, but still have a very brief bit of silence in the track where the scratch was. So it's also usually a good idea to listen to your rips before sharing.

Since EAC uses rereads and a "voting scheme" to try and correct errors in bad sectors, there is a very small (but finite) probability that a sector can be misread and still report OK, so what you say about non-matching checksums makes sense (although this should be very rare). However, as almost everyone has said above, if the checksums match the probability that an error occurred should be essentially zero.

From the EAC site:
"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."