Introduction
First of all, just to clear up what I'm talking about. A CD player consists of two parts : a transport and a DAC, where the transport reads the digital data (1s and 0s) from the disc and passes it to the DAC which creates the sound itself.
With most CD players both these parts are in the same box, you put the CD in and forget about it. However, one hi-fi option is to have these two parts separate. But why would you want to? Well.... for one thing many CD players have the output from the transport stage on the back (digital output) which means you can stick on a new DAC and give an old player a new lease of life. There are other reasons as well, keeping the electrical supplies separate, preventing interference and all that good stuff. So, if you want to you can go out and spend hundreds of pounds (or thousands if you want) on a CD player that consists of a separate transport and DAC. Money well spent?
Spending money on the DAC bit I have no trouble with, since the DAC has an analogue stage the 'quality' of this component will have an effect on the final sound, but the transport? All the transport does is to read 1s and 0s from a disc, and how can this vary between a recycled CD player and two grand dedicated transport? Not only that but the money spent on the connecting cable also (allegedly) affects the sound. I was skeptical.
Errors and jitter
The two reasons given by people who do believe in CD transports are as above : reading errors and jitter. Let's look at those...
One of digital's strength is its tolerance to errors, yet now this is in doubt. I'm basically a computer person and I know that I can go out and buy a computer CD-ROM for less than 40 quid that will read a CD at 24 times the speed needed for audio use. And it would be a reliable read too since with 'real' computer data an error isn't some vague feeling about the sound quality, but a real, measurable data error. OK, I accept the format of an audio CD and a data CD is slightly different, but it's the same technology. So the first theory is that if a £40 CD-ROM can read data reliably, why should I shell out £500+ for a CD transport?
What about the cable? Well, the hi-fi industry would quite happily charge £100+ for a 1m length of data cable, which they would claim, sounds better than a £20 cable. If the error idea holds water then the £100 cable should have less errors on it, right? Well, I can walk into any computer shop in the land and buy 1m of what is known as Cat5 network cable for less then a fiver. This cable is certified up to speeds over fifty times that needed for audio. Oh.
But regardless of all that, is this idea of errors credible at all? Personally, I think it shows a lack of understanding of how digital works. With analogue components a small change introduced in the signal does directly become a small change in the sound, and equally, a large change in the signal becomes a large change in the sound. But with digital it doesn't necessarily follow. Digital information is just 1s and 0s, the pattern of these determines the number they represent. Now, if I had sixteen 0s in a line (0000000000000000) the value would simply be 0. But... supposing during transmission of this pattern the last 0 got magically flipped to a 1? Well, the normal (decimal) value of 0000000000000001 is 1. OK, a small change in the pattern has made a small change in the output, just like analogue. However, if instead of the last bit getting changed it was the first, so the pattern became 1000000000000000? Well now the value is 32768, and that's a big change. The point I'm trying to make here is that with errors in a digital stream you're just as likely to make a whopping change as a tiny one. Also, any 'wrong' value will only be output for 0.00002 secs and I challenge anyone to hear just one error in a four minute recording, we'd need to have lots of errors for it to be really audible.
I'll come back to errors in a bit, but what about jitter? This is a catch-all term banded about by various quarters of the audio/video world and (to the best description I've heard) covers any small timing errors. For example, a DAC may have jitter problems and instead of output a sample exactly every 1/44100 of a second, sometimes it's a bit early and sometimes it's a bit late.
Now this in itself isn't beyond belief, if the DAC was slightly off with it's output timing, in effect the waveform would be getting stretched and compressed on a small scale, a bit like wow & flutter. But hi-fi bods don't just buy into jitter for DACs, oh no, they worry about transports and cable as well. Playing devil's advocate for a moment, how could this work? Well, if the DAC can only output a sample when all 32 bits (16 bits for left & right) are in, any timing errors from the transport & cable will have a knock-on effect to the DAC. But this idea disagreed with my computer background, moving data of audio speeds down a cable is not rocket science by a long way and it shouldn't be a big deal.
Transports
So onto the tests. First of all, I wanted to see if the choice of transport has any effect on the output signal so I chose two convenient transports in my computer, a Toshiba SD-M1002 DVD ROM and a Yamaha CDRW4416 CD-writer. Now both of these are good at their respective jobs but neither is a dedicated or optimised CD audio transport, so if transports do make a difference we should hope to see it here.
The test was doing an audio extraction of Hefner's 'Good Fruit' single via Audiocatalyst 2.1, the output WAV being checked using the MD5 checksum programme. The first results were:
| Drive | File size | Play time | Rip speed | MD5 |
|---|---|---|---|---|
| SD-M1002 | 36,938,204 | 3:29.4 | 3x | 0cb21482c5788bae3d05bad435724320 |
| CDRW4416 | 36,938,204 | 3:29.4 | 6x | 24c88c8d0d77e07a2894da99c867c2b7 |
So the file sizes are equal (which is good) but the checksums aren't (this is bad). The other thing I noticed was both readers recorded a click at the start of the recording, something I don't hear when listening to the CD on my hi-fi player. Anyway, I took the left channel from each recording and put them side-to-side in Cool Edit Pro and saw that the Toshiba recording started 1/1000th of a second sooner. This is no great shakes of course, but would muck up the checksumming. Also, viewing the waveforms in Cool Edit showed an offset between the two waveforms.
This offset isn't that important in the grand scheme of things, and neither is the click to be honest, it's the meat of the song which is interesting. So, next I lopped out the click of each sample and wrote a little Perl script to remove all the leading (near) silence which Cool Edit doesn't seem to remove that well.
After trimming the leading silence there was still no match, but this is hardly a surprise. Since the offsets were different yet the lengths the same I expected the lengths to be different, as they are. To make this fair I had to trim the run-out from the SD-M1002 recording to match the CDRW4416 one. Results below:
| Drive | File size | Play time | MD5 |
|---|---|---|---|
| SD-M1002 | 36,727,200 | 3:28.202 | 423cfbb73504aeadf50ada19f0f87993 |
| CDRW4416 | 36,726,972 | 3:28.202 | 423cfbb73504aeadf50ada19f0f87993 |
And voila! A perfect match. So now we've got 2 grabs taken from different drives matching perfectly, albeit one placed the whole song 0.0013 seconds ahead of the other. But, just to ram the point home I tried the same thing with another couple of drives I had lying around a Toshiba 5302 and a Toshiba 5701. Oh, you may be noticing I seem to have a lot of Toshiba drives, yeah well, I just like them. Anyway, the results:
| Drive | File size | Play time | Rip speed | MD5 |
|---|---|---|---|---|
| 5302 | 36,726,972 | 3:28.202 | 1x | 423cfbb73504aeadf50ada19f0f87993 |
| 5701 | 36,724,756 | 3:28.19 | 1.8x | a937ca123fa5605c8622657f2db03b6a |
| SD-M1002 | 36,724,756 | 3:28.19 | 3x | a7312cce93aaa8a758ecc1f276c40f27 |
OK, so let's look at these results. The 5302 is my old, old quad speed drive which hasn't had a clean in it's life and during recording it looked like it might have produced a skip, yet after clipping it was fine, so top marks to the old dog - especially as it didn't grab a click at the start. Now as for the 5701, this is a relative newcomer to the family, it's a 12x SCSI drive I picked up from a fair second hand to use with the Indy (although originally it came out of a Sun box). This drive had a terrible time recording with loads of synchronisation problems and sure enough it hasn't produced a matching file. The reason I've stuck another SD-M1002 result in there is because the 5701 had the largest offset yet so after I clipped the leading space off it was shorter than the others and would never had matched, so I shortened the SD-M1002 sample for a fair comparison.
So what have we got so far? Well, 3 out of 4 drives that agree to the bit of how an audio CD looks, and the one that doesn't has an unknown past. Also remember that none of these drives were designed just for playing audio, and that they've extracted the information up to 6 times quicker then an audio CD player needs to.
Above seems to prove a computer and CD-ROM can do a 'perfect' transportation job on an audio CD. But what about a real CD player?
The only audio CD player I have is a Kenwood DP-3080, which whilst not bad, is firmly in the budget bracket. For comparison purposes I needed to get the output from the 3080 onto computer and for this I had two methods. Firstly, I piped the (optical) output from the 3080 into a PC with the CMI-based Nightingale sound-card, and secondly the output from the 3080 is passed into a Midiman CO2 convertor to get it into an electrical signal and from there it was passed into a SGI Indy. I'd never done any 'proper' tests on the Nightingale or Indy for digital grabbing before, so this was as much a test of them as everything else. The results, after trimming and cropping, were:
| Device | File size | Play time | MD5 |
|---|---|---|---|
| Nightingale | 36,726,972 | 3:28.202 | 423cfbb73504aeadf50ada19f0f87993 |
| Indy | 36,726,972 | 3:28.202 | 423cfbb73504aeadf50ada19f0f87993 |
So there you have it, the 3080 (a £150 player) is capable of outputting a CD perfectly when just used as a transport. Also, both the Nightingale and Indy (including CO2) are capable of bit-perfect audio grabbing. Marvellous.
Cable
The other nice thing about the Indy grabbing the signal correctly was that it was using an electrical connection. Now, whilst the optical lead I used was a proper audio lead (£20 ish) the electrical cable was a random 3.5mm-to-RCA lead I had lying round, and it worked fine. So... how far could I push it?
The 3.5mm-to-RCA lead was cut and I added into the loop 2 lots of 4m speaker cable, I didn't bother soldering the joints, just twisted the cables together, and then made another recording. Before I did any comparisons I did another test with the same wiring except with a wire coat hanger between each of the 4m lengths of speaker cable, so the set-up was now :
| ^
| |
+---> 4m cable -> coat hanger -> 4m cable ----+
So after all the trimming etc., did these grabs match? Well, no, they didn't which was disappointing. Curious, I ran a quick difference script to find the number of errors in each result.
| Setup | File size | Play time | Number of errors |
|---|---|---|---|
| Just cable | 36,726,972 | 3:28.202 | 2 |
| Cable + hangers | 36,726,972 | 3:28.202 | 1 |
So, a whopping 2 errors in one file and a single error in the other. Wow. If you like percentages, then the worst of these is outputting the correct sound for 99.999998% of the time, and this from a very suspect cabling arrangement. Interesting though that the hangers made things better, maybe I should add coat-hangers to all my cabling....
Conclusions
So does all this prove that all transports and cabling make no difference to hi-fi? Unfortunately, not quite, but it does prove that it shouldn't make any difference.
Back near the the start of this article I put forward the idea that jitter introduced from whatever source could, in theory, affect a DAC as it outputs the sample when all 32 bits are in no matter of their timing. This could still be true, I didn't measure the timing performance of any of the transports above, or the timing of my DAC, since I don't have the equipment to do so. But if there is the potential for timing errors, why didn't they affect these experiments? Simply because the computers were in no hurry to write the sound, whenever the bits arrived was just fine and they duly got written to disc. If we played these recordings back the jitter would be decided by the soundcard, if it had a quality timing chip/circuit we'd do well, with the opposite being true as well.
All very interesting, but how does this affect hi-fi? Well, a DAC (whether integrated or separate) could do the same thing. Instead of outputting the sample blindly as soon as it arrives, it would be better to stick it into a buffer. Next, a separate circuit with accurate timing would read from the other end of the buffer, outputting samples with near perfect precision. Providing the buffer was allowed to fill a little before playback started there's no reason why it should ever over-run (drop samples) or under-run (output silence) as the jitter in a recording should even out over time. This isn't difficult, and I don't know if real CD players/DACs do it or not, but hey, they should do.
So jitter is still a possibility. What about errors? Well, I think that's pretty much blown out of the water, any half-decent CD transport is capable of bit-perfect operation and cabling is vastly more tolerant then people would have you believe.
And that's it; cabling is easy, transports are bit-perfect, and any jitter should be corrected by the DAC.
