Achieving bit-perfect rendering of audio CDs

Question

I am aiming to get bit-perfect rendering of audio CDs and wondering about the necessary configuration.

Currently I have:

• A high-end CD transport without a word clock
• A high-end RME sound card with a word clock module
• A very high-end DAC with a word clock output and precision internal clock

I guess that, from the sound card to the DAC, I am probably good because the word clock will give a bit-perfect transfer. So, for example, if I have a sound file on the computer, then the card should be able to deliver the exact sound file to the DAC.

The question mark is how perfect the read from a CD will be to the sound card. Do I need a transport with a word clock? The transport has a coaxial S/PDIF which goes up to 192 Khz (the max) but no word clock.

There are CD transports with word clocks, but they cost as much as a new automobile. So I don't want to get one of those unless the standard high-end (sub-$1000) transport cannot deliver bit-perfect playback.

One possibility here of course is that no transport can deliver bit-perfect playback. So it is just shades of gray at some point, but I don't know enough about how audio tracks are pulled off a CD to be able to answer that.

Answer 1

tl; dr: want 'bit-perfect'? Use SPDIF to the sound card, or just 'rip' the CD. The data you get from SPDIF doesn't need to (and shouldn't) be oversampled - that only matters at the DAC itself, which will do its own oversampling.

To achieve 'bit-perfect' rendering, that is, an exact bit-for-bit copy of a CD, you will need to use an all-digital path with no analog steps in between. Any analog conversions, be they the transport DAC or the sound card ADC as you propose, will inject some amount of difference from your original bits on disc. The amount of difference will depend entirely on the quality of those conversions.

Also, an analog transport DAC path to the sound card ADC won't have a matched sample rate. There will be some time-code drift in source vs. capture. This can be eliminated if the transport clock is locked to the same clock as the sampling ADC (or vice-versa), but as you said, this requires some specialist ($$$) gear.

On the other hand, if your sound card accepts SPDIF input you can use that instead of the ADC. This solves both the analog distortion and sample-rate matching. The SPDIF data you capture (along with subcode) will be the same as the original disc, and they will have sample-for-sample source timing exactly as they were laid down on the disc. Even the crappiest CD player will deliver perfect bits this way.

On the other, other hand, you can just rip the CD digitally and dupe it that way. This would be much easier and faster, as you can rip at whatever X speed the CD- or DVD-ROM drive can handle.

Now, to this business of clocks and fancy transports...

First, CD isn't like an LP record where the linear track delivers its information directly. Nor is CD subject to 'wow' or 'flutter'. That's because between the CD's raw pit-and-land physical coding and the audio PCM data sent to the output, there's several digital layers, and those layers are decoupled from each other by data buffers.

CD data are arranged in frames of 588 EFM-modulated raw channel bits, yielding 264 demodulated bits (33 bytes) divided as 6 stereo samples (24 bytes), 8 CIRC bytes, and one subcode byte per frame. These raw frames are read, decoded, buffered and processed with Reed-Solomon error correction into the final product: PCM and subcode data. These are what are ultimately delivered to the DAC and SPDIF interfaces, not the raw pit-and-land encoding on the disc.

The disc read channel system and audio outputs share a common clock reference (a popular one is 384fs, or 16.9344MHz.) The audio outputs (DAC and SPDIF) are directly locked to this clock, and sink data at a constant rate. The controller's job is to present the DAC with pure bits at a constant, flutter-free rate.

The disc, being a mechanical thing, has tolerances that cause variation in its raw data rate. The read channel controller adjusts the disc servos dynamically to compensate for this. But this adjustment isn't perfect, so the read channel controller has some elastic buffering (FIFOs) to allow not only for the disc speed variation, but also the data block processing overhead.

(Some CD players - especially portable ones with anti-skip - buffer several seconds of audio data to cover loss of servo due to mechanical shock. They spin a bit faster - 1.5 to 2x - so they 'read ahead' of the DAC.)

The read channel controller produces data from the wobbly, blocky, and sometimes-skippy disc as an error-corrected stream, at the average 44.1KHz rate related to the master clock. In contrast, the DAC and SPDIF consume the data at an exact 44.1KHz rate directly synchronized to the master clock that never varies.

So the notion that the disc somehow sets the clock rate is completely backwards. The master clock rate sets the disc's average read rate, and the read channel controller dutifully follows along as best it can. However, because the read channel and DAC + SPDIF are separated by an elastic buffer, the processes of managing the servo and decoding the data have zero influence on the PCM data rate itself, which, remember, is directly locked to the player's master crystal reference.

That said, the CD player's delivered PCM data may have some clock jitter (good players will have less.) Clock jitter is undesireable as it can modulate the DAC output, leading to distortion. In DAC playback, this jitter can be smoothed out by a quality back-end DAC that has jitter-reducing clock recovery. As a practical matter, good CD / DVD player designs place the master clock source close to the DAC, using careful low-jitter design for the cleanest, harmonic-free clock possible. The clock is then buffered sent to the rest of the system which can tolerate more jitter.

What about SPDIF? What you get from the SPDIF port is exactly what's stored on the CD: PCM + subcode, minus all the channel coding and error-correction overhead. If you capture native SPDIF to a digital file, then jitter (and clock drift) don't matter. You get perfect bits that have the original sample-for-sample timing, plus correct subcode data.

If you feed SPDIF to a DAC, that SPDIF can have some source jitter. So a good SPDIF-input DAC recovers the clock and smooths it further to make a local, low-jitter / low-harmonic master clock to further reduce DAC distortion.

But, even with the best careful system design and advanced DAC architecture, it's still analog output and thus will never be bit-perfect with the digital source.

Answer 2

It is quite important to test for bit-perfect-ness because sometimes you get surprises.

For example, that old junk CD723 had an undithered digital volume control that couldn't be set to 0dB. Its maximum setting was a bit lower than 0dB. So it would multiply all the digital data by something like 0.99 and then truncate it to 16 bits, who cares about dither. It did that even on the SPDIF output, so I recorded it on the PC, ABX'd it versus the ripped CD, and the buggy processing in the CDP was definitely audible. It manifested as all the sweet reverb and details disappearing. It makes perfect sense, because a proper CD with at least 12-16dB dynamic range uses only 11-12 bits most of the time, so you really need that LSB dithering that's embedded in the recording, and messing with the LSB destroys the mastering engineer's good dithering job.

How to test a CD player for bit-perfectness:

Burn a CD with a test WAV, play it on the CDP, record the SPDIF output with your soundcard, and compare the files. I used to do that with a python script so can't recommend software, but on linux you can also just use diff. You should use a software that will skip the extra silence at the beginning of your recording. If the two files are identical (except the silence of course) then it is bit-perfect.

You can do the same test by recording the output of the CDP, then ripping the CD, and comparing the files. They should be identical, minus the silence at the beginning and end.

You can do the same with your soundcard in loopback. Output a WAV on the SPDIF output, record it, compare. It is quite useful to detect driver or software bugs that will do funny things to the audio, or that sneaky windows resampler.

You will most likely be disappointed though: all properly working CDPs will read a CD bit-perfect, unless there is a firmware bug like CD723. I tested a €30 multi-MP3-DVD player and of course the digital output was perfect. Absolutely all the audiophile woo about transports is just superstition. Green markers, blah blah, gold plated CD-Rs, this has zero effects on the actual data.

Likewise all soundcards are bit-perfect if used in a mode that enables it, like ASIO, unless there are bugs or special sound effect options that can be enabled or disabled separately.

Digital audio read from a CD is bit-for-bit identical to the same file played on a computer's SPDIF output (unless, as said above, the drivers do funny stuff, but it you test it, you can check that the bits are the same). Likewise the bits are the same on optical or coax, no matter how much the cable costs.

SPDIF includes error checking codes. If you want to experiment you can wire a LED to the ERROR output of the SPDIF decoder. The only way to light it is to unplug the SPDIF optical fiber. It is very robust.

So, do the test, and most likely if your hardware is working and your software is not buggy, you will find out that all the bits are transmitted perfectly. This is important, because instead of wasting time on woo-woo, you can fix actual problems and make actual improvements.

If there are differences in sound quality between two transports, using the same DAC, and both are functional (ie, bit-perfect) then the differences are entirely due to clock jitter and EMI. This is another huge can of worms, which tends to be called "woo-woo" by objectivists.

Yes you can measure a difference in jitter by placing a brick (or the gold plated audiophile equivalent, probably granite) on the transport, or mess with these cute spiky feets, etc. It tends to not be relevant, and to indicate the device is cheaply designed, but the effect exists.

So yes there are huge sound quality differences between transports, and it's not the bits, it's jitter and EMI, and what it mostly indicates is the DAC's inability to do its job of rejecting that. So if a transport sounds a lot better than another, it's not because the transport is great, it's because the DAC sucks. It's like the suspension on a car. If "this road feels so much better than this other one", it's not really the road, just fix the suspension.

Important: If your transport does "upsampling" (the marketing term for "oversampling") then the bits on the SPDIF output are not the bits on the CD, because the signal was oversampled. If the algorithm is not buggy, this is absolutely fine, but if you want to test for bit-perfect-ness, of course you should disable it for the test. Likewise if you do the test with the soundcard, make sure there isn't a sample rate conversion plugin somewhere in the chain. Otherwise you get an original 44.1k WAV and a (say) 192k recorded wav, and there is no point in comparing them.

The question mark is how perfect the read from a CD will be to the sound card.

It will be what's on the disk, unless the CDP is buggy or upsamples.

There is a difference with scratched CDs though: if there is a read error, which is very rare but happens if it is badly scratched, the CDP will hide it by interpolating the missing sample from its neighbors. So you may get an occasional sample that differs from the actual data on disk, if the CD is damaged. That's actually what you want, it's better than a loud click due to a read error. If the CD is in reasonably good condition, it NEVER happens.

If your goal is to rip CDs, just do it with your computer. Use Exact Audio Copy and make sure the drive in the PC reports C2 errors correctly, so if a CD is scratched, it will read again or give up, and not output a WAV file with loud clicks. This gives bit-perfect rips.

Now if your goal is to listen to the CD, then... just sell the CD player, and play the ripped file on your computer with the soundcard slaved to the DAC's wordclock output. If the DAC has a master clock, this option ensures the least possible amount of jitter.

Also there is confusion: word clock has nothing to do with bits, in fact it has nothing to do with the data. It's about synchronization. If you use several ADCs in your recording studio you want them all synchronized so the tracks line up sample by sample, so they have to be synced by word clock. And in your case, the DAC outputs a clock and the soundcard synchronizes itself to it, so the DAC doesn't have to do the jitter rejection job.

Storytime

How to make a CD player sound better with a brick.

Due to vibrations in the room, like music being played, everything vibrates, including the spinning CD. It also wobbles because it can never be perfectly flat and centered. Likewise the track itself is not a perfect spiral, it can have some wobble.

The actuator coils in the optical pick-up keep the lens assembly aligned with the track, both horizontally and vertically. It's a pretty tough job, because the track is only 500nm wide and going very fast past the lens. So the coils eat up quite a lot of current to do the job.

And... the actuator coil current pretty much mirrors any vibration on the CD. This draws current from the power supply depending on ambient noise, vibration, ripple in the track, etc. It's basically a large microphone.

If the power supply is cheap enough, and you stick a scope probe in it, you will notice a huge amount of ripple that depends on ambient noise. On the CD723 it was so bad that someone walking in the room would cause the power supply to dance on the scope, just from vibration. Due to the low PSRR of the logic supply, this found its way into the rest of the circuit, and as a result SPDIF output jitter was visible to the naked eye on the scope, with the SPDIF trace wiggling around at the slightest vibration.

The usual audiophile solution is to make a very expensive and heavy machined aluminium chassis (or put a brick on it). A better solution is to build a proper power supply with the important bits having good PSRR. Or just use a computer to play the digital file, which removes the problem.

And so all the audiophile tweaks, the spiky feet, the granite slabs, the super heavy stands, all the woo-woo, it actually does something. It works! It solves the completely wrong problem, which is actually PSRR, but it's not magic at all. And the more it works, the more you know the CDP's power supply's low PSRR feeds the ripple from actuator coil current where it shouldn't be, and is therefore garbage.