Is My Audio Clipping? How to Tell Loud From Damaged

A track peaks at 0.0 dBFS. Is that clipped, or is it a master that was limited to the ceiling on purpose?

Both look identical on a peak meter, and that is why peak meters cause so many false alarms. The difference is not how high the waveform goes. It is how long it stays there.

What clipping actually is

A digital sample cannot exceed full scale. When the signal that should have been recorded goes past it, every sample that would have been higher is written at the maximum instead. The waveform’s peak is not a curve any more — it is a flat horizontal line, and the length of that line is the number of consecutive samples that were destroyed.

A limiter working correctly touches the ceiling and comes straight back down: runs of one or two samples, sometimes none at all. A clipped recording sits on the ceiling for dozens of samples at a time.

Measured: a commercial master limited to −1.2 dBFS reads 0.000% clipped samples. A genuinely clipped recording reads flat runs of fifty or more.

So the useful measurement is the longest flat run at full scale, not the peak level.

Why the average is the wrong statistic here

Most quality measurements over a long file should be reported as a median — one soft second in a whip pan is motion, not a defect, and a worst-takes-all rule would condemn almost everything real.

Clipping is the deliberate exception. It is cumulative damage. A file clipped solidly through three sections out of twenty is a damaged file, and a median reports 0.000% for it — a completely clean bill of health for audio that is provably broken in three places.

So clipping is reported as a total across everything read, not as a typical second. That is a departure from the rule, and it is the right one: the question is not “what is this file usually like”, it is “was anything destroyed”.

The trap that gets stereo files wrong

Audio samples arrive interleaved: left, right, left, right. Measure run length across that stream and a left channel clipped solid, beside a clean right channel, produces runs of one — because every second sample is fine.

A real file measured this way: a left channel 52% clipped in runs of 51 samples, reported as “no clipped samples”. The fix is to measure each channel separately. It sounds obvious written down and it is the kind of thing that survives for a long time, because the output is plausible.

What to do about it

If the clipping is in the recording, it is not recoverable. The samples that were above full scale were never written. Declipping tools interpolate a guess across the flat run; they can make it less obtrusive and they cannot restore what was not recorded. Re-record if you can.

If it appeared during export, it is entirely fixable and very common: - Summing tracks that individually peak near 0 pushes the sum past it. - Sample-rate conversion and lossy encoding both produce inter-sample peaks — a file that never clips at its own sample rate can clip when decoded. Leave 1 dB of headroom before encoding. - Normalising to 0.0 dBFS guarantees this. Normalise to −1.0 and the problem disappears.

If it appeared after upload to a platform, check the loudness. Streaming services normalise to a target (typically around −14 LUFS) and a master far louder than that gets turned down — which is fine — but a master mixed into clipping to be loud has already lost the detail before any of that happens.

Check a file

Upload one audio file and DiffALL reports clipping as the share of samples destroyed and the longest flat run, alongside loudness measured to the real BS.1770 standard, the file’s frequency range, its bitrate adjusted for its codec, and whether a stereo file carries actual stereo content. Where it finds clipping it marks the seconds it found it in, so you can go and listen.

If you have the file from before the step you suspect, comparing the two answers the sharper question: not is this clipped, but which stage clipped it.