[mad-user] Clipping - Some naive (?) questions
Tue, 13 Feb 2001 21:37:52 -0500
"D D" wrote:
> I'm a new user to MAD and it's immediately become my standard for mp3
> listening and decoding. The first thing that shook me when using Mad, was
> something that I never had encountered before, the mp3 clipping
> indicator. Low-bit distortion is one thing, but high-bit problems is surely
> a worse one, if not the worst! And when I witnessed Mad reports clipping
> even with files produced by the best encoders like Lame, this rang a red
> alert for me: are we constantly exposed to clipping distortion when using
> winamp's decoder or other decoding apps?
In a word, probably.
> In conclusion, to rephrase my (naive ?) questions: how is it in principle
> possible that Mad detects clipping, how does Mad do it and where exaclty is
> Mad detecting it:
> a) is clipping stored inside the mp3 file content?
> b) is it an artifact of decoding programs ?
To understand the clipping issue, it's helpful to understand a little bit
about the MP3 decoding process. There are two steps relevant to this
01011001100010 ---> | decoder | ---> +0.298238, +0.019343, -0.374920, ...
MP3 data +---------+ PCM samples
The PCM samples produced from decoding are relative to a "full scale" range of
-1 to +1. In other words, these samples are fractional numbers with absolute
value (usually) less than 1.
As will be explained, no clipping occurs here, although these values can
sometimes go beyond full scale.
PCM samples ---> | scaling, rounding, | ---> 9773, 634, -12285, ...
| dithering | 16-bit output
To get a 16-bit (or 8-bit or 24-bit) output value from a PCM sample, you need
to scale the number -- for example, multiply by 2^15. Thus the full 16-bit
integer range -32768 to +32767 is used to represent the fractional numbers
between -1 and +1.
A problem arises when the decoder produces PCM samples beyond full scale, that
is, with absolute value greater than 1. This can happen even in fully
compliant decoders, and is not (necessarily) the result of a programming
error. It happens due to the MP3 algorithm itself and the encoding methods
applied to the original signal.
Encoders *could* try to minimize this occurrence, but my guess is most are
probably unaware of the effect or do not pay very close attention to samples
near full scale, so these samples can sometimes creep above full scale
depending on the level of quantization. Encoders also work in the frequency
domain, so it is probably difficult to realize the effect on samples in the
time domain without following up with a full decode.
In any case, decoded samples beyond full scale are a fact of life. The
question is, what to do about it? These can't be represented in normal output
using the scaling method I just described, so something must be done.
The simplest answer is to clip the signal, and this is probably what 95% of
all decoders do. Any sample above full scale is treated the same as full
scale. This adds distortion to the output.
Another answer is to use a limiting/compressing technique on samples near and
beyond full scale. This has been discussed on this list and is something I've
considered and may implement at some point.
In the case of the current MAD plug-in, clipping can be used in a feedback
loop to attenuate the signal so that further clipping can be avoided.
It's important to keep in mind the two distinct steps I described to get to
the final output. Some decoders combine these steps, but this limits their
flexibility. Strictly speaking, "MAD" only performs the decoding step; the
issue of clipping is outside its scope. Applications that use MAD, like the
plug-in for Winamp, are responsible for the policies that affect things like
clipping and dithering. It's a fine distinction, but other apps that use MAD
may implement different policies.
> In addition, can you suggest another reliable means of verifying that an mp3
> contain or not clipped content ?
Since most decoders combine the decoding step with the scaling and clipping
step, it's impossible to know from their output how much clipping has
occurred. It's the same as trying to determine the number of clipped samples
in a 16-bit WAVE file: you can guess that the samples at -32768 and +32767
were clipped from some greater amplitude, but this isn't always the case.
That's why tools like Cool Edit only report "possibly clipped samples."
Recent versions of the command-line `madplay' will report the number of
clipped samples and peak amplitude, but this is the same information the
plug-in gathers when attenuation is disabled, and since it uses the same MAD
decoder back-end, this may not be the kind of verification you're looking for.
The sample MPEG audio decoder implementation in the ISO dist10 source code
floating around actually reports clipped samples as it's decoding. It doesn't
give a total though, and you'd probably have to compile it yourself, so I
don't know how useful this is.
Hope this helps.