smc2911;278662 Wrote: > Good point. So I'd summarise in terms of three levels of redundancy: > > 1. You know it's there in principal, but it's not useful. > 2. You use it to identify a problem (e.g. CRC) but you can't do > anything about the problem. > 3. You use it to correct errors (ECC). > > 2 and 3 come in degrees depending on how many errors they can deal with > before they stop being useful.
Exactly.. except I would say #1 is only valid for things like TCP/IP transport with wav files. You get the TCP checksums, but it's not inherent to the audio encoding like FLAC. So just to make the audiophile community twitch a bit. The 16bit checksum used by TCP is not exactly the best. It catches most errors, but I have personally seen corruption happen in live networks. Of course this was a network switch handling many many gigabits of traffic, and the error rates were so bad that it was causing 50% of packets to be dropped because the checksums didn't match.. but when you're doing gigabits of traffic and .0001% of the packets are corrupt in some way but still pass checksums get through to the application layer, you see strange things happen. Thankfully the likelyhood of this causing audible issues with the squeezebox are very very low. -- SuperQ ------------------------------------------------------------------------ SuperQ's Profile: http://forums.slimdevices.com/member.php?userid=2139 View this thread: http://forums.slimdevices.com/showthread.php?t=44532 _______________________________________________ audiophiles mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/audiophiles
