JezA JezA;510409 Wrote: > If you spend hundreds of pounds on a Naim s/pdif lead, is it the zeros > that are more 'zero-ey' or the ones that are more 'one-like'? Do you get > more 0s with a Naim lead, or more 1s? Do they come in a different order? > Did they go to a better school? The Naim DAC purports to buffer and > re-clock the data; it doesn't retrieve the clock-signal from the data > stream, so surely if the design is any good it should work with any > vaguely decent lead, unless of course it is susceptible to other kinds > of intereference, such as RF, which would be a pity in such an expensive > product. >
I am not arguing in favour of using 100's £ on digital cables. I'm simply saying two things. a) That this (expensive cables) is how things work in hi-fi everywhere. b) That there is a technical good reason to support the importance of the quality of the s/pdif cable. I am not asserting anything on how a) and b) relates to each other. In fact I tend to agree with your sentiment. JezA;510409 Wrote: > > "Do it right" at the very least means doing it in such a way that > s/pdif leads are not part of the solution, for the very reason that, as > you tell me, they can affect the sound of a (re-buffering re-clocking) > DAC! If you have a cd transport, s/pdif is a pretty much unavoidable > necessity. If your data is on a hard-drive s/pdif is completely > avoidable, as the Transporter, Squeezebox and Linn DS gear > demonstrates. > > Also, it is unclear how the Naim DAC works. If there are 10 close but > different clocks which are switched between intermittently to keep the > buffer from over or underflowing then that itself is a form of jitter > and/or imprecision; but if those 10 clocks belong to different sampling > frequencies (ie 32, 44, 48, 96, 192, etc) then the buffer must over or > underflow at some point. If the buffer was just kept topped up over the > network such issues would not arise - why pick a clock which 'nearly' > matches the one in the s/pdif signal when the correct frequency is in > the file header!???! Its not unclear to me, but apparently it is to many. I'm in fact presently engaged in a discussion at the Naim forum where I'm trying to explain how the jitter-rejection part of the DAC works*, so although I would like to comment here I provide a link to that discussion as to avoid writing the same twice. There is of course also the whitepaper which says it all. http://forums.naim-audio.com/eve/forums/a/tpc/f/8772903417/m/8602935827 Though as an answer to your final question I can say that one clue is to consider the relationship between jitter and data-rate. The frequncy is not in the "file-header" of anything received by the DAC. I don't know what a "file-header" in S/PDIF is. The clock is encoded in the data-stream. The 10 clocks are inteded to (approximately) match, *not* various audio-frequncies such as 44.1, 48, 88, etc, but rather some interval around any fixed one of those, say 44.1. -- bhaagensen ------------------------------------------------------------------------ bhaagensen's Profile: http://forums.slimdevices.com/member.php?userid=7418 View this thread: http://forums.slimdevices.com/showthread.php?t=74471
_______________________________________________ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
