Pre-processing, MP3 encoding and Declipping

The Declipper that's in Stereo Tool, the Omnia.9, Omnia.7 and Omnia.9XE and X/2 is the first step in the audio processing chain, and with good reason. But I've seen several stations that are putting a pre-processor, such as an Ariane, in front of one of these processors. Some stations have a playlist that consists of MPEG2, MP3 or AAC files, or use an MPEG2 or MP3 link from their studio to the transmitter site, and place the processor there. In this post I will describe how this affects the effectiveness of the Declipper.

Why is pre-processing a problem?

Unless the preprocessor that is used only operates on a single (wide) band, acts slowly and is fully phase linear, a proprocessor will change the waveform in ways that make it harder to detect clipping. Take for example this waveform, which only adds non-linearity:

As you can see, the flat areas that are easily recognizable on top are not flat anymore in the bottom image. The flat parts can end up anywhere, even in the center, which makes them much harder to detect. On top of that, since different frequencies have different delays, the distortion caused by a single clipped sample can easily be spread out over multiple samples.

Why is lossy encoding (MP3, MPEG2, AAC) a problem?

Most lossy codecs suffer from pre- and post-ringing. Which means that a click caused by a single clipped sample can be spread out to in some cases more than 1000 samples. Now, the clipping will usually still be visible and can to a large extent still be fixed, but the pre- and post-ringing of distortion will remain! And the flat tops that are caused by the clipping aren't as flat anymore.

This is the result of encoding some clipped audio (top) to 96 kbit/s MP3 (bottom). The one on top clearly looks like a clipped waveform, the one at the bottom looks like it could just as well have been limited. Also, there are some peaks that stick out much higher, so keeping track of the maximum level to determine whether samples might be clipped is less effective.

Beside this, using this type of lossy codecs is a very bad idea for audio quality anyway. These codecs try to minimize audible effects that you can hear, but if you process the audio afterwards, many of the assumptions that these codecs make are invalidated, and the effects will be very audible! So unless you have a very good reason, never use these codecs except when you're streaming to end users.

More problems with lossy encoding

The situation is actually even worse. Lossy codecs in general have difficulty encoding clipped audio, because it contains a lot of harmonics that all need to be encoded. So, much of the bitrate that's available is used to transfer distortion which we will (try to) remove later. If you also send the end result to your listeners using a lossy codec (streaming, DAB+, HD radio), your audio quality gets 3 separate hits:

1. The lossy encoder uses a lot of its bandwidth to reproduce the distortion, creating more encoding (MP3-like) artifacts.
2. The Declipper cannot completely remove all the distortion.
3. The output lossy encoder again needs to use bandwidth for the remaining distortion, causing yet more artifacts.

This image shows the spectrum of the clipped audio (red) vs. the spectrum of the audio after declipping (yellow/orange), the difference is about 20 dB. It's pretty clear from this image that the declipped audio is much easier to encode.

As a side note: This means that to improve your codec's response you should always use the declipper for streams, HD and DAB+ stations!

So now what?

If you feed your processor that contains the Declipper with a lossless source, without making any changes to the audio, you're fine. If your music library consists of something like MP3's, you're doomed - go away and start re-ripping everything. (Sorry, I can't make it much nicer than that).

In other situations, try to declip before you do anything else. This is definitely not the easiest solution, and live material still might arrive with clipping which wouldn't be fixed properly. Anyway, there are multiple ways of doing this.

You could for example declip all the files when you put them in your music library. Please keep in mind that future repair filters, declipper improvements or even declipper settings changes might force you to do this again, so at the very least, keep your originals as well. Also make sure that you store them in a high enough bit depth, and under no circumstances use a lossy codec to store them.

Another option is to run part of the processor that contains the declipper before the steps that cause the changes to the audio, and the rest afterwards. In case of Stereo Tool, you can run 2 copies, in case of several of the Omnia products you could use patch points to get the declipped audio out, and send it back in after performing the pre-processing.

A few final notes

It probably doesn't hurt to declip twice (but it might if you change the audio in between). So, there are situations where you might want to perform the declipping on each file, but still enable it on the processor as well.

If you store the output of the declipper in a file with the same bit depth as the original, due to the extra headroom required you will introduce some hiss or quantization noise. For 24 bit files that's no problem, for 16 bit files it might be, especially if you use processing that can boost the level a lot. If you use Stereo Tool you could use the Dequantizer to increase the bit depth back from 16 to about 18 or 19 bits, but not going back and forth is always better. So it's better to store the resulting files in a higher bit depth.