Has anyone looked at the actual error rates of a buffered packetized plesiochronous system like the SB3 vs the isochronous bit transport system of a CD transport?
My experience with EAC was that 20% of my CDs came through with no errors recorded in the log. 20% of my CDs had significant error rates (many tracks, many errors). About 60% of CDs had "some" errors - a couple of tracks and error rates around 1%. There is nothing special about my CD collection - I have always taken good care of them, so I see no reason to think my experience is not representative om the "good" side. A 1% sample loss rate on bit oriented CD readback would seem to me to be very high. On voice codecs this would be noticable and very bad. I would have to think this would also transfer to music perception. So, unless a CD transport designer has gone to alot of trouble with actual buffering and multple reads and other data oriented error detection efforts, I don't see how the SB3 with FLAC files and EAC ripped CDs could be anything other than a significantly lower error rate. Certainly, you can get this improved error handling at a fraction of the cost of a bit accurate CD transport. The transition from bit isochronous to buffered plesiochronous (not quite async, not quote isochronous) has been underway in the Internet for 15 years. With the creation of VoIP based telephone systems the transition is complete, and the last claims of the hard core isochronous defenders is dying off. So, I would suggest that just moving off CD isochronous bit transport into error detected and corrected packetized transport would get you a better sound because you get a materially lower error rate. This isn't quite what you meant, I am sure, but I suspect it has a lot to do with a perception of "better". It will definately be more error free. (To those who would jump on my use of plesiochronous - the term these days has been stretched to mean systems with clocking on each end that can be far apart, not just a little apart, with buffering to fix the (potentially big) clock slip issues. Asynch still means no clocking, which is not true of a media stream. The stream does not have to have end to end clock integrity, just local clock integrity). -- Eric Carroll ------------------------------------------------------------------------ Eric Carroll's Profile: http://forums.slimdevices.com/member.php?userid=9293 View this thread: http://forums.slimdevices.com/showthread.php?t=31203 _______________________________________________ audiophiles mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/audiophiles
