4 ms·
I think that "it either work or doesn't" only if the receiver has some kind of cyclic redundancy check before processing the signal. My guess is that very few
by cake 17y ago
I think that "it either work or doesn't" only if the receiver has some kind of cyclic redundancy check before processing the signal.
My guess is that very few digital A/V systems implement this. Proof of this is the weird sound you may hear on a damaged compact disc, it half works.
- micks56 17y agoThere probably are CRCs run during the decoding process, but CRCs only tell you "yes this is correct" or "no, something went wrong." There are additional protection schemes that can detect and correct bit errors. Those are probably also run during the decoding process. The problem is that you can only detect so many wrong bits in a given word, and beyond that no correction can be made. That is probably why the damaged disc half works.
- cake 17y agoYes it depends on the way you handle the response of the CRC, you could say "give me the data I don't care" or "please try to read it again it's wrong". In my opinion that is just the proof that it's not as simple as "it just works or not" but rather : depending on muptiple factors such as error correction and the way your algorithm works on the receiver it may "half work" no matter what kind of cable you plug in.
- ramchip 17y agoCompact discs use something far better (in that context), a combination of two interleaved Reed–Solomon codes called CIRC, which is error-correcting (and not just detecting like a CRC). All digital A/V systems have to implement this in order to read a CD. It's made to be strong against burst errors which is why it can handle scratches on a CD pretty well. Samples can also be interpolated if something's really unreadable. Even with an error-detecting code, there comes a point where there's too many errors to know if you received a valid code word or if the errors just "canceled each other". If 000 and 111 are your only valid words, it's still possible that a 111 gets turned into a 000 (3 consecutive errors) and there's no way to know about it...