Guest Blog: It's Time to Admit that We Don't Know Everything

Posted by: Tom Martin at 4:04 pm, January 21st, 2010

It is this fourth factor - the impact of cognition on the outcome - which makes DBT as applied to audio quite different from DBT as applied to, say, drug testing. It is often observed in audio DBT, in cases where subtle differences are uncontroversially acknowledged to be present (such as tests of lossy audio codecs), that "experienced" listeners are more statistically likely to identify differences. Why should that be? It's possible that experienced listeners are experienced because they can hear better, but given the disproportionately high representation of older males in the audiophile community, that seems unlikely. A more likely explanation is that experienced listeners just know what to listen for. When you think about it, this is not surprising. If we do a DBT on two different Stradivarius violins, who is more likely to reliably distinguish them? An untrained listener off the street, or the person who has owned and played one of the two Strads for the last 20 years? Any listening test - blind or not – conflates hearing and cognition, and is subject to deficiencies in either of those.

Bob Stuart of Meridian Audio, digital audio pioneer, degreed in both audio engineering and psychoacoustics, points out one obvious problem with DBT as applied to music listening: the “problem” of memory. If component B raises a subtle aspect of the music to the conscious level (the actual lyrics to Louie Louie?), you are now very likely to hear it when switching back to component A as well – because you remember it. People aren’t test instruments – they can’t reliably be reset to the same initial conditions. What you hear when you listen to music is a function both of your low-level sensory apparatus, and your experience. There is no way to construct a music listening test, DBT or otherwise, which conclusively proves what differences can and cannot be heard, because hearing can't be isolated as an independent variable.

A further observation about the limits of audio DBTs falls out of this discussion. In a double blind test of, say, drugs, we not only assume that the test subjects’ cognition (outside of the placebo effect) does not impact the results, but we also ignore statistical "flyers". If one test subject gets spectacularly better while taking the test drug, but nobody else does, the drug has failed. We chalk up the flyer to some combination of factors not applicable to the general population. But here's the thing: audiophiles are "flyers" by definition. The differences between the two Stradivari are of no import to the general populace, but Itzhak Perlman is a different story. The ability to detect woodwind sound reflecting off the orchestral shell is of no import to the general population, but it is to me. Many audio DBTs are oriented more at what the “average” person in a test population can or can’t “hear”, than in ferreting out performance differences at the margins.
 
Yes, single blind listening is obviously subject to serious errors such as confirmation bias, and attempting to confirm results through other mechanisms such as measurements and double blind tests is something "subjectivist" magazines should do much more often. And the more extraordinary the claims for a component are, the more scrutiny they should receive. At the same time, I'll submit that many advances in audio reproduction were introduced by engineers who used their ears as their primary tool. I remember well the controversies surrounding digital audio in the early days, 30 years ago. Objectivist audio equipment reviewers, using the measurements they'd used to evaluate the analog world, found that digital audio measured essentially "perfect", and their ears confirmed what their measurements told them. Many professionals who cared mostly about sound, however, like recording engineers and subjective audio reviewers, insisted that these early digital recordings didn't sound "right" in important ways. And sure enough, over time, the causes of various digital audio artifacts became studied and understood, measurements were devised, listening tests which exaggerated the phenomena educated audio professionals on how to hear these things, and a whole host of technical improvements ranging from dither and noise shaping to jitter reduction to innovative anti-aliasing and reconstruction filter design, among many others, were employed to attack and reduce the unique problems of digital audio, to the point that it now comes very close to meeting its original promise. What is especially ironic is that some of those types who proclaimed digital "perfect" way back then (hello, Brad Meyer) now take the line that, of course, those early systems had some little issues but we've fixed all of them now! I reserve the right to be skeptical.
 

I close with a few lessons from my own experience as an objectivist audiophile:

Comments

Cemil Gandur -- Sun, 01/24/2010 - 14:54

Very nicely written. Excellent post.

baald (not verified) -- Thu, 01/28/2010 - 14:03

you. are. a . god.

MarcFirenze (not verified) -- Thu, 01/28/2010 - 14:31

Sheesh. If the current standards are that picky/difficult/prone to error, just use TCP/IP and ethernet and get it this paradigm-shift-from-analog-to-digital over with. You have described the whole SPDIF, AES, USB, DVI, HDMI, TosLink epoch as a bumpy road on the way to digital nirvana. Just get to the destination for god's sake. I'll be happy to run that weenie 48Mbit/sec Blu-Ray stream on 1000Mbit/sec ethernet, thank you very much. I think there is room in the bandwidth for timing information.

ScottB (not verified) -- Sat, 01/30/2010 - 12:25

My post was originally written in the comments section of the Furutech USB cable review, and wasn't intended to address the question of reducing digital transmission jitter more broadly. The most logical way to address the issue of transmission-related jitter is simply not to transmit timing information over the transmission channel at all. In other words, use an asynchronous protocol, where the controlling clock is in the receiver, and data is transmitted "on demand" when needed to fill the input buffer - just as it is in Ethernet. Both Firewire and USB also support asynchronous, packet-based digital audio protocols, and a few USB DACs are starting to use USB in asynchronous mode. I have one myself - the Ayre QB-9. The async USB protocol is apparently quite involved to implement, but I suspect that, in about 2 to 3 years time, pretty much all USB DACs with audiophile pretensions will be using the asynchronous protocol.

BTW, Firewire, as I understand it, was async from the beginning, which goes a long way to explaining its popularity in professional audio gear.

imickey503 (not verified) -- Thu, 01/28/2010 - 18:27

MarcFirenze : HELL LETS GO FOR THE GOLD AND GO FOR 10GBoE!

But before we get there, We all might like to try Fiber channel 0r inifiniband to make sure we have enough headroom!

Anonymouse (not verified) -- Fri, 02/05/2010 - 19:20

Well, Scott you have constructed a wonderful example without looking at all of the pieces of the puzzle.
At no point did you seem to argue that the data can't be reliably transferred over the cable. Your point was that jitter would affect how the data was utilized. In technical terms we call this the transport layer. In most communications protocols this is layer 1.
IF the output of the USB cable were directly coupled to the input of the DAC AND the DAC relied on exclusively on the clock derived from cable input you could potentially be right. Jitter would in fact be a significant contributer to the sound coming out of the DAC.

Which is precisely why designers DO NOT use a source clock from an outside source as a reference. The data transfer is actually transfered to the device at a rate which exceeds that rate required by the DAC and buffered locally in a memory and then used by the DAC controller at the rate which it requires.
The clock rate being fed to the DAC is derived from a local precision oscillator. If the DAC your using doesn't have this, well you get what you deserve and shouldn't wasting your money on cables, but on buying a better DAC.
In the end if the cable has adequate bandwidth to transport the signal, that is good enough. It's like saying the movie looked better at the theater becuase the film came on a truck instead of a plane.
As long as it wasn't damaged in shipment, it just isn't a relevant aspect of the discussion.

ScottB (not verified) -- Fri, 02/05/2010 - 22:17

"Which is precisely why designers DO NOT use a source clock from an outside source as a reference. The data transfer is actually transfered to the device at a rate which exceeds that rate required by the DAC and buffered locally in a memory and then used by the DAC controller at the rate which it requires."

Incorrect, you haven't researched the fundamentals. You're making the same mistake that so many other posters on the USB cable review thread also made. What you're describing is an asynchronous protocol, in which the receiver requests data, at a high transfer rate, from the source, fills a buffer with the data, and begins to "meter" out the data from the buffer based on its own internal clock. When the data buffer gets more room, another request to the source is sent for more data. This is the kind of protocol used for almost all USB (or Ethernet, or eSata, etc) peripherals, like disk drives, printers, cameras, etc, and within broadly defined design limits, data integrity through these asynchronous protocols is perfect, regardless of cable.

But the most commonly used USB audio protocol is synchronous - the data is first clocked at the source, and transferred at the rate it is to be consumed, modulo clock error. The receiver has a passive role - it must take the data at the rate the source dishes it out. The receiver is therefore somewhat at the mercy of the source. Yes, the receiving DAC can buffer the input data and use its own clock to meter the data out of the buffer, and thus smooth timing errors. Almost all modern DACs do exactly that (typically called de-jittering). But the ability of a de-jittering system to eliminate timing error is finite. The input buffer can't be very big, lest the user interface become very slow. And obviously, the clock at the receiving end must in some way synchronize to the clock frequency being delivered from the source, or buffer overrun/underrun will occur. In other words, the receiver is not in complete control of its own clock, it must adapt to changes in the source clock, and those adaptations themselves are effectively timing "errors", aka jitter. And the source clock itself is modified by the interactions between source, receiver, and cable.

See my above comment about an emerging use of USB in asynchronous mode for digital audio, which obviously changes the above analysis almost completely.

VandyMan (not verified) -- Thu, 02/11/2010 - 12:11

If jitter is truly the cause of perceived differences between digital cables, why do NO manufactures state jitter rates and NO digital cable reviewers (in publications that do measurements) publish jitter measurements? The question of a digital cables impact on jitter could easily be answered by measuring jitter using a number of different cables in a known system. My guess is that such measurements are not done/published because they would reveal the digital cable market to be a fraud.

ScottB (not verified) -- Fri, 02/12/2010 - 18:52

I agree with the meta-level point you're making, which is that cable manufacturers ought to provide a lot more credible theoretical and empirical information backing their claims. On the other hand, if you think that the very notion of cables impacting transmission jitter is a "fraud", there is plenty of empirical data showing the impact of cabling on jitter. Perhaps the most extreme example I've run across is an old article on CD transport jitter by Robert Harley, back when he was with that other mag:

http://www.stereophile.com/features/368/index3.html

In which RH saw a doubling of measured jitter just by reversing the direction of an SPDIF cable (!)

For those interested in a more in-depth treatment of the whole question of jitter, this article by Steve Nugent of Empirical Audio gets into more detail without being overly technical:

http://www.positive-feedback.com/Issue43/jitter.htm

I should also note that the whole idea of measuring jitter induced by a cable is problematic, since the impact of a cable is very dependent on the characteristics of the transmitter and receiver circuitry, and even the musical content itself. As you see in the Stereophile article above, you can find combinations of equipment and test signal that create gross differences, which may or may not correspond to performance in the average system.

All content, design, and layout are Copyright © 1999 - 2011 NextScreen. All Rights Reserved.
Reproduction in whole or part in any form or medium without specific written permission is prohibited.