why didn't cd players ever re-buffer?

[cliveb]

"The hypothesis that making CDs easier to read has an effect on the jitter of the master clock has been shown to be unfounded in the Prism/DCA paper referenced earlier in this thread."

This paper is not relevant IMO. Anyone can write a paper and publish it on the web. Does the author have 30 years digital design experience? Was he a design lead on the Pentium 2?

Indeed anyone can write a paper and publish it on the net. Yours is an example, of course. The difference is that Dunn et. al.'s paper is a report of a scientifically controlled study.

You say the paper is not relevant, but it strikes me that it is absolutely relevant. Your claim is basically that differences in the pit geometry of CDs affects jitter arriving at the DAC, and the Prism/DCA paper demonstrates that it does not. Based on the methodologies used in these two studies, I know which one I prefer to believe.

I very much doubt that Julian Dunn was involved in the design of the Pentium 2. However, he did work for Prism, one of the foremost companies in the field of digital audio (designing their state of the art A/D and D/A converters), was a highly respected member of the AES, and was one of the leaders of the IEC team looking after the SPDIF specification. So I think he probably knew a thing or two about the subject. Sadly, he died about three years ago.

[cliveb]

If you have either of these CD's below, I will write new a low-jitter copy of one of them with my modded CD copier and ship it to you. Then report back on whether you can hear a difference between your commercial disk and my copy on a standard CD player. Then, I want you to rip a track from the copy and the original commercial CD and see if you can hear any difference between them when played back from the computer through the SB. This should settle it once and for all, assuming that your system is resolving enough.

CD#1 - Nora Jones - come away with me
CD#2 - Miles Davis - Kind of Blue

Unfortunately I have neither of those CDs. More to the point, I no longer own a high quality CD player, having sold mine after buying an SB2. (You see, I do actually believe that computer based playback is a step forward - just not for the same reasons as you). I doubt that either of the kids' CD boomboxes would be considered sufficient for such a test :-)

In any case, such a test would be pointless. If I were report that there was no audible difference, you could simply suggest that either my system is not revealing enough, or I'm deaf, or I'm lying.

[opaqueice]

The crystal or crystal oscillator that drives the PLL is replaced with a Superclock. It is still a PLL driven by a fixed frequency clock, but the jitter contribution of the clock itself is reduced.

Steve N.

OK, I'm not an electrical engineer, so probably this is a stupid question - but I still don't get it. As far as I understand, there is a PLL locked to a crystal oscillator in the CD player. The data stream coming from reading the disc will be jittery, as you're saying, and I suppose the output of the PLL could be sensitive to that and therefore jittery. This is the clock that controls the rate at which data is read into the buffer. However it's not clear to me why you would want or need to use this as the clock for reading out of the buffer or for the DAC.

The point is the AVERAGE frequency of a PLL clock is very very close to identical to the frequency of the crystal oscillator, or an integer multiple of it (at least based on the little I know about PLLs). So why would you use the output of the PLL as a clock for the DAC and/or buffer readout, when you could simply use the crystal itself? A problem (with buffer under or overflow) would arise if the AVERAGE frequencies of those two clocks differed, but I don't see how they could. So all you would need is a buffer large enough to withstand the variations due to the jitter of the input clock - and that's very very small. In fact naively it doesn't need to be much larger than one bit, unless the jitter is so bad it causes bit errors (in which case all bets are off anyway).

So unless there's some reason you can't use the crystal as the clock for the DAC, or I'm wrong about the average frequencies, it seems that the buffer insulates you entirely from jitter in reading the disc. Am I missing something?

By the way, this has been a very interesting thread for me - I've learned a lot, and thanks to all that have participated so far.

[SoftwireEngineer]

Re: the Prism test - I am not sure it is highly objective. Looks like it must have been done with an agenda i.e. jitter rejecting DACs are a must to have good playback. Saving grace, they say the work is on-going. Read the part below -
"None of the disc-related or servo-related artifacts was present
for any two-box system: jitter-rejecting DACs were generally
clean, as shown in the figures, whereas the spectra of non-jitter rejecting
DACs were swamped with interface-jitter-induced
components which were large in comparison to the artifacts
noted above in one-box players."

The study would have been more clear and less confusing if the DACs were not involved in the picture at all. The jitter should have been measure in the digital output of the players (like in this article http://www.stereophile.com/features/368/ )

Ultimately, It is still not clear to me that all CD players have a 'buffer' which isolates them from the disc quality. We probably should get more into the specifics, I guess, like what chips have buffers of what size and how they are actually clocked in and out. Steve, has already mentioned that portable players are surely buffered, not to mention the CD-ROM based ones. So probably there are some players which are probably immune to disc issues.

[audioengr]

OK, I'm not an electrical engineer, so probably this is a stupid question - but I still don't get it. As far as I understand, there is a PLL locked to a crystal oscillator in the CD player. The data stream coming from reading the disc will be jittery, as you're saying, and I suppose the output of the PLL could be sensitive to that and therefore jittery. This is the clock that controls the rate at which data is read into the buffer. However it's not clear to me why you would want or need to use this as the clock for reading out of the buffer

This clock MUST be used for reading the data out of the buffer, and this is the case. Any other asynchronous clock would cause underrun or overrun. It MUST be a PLL based on the actual bit-rate from the spinning disk. This is a real-time system.

The point is the AVERAGE frequency of a PLL clock is very very close to identical to the frequency of the crystal oscillator, or an integer multiple of it (at least based on the little I know about PLLs). So why would you use the output of the PLL as a clock for the DAC and/or buffer readout, when you could simply use the crystal itself? A problem (with buffer under or overflow) would arise if the AVERAGE frequencies of those two clocks differed, but I don't see how they could.

I see what you are getting at and it makes sense. It should be possible to do this, however I'm quite certain that this is not how it is done. There are evidently other reasons why the PLL clock must be used. The "raw" clock in the transport or player is generally not used. It is probably because the buffer must be much larger than you think and will add cost and complexity to the device.

I know this for sure. If you take steps to reduce the jitter on the CD itself, this makes a marked improvement in the sound quality, particularly the detail in the high-frequencies. This is consistent with reducing jitter. If this were not the case, and only improving the clock itself improved the sound, then I would be inclined to believe that the only the clock generator jitter was important. I have done a number of demonstrations at CES in the past 2-3 years where the listeners could hear the original CD, the copied CD, then a modded Transport and finally the same track only computer-driven. In every case the listeners were able to clearly hear an improvement due to reduction in jitter.

This thread has taken enough of my time. I'm too busy to debate this ad infinitim....

Steve N.

[Konig]

Steve i know u are a big proponent of I2S instead of reclocking

However im still curious to know if it is possible to add a wordclock or superclock input function to the squeezebox? I believe this will save alot of people the need to buy the transporter for their digital out only.