Anthem Statement D2

This thing is friggin' amazing.

I recently upgraded my pre-pro to an Anthem Statement D2. I haven't had much opportunity to do any video comparisons, partially because I can't stop listening to music. I really liked my AVM-20, but the D2 sounds so good I can't help but blog about it. I can finally pick out the second violins from the first, spatially. It's not live music, yet it still has emotional and visceral impact.

If you feel like talkin' tech, here's the full setup: The signal starts at an old floor-demo Lexicon RT-10 disc player (fabulous on its own, for audio), travels over an AES/EBU connection to the D2, then passes through XLR-terminated coax to the Anthem AVM-50 amp which passively bi-amps a pair of Paradigm Signature S2 loudspeakers. The low frequencies are sent to a Velodyne DD-10 subwoofer.

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.