CD Transports: Data Drops Etc...

This isn't what you want to hear but - You can't get there from here.

The analysis you are attempting is an interesting intellectual excercise but will have no correlation to picking a cd player that you actually like!

I'm on my third set of speakers, third power amp, second pre-amp, went through 2 dacs and 2 cd players - all because I tried to 'figure out' the answer ahead of time. It would have been much easier to invest the time listening to as many components as I could and simply pick what I liked best.

There are so many factors that determine the final sound that you can't really break it down to pieces, add the individual scores and then assume the final product will equal the total score.

I know this is agonizingly low-tech but you just have to listen to as many players as you can in your own system and pick the one you like best.

Happy Listening!

- A

Some of this is a question I have tried to understand the answer to for a long time, to no avail. It sounds trite (or obvious) to say that the job of transport is to read the data on the CD and deliver it faithfully to the destination, in the case of music, the DAC. Given that a $50 CD drive in a computer can read a CD at much faster rates than is required for audio playback from a redbood CD, and deliver it provably bit-for-bit to another location, all while in a horrible electrical environment and, if you like, with the computer sitting on it's side, leads me to wonder why any of these issues exist in the audio component world. I see only one of two possibilities:

1. They don't and the performance differences people confer don't actually exist, or

2. They exist because truly bad engineering in the transport-to-DAC design that is fundamental to ALL audio component CD players. Assuming everyone who hears a difference isn't looney (and I assume they're not), there should be a technical explanation that is understandable in engineering terms to describe why the cheap computer CD can do it but the audio CD player can't. I've never read one that was convincing.

I think the far greater difference you'll find between a Wadia 861 and a Sony SCD-1 will be in the filtering algorithms they apply to the data stream. -Kirk

For KThomas -

In the case of jitter the issue is insuring that the input of the dac sees the exact series of bits that came off the drive.

It is possible that the bits come off the drive properly but are seen as a different series of bits by the dac.

The dac wants to know the value of a bit at each clock tick and this involves sensing changes in voltage. A variety of factors can lead to the dac sensing an incorrect value.

So, reading the bits from the cd accurately is different than getting those bits into the dac with the proper timing.

I have intentionally not attempted to explain things that are beyond my knowledge. Hopefully an expert can jump in and provide more details.

Aragain - You're definitely right that reading the bits from a CD is different than feeding them to a DAC with the proper timing, but feeding the DAC isn't a whole lot different than feeding the mechanics to write data to a hard drive, and that's basically a guaranteed, bit-for-bit correct operation with even relatively cheap hardware. I won't even pretend to understand the output side of a DAC and all the things that could make one sound different that the other, but the input side is a digital interface, and digital data is how I make my living. Again, I don't know a lot about how a DAC is physically constructed, but I don't know why it couldn't be constructed with an input buffer such that you aren't clocking the data directly into the sample space in the DAC that is going to be generated next directly. Feed it into a, say, 8K buffer that in turn feeds the DAC. The buffer could be built right in the DAC chip itself, and I can't imagine arguing that perfect transfer couldn't occur from one part of the chip to another.

Another way of asking the question is why, if I can ship data 100% reliably all the way around the world at data rates MUCH higher than is required for redbook CD playback and recreate the data perfectly at it's destination, can't I engineer a solution to read a CD and transfer that information 100% correctly to another chip in the same physical box? This is especially confusing because I can turn around and do an apparently analogous operation on another electronic device that is cheap and non-optimized.

I've often wondered if high-end transports employ filtering algorithms on the digital data stream they produce. It would be very possible to read the data from the CD, apply a filtering algorithm to the bit-stream, and produce a 16-bit/44.1Khz compatible stream that is intentionally different from what is on the disc. With well executed filtering, you could certainly change the sound, possibly in a way many would prefer. I've never read a reference that explicitly says somebody's transport does this, but I don't see any reason why somebody couldn't to produce a distinctive sound. -Kirk

Followup to Aragain:

The CD system depends on the Nyquist Sampling Theorem, which states that a band-limited analog signal (22.05 khz for CD) sampled at at least twice the band limt (44.1 khz for CD) can be exactly reconstructed from the time series of samples.

A tacit assumption behind the Nyquist theorum is that the time interval between the samples be precise and equal to 1/fs, where fs is the sampling frequency (44.1 khz for CD). Any variation in the interval between samples AT THE DAC causes distortion (usually additional non integral high harmonics) in the reconstructed signal.

Thus recovering the data from the disc is only one part of the problem, and the easy part. That's why cheap CD rom drives have no difficulty extracting data from discs in computers. There is no time critical element involved in reading a file.

Audiophile CD transports have no problems getting the data either. It's the timing that causes problems. The clock signal usually starts at the transport (there are exceptions - see the Wadia 270 - 27ix combo). Any tracking problems from a warped disc may affect the stability of the clock at this point.

There are many opportunities for timing errors (jitter) to appear as the signal moves from transport to DAC. Almost all transport/dac seperates communicate using the SPDIF (Sony-Phillips Digital Interface) standard across coax or optical links. SPDIF combines the data stream and the clock together into one signal for transmission on one cable. The receiver at the DAC must extract the clock and data from the SPDIF. This extracted clock often directly becomes the timing reference to the DAC (though some processors go to elaborate lengths to stabilize this clock signal).

The SPDIF signal is itself an analog signal, and is subject to degradations in transit. Thses degradations can alter the waveshape so that the receiver has a hard time decting exactly when a clock transition occurs. This uncertainty is one cause of jitter, and is one reason that digital interconnects sound different.

I'm just scratching the surface here. Going back to T_bone's original note, one could say that the engineering is faulty. For example there are other bus schemes (I2S for example) that transmit clock and data on separate physical lines.

All things being equal (which they never are!) a single box player has an easier time of things since all components are under the designer's control and he/she doesn't have to use SPDIF to transfer data to the dac section.

Hi KThomas -

I'm in the computer game also and this same cd drive question has bugged me for a while.

One analogy is the old 'framing error' on a modem's uart where the uart's clock got out of sync with the sender's clock.

Still, it seems like this is a problem that has been solved already and could be built into a cd player.

I am trying to remember where I read a bunch of stuff about jitter. I suppose a web search would eventually turn up something insightful.

Cheers,
A

Ghost - Thanks for the info!

Still, this seems like a standard async communication problem (particularly in the single-box players) which has been solved in the computer data communications world. I think the serial rate on SPDIF is 2 mhz or 4 mhz.

If the dac is viewed as an async receiver (which I don't know if that's a valid view) then it seems existing engineering is available to get it right.

Still puzzled -
A

It's the framing error on a UART model that I have in mind for this data transfer too. Maybe that's the wrong mental model, and when I get the right mental model it'll be clearer to me. Certainly, one problem with digital audio playback is that these connections don't have redundancy built in (ie, no retry logic). However, I can connect two computers up via async ports (ie, UARTS) and write a simple program to send on one side, receive on the other, and report any chip-level errors, let it run for days and not see a single error, all without retry logic, etc. So, it still seems very solvable, at least to my level of understanding of the problem set.

I guess another way I think of it is this - what if somebody re-engineered the concept of a CD transport / DAC combination such that the transport didn't attempt to play it back real-time, but rather read the CD "in" and reliably loaded it into memory on the DAC. This would be akin to reading a computer CD into memory and, since you'd be re-engineering the interface, could base it on different technology. Then, the "CD" would play back from within the DAC's memory. I would think the whole issue of jitter would be moot with such a setup, and the whole notion of an expensive transport and expensive interconnects would be moot as well.-Kirk

Remember, that unlike an async serial data transfer between two uarts, the SPDIF signal contains both the data and clock streams intertwined. Unlike a uart, which knows a priori the operating baud rate, the SPDIF receiver must extract the clock from the incoming signal and then use this clock to derive the data stream from the signal.

Any distortions that round off the corners of the analog waveform making up the SPDIF signal cause the receiver to derive a jittery clock signal. In any digital logic, there is a transition zone between the voltages representing the logic states "1" and "0" that is neither state. A rounded off waveform spends more time in this transition zone, thus delaying the detection of logic transitions, thus affecting the derived clock signal.

This effect is not constant.

Improperly terminated coax (RCA plugs instead of BNC connectors, or bad transmitter/receiver design) will have reflections giving rise to standing waves which will cause distortion to the SPDIF signal.

Basic CD player design is still rooted 1983 technology. In those days memory and processor were expensive. I think that one could completely rethink the player design today, using current digital technology and its new price points.

Perhaps the CD drive (at 4x or better) could read ahead, and fill up a circular buffer. The data stream could then be clocked out of the buffer at a constant rate independently of the transport This scheme would even allow for retries of uncorrectable read errors, and would break the direct connection between data timing and transport timing. Of course we'd want to dump SPDIF as a connection mechanism...

I bet it would be easy to make using off-the shelf parts as well.