Results from informal jitter measurements on CD transports

If this post makes no sense, check out the previous three posts for more explanation. In short, I recently considered upgrading my cd player. One unit I demoed sounded much better than the rest, even though I was using an S/PDIF or AES/EBU connection to my pre-amp. My wife commented, "I don't appreciate how bad the Lexicon makes our current CD player sound". I wanted to find out why the Lexicon RT-10 sounded so much better: fewer CD read errors? some sort of digital signal processing? better S/PDIF or AES/EBU connection?

I eliminated CD read errors as an important differentiator in my first experiment, and had no idea how to test dsp tom-foolery. So I tested the S/PDIF interface. My experimental setup is described in a previous post, but I'll summarize here: it was pretty ugly. In this post, I'll summarize the results. If you want to peruse the data, visit http://komarix.org/per/computers/spdif/index_html.

I auditioned four CD players. Subjective "a/b" listening experiments, by one to three people, ordered the transports from best-sounding to worst-sounding as follows:

• Lexicon RT-10 (using the AES/EBU balanced digital connection)
• Pioneer Elite 79avi
• Rotel RCD-02
• Momitsu v880n

Note that "worst" doesn't mean "bad". For example, I really like the sound of the Rotel, and it has great a very nice built-in pre-amp. The main difference by my ears is level of detail, for example the texture of violins, the sound of piano hammers, or the clarity of a timpani roll. In the rock-n-roll world, with the Lexicon RT-10 I was able to understand the words in heretofore-unintelligible R.E.M. songs (I still don't know whether I understand what Michael Stipe means).

Jitter (timing error) measurements for each of the four players were taken, and the average jitter error was computed. There are a lot of problems with my experimental setup, but I'm inclined to believe my measurements are a reasonable way to sort CD players according to the quality of their SPDIF or AES/EBU output interface. Here's a summary of the results, lower jitter error is better:

• Lexicon RT-10: 1.3ms
• Pioneer Elite 79avi: 1.9ms
• Rotel RCD-02: 3.2ms
• Momitsu v880n: 5.0ms

The statistic for the Lexicon comes from the AES/EBU interface, the rest are for the S/PDIF interfaces (these standards are closely related). I'm using AES/EBU for the Lexicon because of deficiencies in my test setup (no 75 ohm termination of the S/PDIF line during testing, and a really pathetic error calculation script that freaks out on the Lexicon's unterminated S/PDIF output).

For what it is worth, these lists are also in order by price, from most expensive to least. However, comparing this way is apples to oranges, because of different feature sets and release dates.

In case you are interested in S/PDIF waveforms, I've made miniature images below. These images link to full-sized versions at http://komarix.org/per/computers/spdif/index_html. Note that these waveforms might be smoother if I had used proper 75 ohm termination when measuring the signal. See my earlier post about S/PDIF for resources that explain how to interpret biphase-mark-encoded signals.

My simple method for measuring jitter

I recently auditioned four CD players to use as digital transports, and discovered they can sound very different. I wanted to understand why these CD players sounded different, given that they were reading the same digital source material, and transmitting that material digitally to the same pre-amp. When auditioning audio equipment, I really only care how the equipment sounds to Jeanie and me. This time, however, my curiosity motivated a few extra experiments.

In two previous posts, I explained a bit about digital audio interfaces, and what types of errors might account for acoustic differences. I described a test I performed to check whether CD read-errors might account for the differences I heard between CD players, and decided that wasn't the issue (for a couple reasons). Of my remaining hypotheses, I could only hope to test whether jitter (timing errors) was an issue in the digital signal output by the CD player.

I don't have the right electrical test equipment to really measure jitter in an SPDIF or AES/EBU signal. However, I do have a digital oscilloscope and can can transfer electrical measurements to my computer. So I made a plan to record each CD player's SPDIF output as an analog waveform, in some way that would allow a reasonable back-of-the-envelope analysis.

Here's the experimental setup for each CD player: I connected a good RCA-terminated 75ohm cable to the CD player's SPDIF output, and connected my oscilloscope to the other end -- the scope probe hook wouldn't fit around the RCA plug's signal conductor, so clipped it to RCA ground, and clipped the probes grounding clip to the RCA signal conductor. Also note that I didn't use proper termination, leaving the scope's 1M impedance to terminate the 75 ohm line. For each of four pieces of music, I chose a particular passage I would play while taking SPDIF measurements. I wrote a small script to configure and fetch waveform samples from my Tektronix TDS-210 oscilloscope. While playing each of the selected bits of music, I ran my script when the CD player's track timer reached the predetermined time. The script recorded a sample of length 1200 nanoseconds, then 6000ns, then 19200ns. The short samples have good time-resolution, while the long samples have more waves to measure.

Using my equipment, I couldn't run my script on exactly the same section of each music passage on each CD player. However, the overall "type" of music should be the same. For example, the low and high frequency contents of the music should have roughly the same proportions across my samples for each CD player, and the volume levels should be nearly the same, too. Another source of error might have arisen from terminating the SPDIF termination with a 1 megaohm load (my scope). Though this probably caused some overshoot and ringing in the digital signals, I don't believe it caused important timing errors. I eventually picked up better cables and a 75 ohm BNC terminator -- I'll post again if the results are interesting.

After collecting all that data, I chose to use the 6000ns samples for analysis. I wrote another script to find the first time the captured data crossed zero volts, and then measure the distance from that zero crossing to all the other zero crossings we captured. Those distances should have been multiples of 177ns. If the distance between the first zero crossing and a later zero crossing was 880ns, then I assumed it should have been 885ns (since 885ns is five times 177ns), and recorded a 5ns error. Each 6000ns sample had about twenty zero crossings after the first zero crossing. After compute the approximately eighty errors from my four 6000ns samples for a musical passage, I computed the average and standard deviation for the errors.

The four musical passages I used were

• Shostakovich's preludes and fugues for piano, performed by Tatiana Nikolayeva, prelude no. 24 (Hyperion CDA66441/3)
• Alizee's "Moi... Lolita" from her Gourmandise album (Universal/Polydor/Requiem Publishing 549 545 - 2, LC 00309)
• Bruckner's 5th symphony, performed by Barenboim and the Berlin Philharmonic (live, c. 1992), first movement (Warner Classics, 2564 61891-2)
• Josquin Desprez, Sanctus de Passione, performed by the capella antiqua Munchen under Ruhland (Seon/Sony Classical SBK 60362, 01-060362-10)

The four CD players were

• Lexicon RT-10
• Pioneer Elite 79avi
• Rotel RCD-02
• Momitsu v880n

The Lexicon RT-10 has both SPDIF and AES/EBU outputs, and I recorded data from both. I also recorded data from my pre-amp's SPDIF record-out jack. The pre-amp is an Anthem AVM-20. We also did informal listening tests between these CD players, usually doing a/b comparisons, and one time doing a single-blind trial.

I will write about the results in my next post. If you want to read ahead, take a look at my rough experiment writeup of the CD players' performance, on my regular webpages.

Why consumer digital audio systems have errors

In a previous post titled "Digital Audio: why cd players sound different", I explained why I decided to attach my oscilloscope to the digital audio outputs of four different cd players. In this post, I'll explain what "jitter" is, and how it affects digital audio transmission. In later posts, I'll explain my experimental setup, and highlight the interesting results. You can find all my experimental data, and a hasty write-up, at http://komarix.org/per/computers/spdif.

Consider the following sequence of words:

let me shoot that duck before I hit you I have a cow hide under rocks at home

You can change the interpretation of these words by changing where periods go:

Let me shoot that duck before I hit you. I have a cow hide under rocks at home.

Let me shoot that. Duck before I hit you. I have a cow. Hide under rocks at home.

When we listen to each other speak, we infer where the periods go. When we read text, we know exactly where the periods are. We have the same choices in digital data transmission. We can use protocols that tell us where the periods are, or we can use protocols that make us guess. Consumer digital audio uses the SPDIF protocol, a descendent of the professional AES/EBU standard, and both make us guess where the periods are. If we guess wrong, we misinterpret the audio data in one way or another. For those who understand all this, please excuse my weak analogy.

AES/EBU and SPDIF use biphase-mark-code modulation, which helps the receiver (e.g. a pre-amp) recover the data clock of the sender (e.g. the CD player) just by looking at the data stream. The sender encodes the data using an approximation of an irregular square wave with voltages between -1 volt and +1 volt. Let's define a "zero crossing" to be the time at which the square wave is at zero volts (as it switches between -1v and +1v). In biphase-mark-code modulation, the receiver knows that zero crossings should be separated by one, two, or three ticks of the data clock. For AES/EBU and SPDIF, those ticks should be about 177 nanoseconds apart. Deviations from these rules are called "jitter". See http://www.epanorama.net/documents/audio/spdif.html for more details about these protocols.

The receiver of the digital data stream can take advantage of biphase-mark-code constraints, and only hasto measure voltage of the sender's square wave once every 177 nanoseconds (preferably half-way between clock ticks). If the receiver doesn't sync its clock exactly to the sender's clock, then the receiver will occasionally misread the senders data. Synchronizing one high-quality clock in the receiver to another high-quality clock in the sender isn't very hard.

Unfortunately, most CD players have deplorable low-accuracy clocks, and can't keep a steady "beat". The device you connect your CD player to, maybe a pre-amp, is constantly readjusting its clock as it tries to understand what the CD player is trying to tell it. This causes errors when interpreting the audio data. If the pre-amp has a low-quality digital input circuit, even more errors will occur. If you want to really understand what these errors are, and how they affect sound reproduction in absolute and psycho-acoustic terms, see http://stereophile.com/features/396bits/ and http://www.stereophile.com/features/368/.

Digital Audio: why cd players sound different

A friend commented that my stereo system sounded good, but the CD player lacked detail. I set out to learn why cd players sound different. Since music is stored digitally on a CD, and my CD player is attached digitally to my pre-amp, I wondered why my pre-amp wouldn't receive an exact copy of the recorded music.

One source of errors is reading the CD, since there are no checksums in the Redbook CD audio format. The other source of errors is data transmission between the CD player and pre-amp, since it also lacks checksums. Since consumer digital audio connections run about 1000 times slower than modern computer CPUs, and over 100 times slower than a good external SCSI bus, I figured disc read errors were the culprit. However, disc read errors usually result in popping sounds, because bad bits make sudden changes in volume, and that's much different than a lack of detail.

I did an experiment with a network audio player, the Momitsu v880n, to eliminate the effect of disc read errors. I did an overlapping-sector rip of a favorite music track on my desktop computer, creating a virtually error-free copy of the CD's information. I transferred the this error-free copoy to the Momitsu over ethernet via TCP, thereby eliminating undetected transmission errors. The Momitsu then sent this pristine, digital audio data over it's digital (spdif) output to my pre-amp. I expected to hear the best possible audio reproduction my stereo could produce. Instead, the result was lackluster, slightly worse than my main CD player (Rotel RCD-02), and much worse than a high-end player I borrowed (Lexicon RT-10).

I concluded that transmission of digital audio data over an spdif interface was the problem, or else the high-end CD player "touched up" the data it read from the CD. Both explanations seemed unlikely. Since Lexicon probably wouldn't reveal their audio secrets to me, I studied the spdif protocol and electrical specifications. If you are interested, I recommend http://www.epanorama.net/documents/audio/spdif.html, or else search Wikipedia. I began to believe that timing errors called "jitter" were responsible for the audible difference between CD players using digital connections. You can read a lot about jitter and CD players at http://www.stereophile.com/features/368/ and http://stereophile.com/features/396bits/. Those articles are somewhat old (mid-1990s), but they present convincing arguments that jitter is a real problem in digital audio systems.

That said, shouldn't modern CD players have addressed and eliminated jitter? The answer is no. Though an Ultra160 SCSI bus built in 1999 can move 160MB per second over several meters of cable with no errors, the spdif interface can't even move 1MB of audio over one meter of cable without errors. The spdif interface is old, and that's part of the explanation. Still, I didn't believe any of this until I conducted a few experiments of my own, using an oscilloscope. I've made a hasty write-up of my conclusions, which you can find at http://komarix.org/per/computers/spdif.

I will highlight the most interesting points and graphs from my experiments in a later post. The summary is that even a very primitive experimental setup (read "ghetto") can reveal errors in spdif data transmission, and those errors correspond directly to subjective assessments of audio reproduction quality. I tested four CD players with three listeners, one of whom let me conduct a single-blind a/b test. The measured error rates of the CD players corresponded perfectly with the listeners's preferences. Unfortunately, the error rates also corresponded to price, with the most expensive player (the Lexicon RT-10) have the lowest error rate (when using it's AES/EBU digital interface, instead of the lower-quality spdif).

The Lexicon was so good that my wife complained: "I don't appreciate how bad it makes our Rotel sound." In fairness to the Rotel, the Lexicon RT-10 retailed for over $3000 in 2003, versus $500 for the Rotel RCD-02 in 2004.

Why haven't we seen newer, better digital transmission protocols appear on consumer audio equipment? Why do $3000 CD players use inferior technology, when compared to $100 portable music players? Why hasn't firewire replaced spdif? My best guess is that the RIAA and music publishers are discouraging high-quality interfaces, because they worry consumers are thieves. With crappy interfaces like spdif, the RIAA can rest assured we'll rarely hear what is recorded on the CD. If this argument seems far-fetched, consider that Sony's high-end super-audio CD (SACD) specification prohibits digital audio transmission when using surround sound. This means we have to use analog transmission when listening to the highest-quality digital recordings.

Thule Rack and Yakima Bike Carrier on 2000 VW Golf IV 5-door

This certainly isn't the topic that inspired this blog, but I probably ought to get this stuff down in print somewhere. We installed a Thule rack on our 2000 VW Golf IV (5-door) today. The instructions looked simple, there were only two steps. That should have been our first clue that Thule's directions omitted important information. The second clue was that we shouldn't have needed to fetch the deadblow mallet to complete the installation.

Once we gave up on Thule's directions and universal application of brute force (save one exception), things went fairly well. Here's what I can remember. Unfortunately, I have no photos.

Regarding Thule's step 1:

• Go ahead and attach the rubber pads to the base of the "towers" (the things the crossbars go through), but don't stick those little wedges in yet (the wedges set the angle between the tower and the tower's base). I don't care what Thule says, they're wrong. If you stick those wedges in and continue to step 2, you'll probably find it very hard to insert the crossbars. The crossbars should slide in somewhat easily, if you follow the steps below that Thule forgot to include.
• On the side of the tower that would face the middle of the roof, slightly above the tower's base, there's a couple pieces of interesting plastic. The lower, wider piece has teeth in a sawtooth pattern, though you might not be able to see that. The other, narrow piece looks a little like a lever or release clip of some kind. Squeeze those pieces together, lifting the lower piece's teeth above the metal slot (you'll figure it out). This allows you to pull those plastic pieces out a bit, which rotates a metal piece a bit in the middle of the tower. This will create a little extra space for the crossbar to slide through. Let's call this metal piece in the middle the "nut-gizmo", since it has a threaded hole in it.
• In step 2, you'll insert the crossbar. Before you do that, put the plastic housing over the towers. Then slide the bar through two towers. Put the towers over the clips (see step 2 to make sense of that), and center the crossbar.
• Now you can put the little wedge thing in.
• Finally, put the screw through the oval hole in the clip, into the "nut-gizmo" we mentioned earlier (don't forget the little plastic part that goes on the screw first, and pay attention to its orientation). As you tighten the screw using the attached plastic handle, you'll be pulling the nut-gizmo back in to its original position. You might have to push down on the lower, wide plastic part with the teeth to lock it into position (though the screw does that as well).
• When centering the crossbars, this info might be useful: We used the 50" crossbar. On the front crossbar, we had about 105mm extending beyond the towers (I think, but I don't remember the front measurement so well). For the rear crossbar, we had about 135mm extending beyond the towers.

Regarding Thule's step 2:

• The 2000 VW Golf has nice little posts that the rack hardware attaches to. The directions for this are fine, except they don't warn you that you'll need a mallet to get the Thule adapter clip over the top of the post (this is the exception to the no-brute-force rule).
• The posts come in pairs, two front and two back, and are located somewhere above the front door and above the rear door. You'll use the "inside" posts that are closest together. Thule explains this well-enough.
• The distance of 180mm from windshield to the inside-front post, and 700mm between the inside-front post and inside-rear post are completely wrong, at least for my Golf IV. Perhaps not coincidentally, 700mm is the minimum distance between the front and rear support. I guess they meant to say "at least 700mm".

The Yakima Viper bike carriers went on easily. A lot of Yakima and Thule gear have been designed to work with each other's racks, which is definitely good for us users. The one thing I don't like about the Viper carrier is the rear strap. With the narrow-ish road tire on my wife's mountain bike, it was very hard to ratchet the strap down tight, and even hard to get it to release. It seems Yakima simply choose too stiff of strap. On the upside, Yakima had about 13 very detailed steps for the bike carrier, in contrast to Thule's crappy directions.

In case you wonder why I bought a Yakima carrier for a Thule rack, it's because I like the square crossbars that Thule used, and I liked the toolless install on the Yakima Viper carrier. Thule's Echelon carrier *might* be toolless, but they don't say that in their catalog, and my local REI didn't have one in stock. Yakima says their round crossbars are stronger, and I suppose they are more aerodynamic, but neither of those is likely to be important. My car roof hold at most 185 pounds (including the rack and bike carriers), and I'm sure that Thule's square bars are more than adequate. On the other hand, stuff I clamp to a single square crossbar won't rotate, e.g. the Thule "load stop" (Thule part 503, listend under "Boat Mounts and Accessories" for no apparent reason).

Thule (which seems to be pronounced Tool-ie) has some sort of online instructions. I didn't find those until I was writing this blog, and I don't think they're mentioned on the paper instructions. Even had I found them earlier, they don't seem to work with Firefox 1.5.10 on GNU/Linux, so Thule's fancy online instructions wouldn't have helped me.

One last bit of info we didn't find online anywhere: Thule and Yakima's locks are *not* interchangeable. Thule's locks include the lock core and the part that actually does the locking. Yakima's locks are just the core, with a little pin that sticks out. Yakima's lockable equipment has a receptacle for the little pin, and the rotating foot that does the locking is attached to that receptacle.

All in all, my wife and I spent two hours attaching our new rack and carrier. I'm looking forward to spending time using it, instead of spending time attaching it.