With coding dead-sure correct isn't usually much different in capacity -- you usually don't need to sacrifice bandwidth completely to get reliability. In fact,

With coding dead-sure correct isn't usually much different in capacity -- you usually don't need to sacrifice bandwidth completely to get reliability. In fact, a simple checksum with a good number of bits (e.g. CRC32) will pretty much give dead-sure accuracy (non-adversarial, you can hash e.g. SHA256 to get cryptographic certainty). If errors were evenly distributed (independent and identically distributed bit flips), it's generally very easy and well known how to obtain dead sure error correction, and the bandwidth you get is known as the channel capacity (C) of the medium (usually in bits/bit or bits/symbol) -- a "good code" operating at a rate R < C (under or equal to capacity) will give you this property; good codes, depending on the error rates, require moderately large block sizes (usually from 8b to 1-2kb in practice). 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_correction#/media/File:RS_BER.png https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_cor...