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.
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
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" ?
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).
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.
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.
Regular error correction + checksum is a pretty solid implementation of that.
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.
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...
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.