Typical Errors in Digital Audio: Wrapping up

This “series” of postings was intended to describe some of the errors that I commonly see when I measure and evaluate digital audio systems. All of the examples I’ve shown are taken from measurements of commercially-available hardware and software – they’re not “beta” versions that are in development.

There are some reasons why I wrote this series that I’d like to make reasonably explicit.

  1. Many of the errors that I’ve described here are significant – but will, in some cases, not be detected by “typical” audio measurements such as frequency response or SNR measurements.
    1. For example, the small clicks caused by skip/insert artefacts will not show up in a SNR or a THD+N measurement due to the fact that the artefacts are so small with respect to the signal. This does not mean that they are not audible. Play a midrange sine tone (say, in the 2 -3 kHz region… nothing too annoying) and listen for clicks.
    2. As another example, the drifting time clock problems described here are not evident as jitter or sampling rate errors at the digital output of the device. These are caused by a clocking problems inside the signal path. So, a simple measurement of the digital output carrier will not, in any way, reveal the significance of the problem inside the system.
    3. Aliasing artefacts (described here) may not show up in a THD measurement (since aliasing artefacts are not Harmonic). They will show up as part of the Noise in a THD+N measurement, but they certainly do not sound like noise, since they are weirdly correlated with the signal. Therefore you cannot sweep them under the rug as “noise”…
  2. Some of the problems with some systems only exist with some combinations of file format / sampling rate / bit depth, as I showed here. So, for example, if you read a test of a streaming system that says “I checked the device/system using a 44.1 kHz, 16-bit WAV file, and found that its output is bit-perfect” Then this is probably true. However, there is no guarantee whatsoever that this “bit-perfect-ness” will hold for all other sampling rates, bit depths, and file formats.
  3. Sometimes, if you test a system, it will behave for a while, and then not behave. As we saw in Figure 10 of this posting, the first skip-insert error happened exactly 10 seconds after the file started playing. So, if you do a quick sweep that only lasts for 9.5 seconds you’ll think that this system is “bit-perfect” – which is true most of the time – but not all of the time…
  4. Sometimes, you just don’t get what you’ve paid for – although that’s not necessarily the fault of the company you’re paying…

Unfortunately, the only thing that I have concluded after having done lots of measurements of lots of systems is that, unless you do a full set of measurements on a given system, you don’t really know how it behaves. And, it might not behave the same tomorrow because something in the chain might have had a software update overnight.

However, there are two more thing that I’d like to point out (which I’ve already mentioned in one of the postings).

Firstly, just because a system has a digital input (or source, say, a file) and a digital output does not guarantee that it’s perfect. These days the weakest links in a digital audio signal path are typically in the signal processing software or the clocking of the devices in the audio chain.

Secondly, if you do have a digital audio system or device, and something sounds weird, there’s probably no need to look for the most complicated solution to the problem. Typically, the problem is in a poor implementation of an algorithm somewhere in the system. In other words, there’s no point in arguing over whether your DAC has a 120 dB or a 123 dB SNR if you have a sampling rate converter upstream that is generating aliasing at -60 dB… Don’t spend money “upgrading” your mains cables if your real problem is that audio samples are being left out every half second because your source and your receiver can’t agree on how fast their clocks should run.

 

So, the bad news is that trying to keep track of all of this is complicated at best. More likely impossible.

 

On the other hand, if you do have a system that you’re happy with, it’s best to not read anything I wrote and just keep listening to your music…

13 Responses on “Typical Errors in Digital Audio: Wrapping up”

  1. Sebastian Forbes says:

    Thanks Geoff !

    So, what does B & O do to help out with this situation ?

    Can we really be left with something that looks stylish but falls prey to all of the above?

  2. geoff says:

    Hi Sebastian,

    As I said, I’m not going to name names. However, as I’ve pointed out in the examples in the series, many of these problems occur before they arrive at the receiver. And, since these are non-linear errors, they cannot be undone downstream, regardless of the quality of the output device… For example, if your streaming subscription was supplied with a 96 kbps AAC file instead of a 44.1/16 FLAC file for a particular song, then the output device or the loudspeaker can’t repair the damage done – it’s too late.

    On the other hand, I can say that the tests I’ve described here are tests that I run almost every week, on B&O devices & SW updates and on “third party” devices as well (of course, in addition to the “usual” tests like magnitude response, SNR, THD+N, etc…)

    Cheers
    -geoff

  4. Olav says:

    Hi Geoff, I’ve really enjoyed reading all your posts here! I must admit that some of the things were tricky to really understand, but I’m rereading and trying to make sense of it all.

    But I have one question: what would be the most fool proof digital chain to use? What would be the best way or ways of avoiding the problems you have identified here?

  5. Rowan says:

    Thanks for sharing this series Geoff, another highlight of an exceptional blog! Really appreciated the description of use of the spectrogram for diagnosing digital audio systems and the descriptions of typical errors associated with time sync.

  6. geoff says:

    Hi Olav,

    I have only found 1 device that behaves well under all tests. However, since I’m not here to advertise for or against anyone, I’m afraid that I won’t be able to reveal what device that was. I should also say, however, that it was a fairly old device that did not support lots of the new-ish streaming/casting protocols, not all of the tests apply in this case.

    There are three ways I’ve found to have a reasonable guarantee that your system is working without testing:
    1. Use professional-level gear and pay attention to the clocking architecture.
    2. use a 20-year old CD player with an S-PDIF output
    3. The other option is to play sound files stored internally on a computer with a sound card that does NOT do sample-rate conversion. In this case, you must also make sure that the clocking is set up correctly – you can’t have your computer running on a different sampling rate than the sound card.

    Note that, this last case is not bullet-proof. I once did a test with my own go-to sound card, and a custom Max/MSP patcher that was used to test for bit-matching. I sent a signal to the device’s S-PDIF output which was routed back to its input. The MSP patcher was comparing the input to the output and reporting any bit errors over time. This worked great for the first 30 hours or so, but then errors started creeping in. By the end of a week of continuous testing, the error rate was quite high. I never did figure out why this was the case, mostly because 30 hours of reliability was all I needed at the time. Maybe I’ll come back to this problem some day…

    To be honest, most of the problems I’ve described in this series are the result of some kind of network-based audio transmission (typically wireless), or the artefacts caused by companies making software that they think will be compatible with other software and hardware (hence the transcoding…).

    Cheers
    -geoff

  7. geoff says:

    Hi Rowan!

    Thanks! I can’t take credit for the spectrogram test. I saw it first on the http://src.infinitewave.ca page and thought it was a brilliant way to see aliasing problems in sample rate converters. Since I’ve been using it a lot, I’ve also gotten used to detecting other errors with it as well. It’s useless as a method of specifying the audio quality of a device, but it’s great for a quick diagnosis once you get used to seeing the plots.

    Hope all’s well!

    Cheers
    -geoff

  8. Olav says:

    Geoff, thanks so much! I really appreciate that you take the time to explain these things to non-technical noobs like me. Highly appreciated. I now read all of your posts about digital errors for the third time, and I think I finally understood it now!

    If I may bother you with a couple of follow-up questions. What’s the reason for recommending 20-year old CD-players? Is the reason that they put out one sampling rate and one sampling rate only, unlike modern players? Or other reasons?

    And another small question about sampling rates. I still haven’t been able to afford the Beolab 50s I lust for, so I’m running a DIY setup. I have an active DSP-based crossover which we may give the fictional name “Driverack Venu360”. As a combined streamer and digital pre-amp I use a device we may give the fictional name “Yamaha WXC-50”, with digital out. The WCC-50, as I understood it, upsamples to 48-bit to control the volume, while the Venu360 has 32-bit floating point. Can this kind of sampling rate conversion (which I assume happens between the two devices?) lead to the kind of problems you have identified? I’m not asking you to comment on these two specific devices, which you may or may not have tested, but in principle… Or are any problems more likely to happen BEFORE the music signal hits the WXC-50? (in my case, a CD-player or Tidal streaming)

  9. geoff says:

    Hi Olav,

    Be careful not confuse upsampling or sample rate conversion with bit depth. It sounds like your Yamaha may be doing the DSP in 48-bit fixed point processing, but the sampling rate (and whether or not it’s converted) is independent of this. The same is true of the 32-bit floating point processing in the Venue360.

    Unfortunately, there’s no way to predict whether the devices you are using have any of the problems I’ve described – or other problems that I haven’t. The only way to find out is to measure them individually, and connected in series.

    The reason I say that you can probably trust a 20-year old CD player is that it had a simple job to do, and it probably did that job reasonably well. It had to read bits off a disc, and send them out the S-PDIF. Unless you find a fancy one with extra processing, chances are it just behaved. There would be no guarantee that the S-PDIF output has an extremely low jitter, but if the device you’re sending the signal to has a low jitter transfer function (via a decent PLL or ASRC, for example), then you don’t need to worry too much about this.

    Cheers
    -geoff

  10. Olav says:

    Thanks, I stand enlightened! You’re right, I got confused in the sample rates and bits. Merry easter!