EAC Track Quality 99.9%

[Lou]

What is the deal with this, like why do some tracks come out 99.9%, with the error correction coming at the tail end of the track? Is the acceptability of this marginal or is it OK? If you see this should you be trying to re-rip to get it to 100%?

[dancin_carrot]

As far as I know, getting less than 100% simply means it took more than one attempt to rip that track perfectly. As long as it says copy ok at the bottom, the track is fine.

[Lou]

OK good, thanks.

[dancin_carrot]

Just a bit more detail from http://users.pandora.be/satcp/eac07.htm

While Peak level tells nothing about the quality of extraction, Track quality does. A Track quality of 100% obviously means that the track was extracted 100% correct. But here's where some people make mistakes; sometimes EAC rereads certain audio sectors multiple times to get accurate extraction results. For every reread EAC does, the Track quality decreases, but this does not mean that the extraction is less accurate. It is possible to have a bit-by-bit perfect copy of a track, while Track quality is lower than 100%. As long as Exact Audio Copy does not report any errors in the Status and Error Messages log, the extracted files are bit-by-bit perfect copies of the original. Track quality should be interpreted as the physical quality of the CD and not of the extracted data. A CD with some scratches or dirty fingers on will certainly cause rereads in EAC and thus a Track quality lower than 100%, but still the extracted tracks may be perfect. Thus if the log says Copy OK for a track that means it's extracted perfect - no matter of the Track quality. So, I hope that made things more clear as many people are confused by the Track quality.

[Lou]

That's excellent because I always just assumed that anything less than 100% meant it was near perfect, but EAC couldn't get it to perfection due to scratches, smudges, etc.

[pmonk]

IMO - I think it has to do with the inferior mechanics that bootleg companies use to mass produce silvers (compared to a major label like Sony)

When I get a new boot the first think I do is rip it and put it away and listen to it on a cd-r!

The only time Dragon Snake was removed from its sleeve was right into my computer and put back where it shall remain!

[Lou]

Yeah actually the reason I posted was because I saw that, it's like how could something unused before get 99.9% and not 100%?

[Five]

This used to confuse me, too... I used to rip and re-rip trying to get 100% on all tracks but also noticed that the checksum were identical so long as it said "copy ok"

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.

[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."