The data is digitally encoded 16-bit PCM, and already has builtin CIRC error correction, there is no "quality" or "accuracy". Your software/hardware either correctly ripped the data or it didn't and this can be trivially verified with crc32 against CUETools or AccurateRip or whatever.
That's generally how the flow chart works in the rip process, if you feel reasonably confident that you've correctly identified your release (specifically the correct pressing) you can burst rip the disc and then compare the ripped tracks to other rips from the same pressing (see also AccurateRip). If you got the same hash as other people ripping the same pressing then you're done.
If your pressing doesn't have a good sample size of hashes to compare to then you use a more secure ripping method that generally makes use of the accurate stream feature (most drives manufactured in the last decade or so have it) it's a slower but more repeatable process of reading a red book CD intended to suppress jitter and alignment errors. If you get through an accurate stream rip and you encounter no read/C2 errors you're probably ok, but if you really have no/few samples to compare against you may be paranoid and rerip the disk a few times to make sure you get repeatable results or even rip the disk with another drive all together.
I can respect the paranoia around ensuring bit-accurate rips of CDs with little-if-any existing metadata on the web.
I remain suspicious of the cargo cult of EAC as doing something substantially different than cdrtools or anything else that knows the ins-and-outs of the redbook format
A lot of the emphasis on EAC is that robust automatic logfile validation tools exist for it (from what I can tell?), so it requires less manual inspection for archival. But I agree that other tools are likely equally capable.
Completely understandable, EAC is certainly not the only software capable of using accurate stream features on CD drives or doing AccurateRip DB comparisons. Making bit-perfect archival rips is more about soundness of "the process" than the software you do it with, EAC is just one such tool.
Mostly, but not completely. CIRC error correction in the Red Book standard is deliberately designed with a soft failure mode for unrecoverable data - specifically, it will "interpolate" audio data to fill in the gap.
If you have a damaged disc, a drive can be better or worse at resolving "marginal" parts of the disc, which will change the data. Whether or not this makes an audible difference is an exercise for the reader, of course.
CD-ROM doesn't have this problem because it introduced a different error correction mechanism with more overhead. So in that case it is "either it ripped correctly or it didn't"... at least until you start getting into mixed-mode discs, or games that stored their FMVs with the weaker error correction mode to save space, or literally anything with copy protection.
CD-ROM doesn't have this problem because it introduced a different error correction mechanism with more overhead.
It's been a while since I've looked at the standards in detail but I believe that involves another layer on top of the layer of error correction that CD-Audio has.
The data seems to be based on telemetry collected for a CD ripping software, which I'm slightly more inclined to believe is real than some mumbo jumbo about vinyl warmth or whatever.
23 of these submissions come from a broken drive, or the disc is damaged to the point a correct read cannot be made. It's not that the drive is producing 99.7% accurate data, there are 10260 100% accurate submissions and there are 23 wrong submissions.
It's a binary state, either the drive is functional and the CD in decent condition, or the drive is broken/CD is damaged. Some drives may have a higher failure rate than other drives, but every drive is either 100% accurate or busted, there is no 95% accurate drive. That's just a broken drive.
> It's a binary state, either the drive is functional and the CD in decent condition
No. How good the drive is at reading marginal discs varies a lot between drives.
The problem is, these populations are not identical disks, and the error rates are low enough that we're not really sure we're seeing a good metric of this.
It's definitely unclear what "inaccurate" means in this sense?
Is an entire track inaccurate if a single sample is inaccurate? In that case then yeah, rather than measuring some level of audio purity, this is measuring your likelihood of getting a perfect rip before taking CD condition into account.
I did it with a simple program that just issued READ CD commands to the drive using SCSI passthrough and saved the first ten minutes of the disc to a raw PCM file. Running that program twice produced two files that sounded the same to me, but had different hashes (and it wasn't a "sample offset" issue either.) The disc had no visible scratches, and it was the same drive that I'd ripped half my music collection from with EAC, so that experiment was solid evidence for me of what the proponents of secure ripping software like EAC keep saying, which is that read errors when burst-ripping on consumer drives are very common.
Unfortunately not all CD drives report C1/C2 errors correctly for audio data from a red book CD which is why you have to do external comparisons (see also AccurateRip) and some discs have fake C2 data as a means of copy protection or sometime the C2 data is just un-reliable.
The data is digitally encoded 16-bit PCM, and already has builtin CIRC error correction, there is no "quality" or "accuracy". Your software/hardware either correctly ripped the data or it didn't and this can be trivially verified with crc32 against CUETools or AccurateRip or whatever.