If you get even an error-corrected rip, why would that not be perfect? I guess I’m failing to understand how any of this could improve accuracy in any way.
Additionally, there is no way to know that you've passed that threshold -- the drive will just return bits, with no way to guarantee that they're correct.
A better description for this is "passive" error-correction. To try to get a 100% bit-perfect rip, it's preferable to start off with a drive that you know minimizes errors in the initial read process.
That just goes to show the lack of design foresight. They were still thinking in terms of grooves carved in plastic or a waveform on tape.
My guess is that you couldn't fit a lot of information on it, what with the redundancy to make it perfect.
Real media like CDs usually have 'burst errors' like scratches that give a whole bunch of successive bit errors; however, there's an interleaving process to "spread" the errors across blocks, i.e. spread the information so it will resist a scratch. In an absolute way, indeed it's impossible to guarantee almost no errors (although you can guarantee almost no undetected errors) -- simply because your CD might be ruined in a way (which I guess isn't all too unlikely). By setting your rate R to a reasonable level above your drive error rates, you can get almost no errors (as few as you like) within those bounds (and fail above).
Here's a typical error rate curve for a moderately large (255b) code: https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_cor...
That is, however, error detection and not error correction.
Once an error is detected you can apply 'correction' to the nearest probably correct value .. which only 'works' for errors under a threshold.
Hence the assertion in comment above yours.
A 32 bytes hash for every 32 bytes? Then you double your storage requirements.
There are actually WAY better algorithms for this than a hash (a hash is meant to handle secrets and cryptography - it's the wrong thing for this purpose).
ECC codes can tell you if the data is bad - and you can choose how many bytes this covers, and that can also fix bad data, again, you can choose how many errors per byte you want.
If you are curious: https://en.wikipedia.org/wiki/Error_correction_code
The rest of your comment is good, but I wanted to quibble with this: hashing is useful for a very wide range of things, and are one of the main building blocks of modern algorithms (hash tables being the best know).
Interesting ! At what point with today's high-capacity-disks (DVD etc), can we just say store the data x3 and take the value of the closest two ?
If the only thing we really want is "high-audio-accuracy" ?
A N bit checksum can at most distinguish 2^n different bitstreams as "100% accurate", and that is assuming there are no transmission errors in transmitting the checksum itself. This is proven trivially by the pigenhole priinciple.
And for most media, the checksum is itself transmitted over a noisy channel like the rest of the data.
Read your link carefully.
Regular error correction + checksum is a pretty solid implementation of that.
Another way to see it - care to list any error code used anywhere with zero error rate?
Read the paper. Shannon write about this in his 1956 paper and subsequent work analyses further, but it's theoretical, and probably not practical for any real world error codes.
So if noise in the channel could turn a 0 to a 1, or a 1 to a 0, then there is never a positive zero-error rate.
This is explained in the paper, page 9, second column.
So this is an interesting math question for channels that don't occur in practice, and has resulted (as far as I can tell) in no working codes usable even in labs. It certainly does not apply to transmitting binary data over any noisy channels or media, which is where most if not all error correction codes are actually used.
You have a skewed perspective of growing up with ubiquitous computing and cheap ICs. This was very much not the case in the early 70s when CDs were designed. Trying to simultaneously design for high fidelity audio and a then completely theoretical demand for data storage would have made no sense and would be unjustifiable scope creep. The spiral groove of a CD is objectively better for a low cost linear playback device - even though it is obviously worse for random data access (though modern DSP mitigated this 15 years later). Engineering is about trade offs.
There’s no binary best effort vs dead sure - it’s a matter of degree, unlike the mistaken GP post, CDDA and CDROM both use RS error detection and correction, just the former has less of it - a CDDA (Redbook) can store about 15% more audio than would be possible with the equivalent WAVE files on a CDROM - at the expense of some redundancy, but it still has very robust error correction - otherwise every little tiny piece of dust would cause a skip. And for audio playback - trying to fill in a best guess is the right thing to do - rather than just making the thing spit the disk out with a failure.
This is not quite right. CDs use a forward error correcting code, and of course that means you can detect errors (how can one correct errors if they can’t detect them?). The CD drive most definitely can distinguish between an error free signal and a marginal one - both at the analog level and the digital level.
Most CD drives firmware are a bit inconsistent in their ability to correctly provide error correction information but this is not a fundamental issue with the technology and far from “no way to know” - relying on the drives error detection facilities is what the C2 error detection option in EAC does for instance. There are some drives that do well with this.
https://wiki.hydrogenaud.io/index.php?title=EAC_Drive_Option...