Digital jitter and disk treament tweak


I've been doing some initial research on audio digital jitter to understand why or how disk treatment could be used to improve the sound quality. As is the case of digital audio, there are a lot of misconception and confusion because there is an inter-relationship between the digital domain and analog domain and they both affect each other. I know there have been plenty of discussion on this forum and on audio asylum but I feel none of the discussion so far have come to any satisfactory conclusion. It seems like at the end of the discussion, nobody was able to agree on anything. Part of the reason was that no one would agree on the concept of how data are read from the cd then delivered to the DAC in the first place.
So in order to clear up some of the confusion or misconception, I would like to start a meaningful discussion that hopefully will help everyone to have a better understanding of digital audio and jitter in general. My initial discussion is by no mean complete but I hope other will try to add or clarify what I have here. I try to be concise and to the point so please be patient.

First off, when we talk of how jitter affect the sound, we often refer to the jitter of the clock at the DAC stage, or specifically, the clock that is responsible to input (or latch) the data (from the transport) into the DAC. Supposed we have a perfect clock with zero jitter for our DAC, then any amount of jitter of the data in the world would have absolute no effect on the output of the DAC (given that data jitter itself is less then the period of the data frequency). The problem is that in some cases, the clock jitter at the DAC is affected by the jitter of the data stream that comes from the transport. Therefore the more jitter the data has, the more jitter the clock will have. Things are further complicated when the transport and DAC are housed in different units in which case data have to be synchronized since they are operated by two separate clocks – one for the transport and one for the DAC. From the transport perspective, the clock is responsible for clocking out the data to the DAC, since the more jitter the clock (of the transport) is, the more jitter on the data will be (the biggest misconception is that most people believe that the data jitter is the jitter we all try to minimize. It’s the jitter of the clock that clock the data out to the DAC that we try to minimize. Once the data has been transported out to the DAC, there are not much we can do). In turn, the jitter of the data will cause more jitter on the clock of the DAC since the DAC has to some how synchronize itself to the incoming data, not to mention the clock of the DAC itself has its own jitter.
The design is simpler if both the transport and DAC (which is true for most cd players) are in one unit since they can be all synchronized to one single clock. If this is the case then I believe data jitter has very minimal effect on the clock, but it does not mean that interfere from the transport does not effect the clock jitter. In most one box design, especially in mid or low end cdp, the clock power supply and grounding are shared with the transport digital circuit so noise from digital circuit will add jitter to the clock. In expensive player or transport, the clock could be isolated from the rest of the digital portion, therefore the effect is minimize, but since everything eventually shared the same transformer and ground, the clock is therefore not entirely inmuned from the noise from the transport digital circuit.

Let’s look at a two most common things that can cause noise to the clock.

1. Error Correction: I believe that the more this circuit need to work, the more power it consume therefore causing power fluctuation on the power supply (that is also shared by the clock) thereby causing noise or jitter to the clock. The other thing error correction can have adverse effect to the sound is that sometimes, the circuit needs to interpolate between two points because of data corruption. Too much interpolation will directly alter the sound signal since the interpolation points are not necessary the same as the original points stored on the disk.

2. Motor Servo Control: The motion or speed of the motor is also controlled by the clock. The motor is constantly has to adjust itself while reading the cd. If the motor has to work harder, it will cause more fluctuation to the power supply and will add more jitter to the clock.

There are other things which will cause jitter that I am still looking into.

With disk treatment, at least the theoretical level, it helps to minimize noise from 1 and 2.
This is a direct quote from a review of the Auric treatment:

“…The gel is an optical treatment that lowers the static charge on the disc’s surfaces as well as improving the optics by allowing the laser pick-up to enter and leave the disc with less reflective or refractive interference. It should be applied to each side -information and label. According to Richard Smith, as the disc spins against the air, a static charge builds up and discharges into the surrounding air or surfaces. This charge/discharge cycle (allegedly) causes the disc to tilt or wobble making it harder to track accurately, causing timing errors. The laser pickup servomotor has to work that much harder to constantly correct the laser’s position, thus causes more pulsing of the power supply. The deleterious sonic nastiness that accumulates from all this noticeably disappears when addressed by the Auric Illuminator…”

Most of the above statement is mostly accurate except for the fact that it seems to imply that timing errors are caused directly from less than ideal data read back from the disk. The effect is extremely indirectly related as I discussed above. The data is clock by a master CLOCK whose timing is has nothing to do with the data itself. The cause of the jitter is indirect.
With painting the disk by various color, the improvement comes from the lack of error circuit activation which minimize power supply fluctuation and interpolation errors.

With recently more advance design which employs what called close-loop Clock feedback currently used by Wadia (I think it is called Clock Link System) , there is only one master clock that is located physically very close to the DAC itself. This clock is then distributed to other part of the cd including the transport even if the transport is housed in a different unit. And because of the clock close proximity to the DAC, any jitter would be very minimal and the effect from the transport for all intent and practical purpose is nonexistent. For this type of implementation, I believe disk treatment would have very small or zero effect to the quality of the sound.

Other company such as Chord DAC64 uses a very large buffer to minimize effect of short term jitter, but long term jitter is probably still a problem. I am still trying to understand how the DAC64 synchronize itself to the coming data. If anybody knows where to find any document, please let me know.

Sorry for the lengthy discussion but I hope the discussion above will help somewhat. If there is anything inaccurate, please give us your opinions.

If you have any questions, please present them since they are beneficial to our discussion.

Thanks for reading.
andy2

Showing 2 responses by audioengr

Laziness - I doubt that. The problem is how to deliver all of the current features of typical CD players and use a cache-based system to do it. This is not a trivial exercise. The buffer management must be done with an imbedded processor to get all of the typical features, which means that in addition to the buffers and CDROM drive, they need microcode to control the buffers to insure that you can fast forward and skip forward and backwards without waiting 30 seconds to hear the next track. It is quite likely that Meridian has done just this, but I'm sure it took a considerable investment in engineering resources and time.
Eldartford wrote:
"The serial data would go into a buffer register and then clocked out at a perfectly uniform rate. Perhaps the common CD player is not built this way, although I can't imagine why not."

You are correct that this technique would yield the least jitter. The reason that most manufacturers do not do this is that typical transports read at the standard data rate, instead of much faster. CDROM's of course read faster. If you buffer the data, you have to have very large buffers or read the data from the disk much faster than the native rate. Otherwise you get buffer underrun - drop-outs. Also, it is difficult to do fast-forwarding and skipping if the data is already in the buffer - you would have to flush the buffer and then wait until it fills again before your could play the music. This is essentially a "cache-based" data retreival system, just like the data cache buffer in your Pentium 4. If you have a cache miss in these systems, then you pay the penalty of waiting some latency for the data to arrive.

Somehow, the same folks that do the microprocessor design (my former life) and the folks that do the consumer electronics design have not cross-pollenated enough to make such a cache-based system a reality. You would think that they would be quite common. The only place where I have seen this as ubiquitous is in the portable CD players with "shock" buffers.