Peak Normalisation Versus Loudness Normalisation, and the Target That Cannot Be Reached

Peak and loudness answer two different questions

Peak normalisation asks: what is the single loudest sample in this file, and by what constant do I multiply everything so that sample lands exactly on a chosen ceiling? It is one measurement and one multiplication. It is fast, exact and almost useless for making two recordings sound equally loud, because the loudest instant of a piece of audio tells you nothing about how loud it feels. A sparse recording of a voice with one door slam in it, and a dense wall of music, can both peak at exactly the same sample value while one sounds several times louder than the other.

Loudness normalisation asks the other question: how loud does this whole programme feel, and by how much must I move it so it feels as loud as everything else? Answering it requires a model of hearing, and there is one: ITU-R BS.1770 defines a filter that approximates the ear's frequency response, sums the channels with fixed weights, and — crucially — gates out the quiet parts so a long silence at the end does not drag the number down. The result is a loudness in LUFS, and two files that measure the same LUFS really do sound about equally loud. EBU R 128 is the practice built on top of that measurement, and it is where the target numbers come from.

This tool only does the second. There is no peak-normalisation button, and that is the right choice: peak normalisation is what a file manager's "normalize" checkbox used to mean and it almost never did what people wanted. What the tool does keep from the peak world is a ceiling — a true-peak limit, set to −1 dBTP by default — and that ceiling turns out to be the most consequential control on the page, for reasons the third section gets to.

Two passes, and why one is not enough

A single-pass loudness normaliser has an impossible job: it must decide, at every moment, how much gain to apply, knowing only what it has already heard. Faced with a quiet opening it lifts it, and then a loud chorus arrives that it has to push back down. The result is a recording whose internal balance has been rearranged by an algorithm making guesses about the future — which is a compressor, not a normaliser, and it is not what anyone asking for normalisation had in mind.

The two-pass form removes the guesswork. The first pass reads the whole programme and prints its measurements: integrated loudness, true peak, loudness range and the gating threshold it used. Those four numbers, plus a target offset, are handed back to the second pass, which now knows the answer before it starts and can apply one constant gain from beginning to end. Nothing is rearranged; the recording is simply moved. That is what linear normalisation means, and it is what the tool asks for with linear=true.

When there is headroom, this works exactly as advertised. A steady test tone measuring −29.75 LUFS with peaks far down at −26.02 dBTP, asked for the broadcast target of −23 LUFS, came out at −23.05 LUFS: five hundredths of a decibel from the mark, which for practical purposes is the mark. The design is sound. The problem is what happens when there is no headroom.

The target you ask for is not always the target you get

linear=true is not an instruction, it is a preference. ffmpeg's loudnorm applies a constant gain only when doing so keeps the true peak under the ceiling you set. If the constant gain the measurements imply would breach that ceiling, the filter quietly abandons linear mode and falls back to its dynamic algorithm — which respects the ceiling and, in doing so, cannot reach your loudness target. Nothing in the log announces the switch. The tool used to print the number you asked for and call the difference "correction applied"; it now sends the file it produced back through the same meter and prints what came back, so the figure on screen is one that was measured rather than one that was requested.

Here is what that costs on entirely ordinary material. Take a programme measuring −16.06 LUFS whose peaks sit at −0.09 dBTP — a completely normal profile for anything mastered in the last twenty years, since almost everything is pushed close to full scale. Ask for the default streaming target of −14 LUFS with the default −1 dBTP ceiling. A linear gain of about two decibels would put those peaks at roughly +1.9 dBTP, so linear mode is refused. The result file measures −15.59 LUFS: the real gain was half a decibel, not the two a target-based readout would claim. The panel used to read "Measured: −16.1 LUFS → −14.0 LUFS · Correction applied: +2.1 LU", every word of which was an assumption dressed as a measurement. It now reads −15.59, because the output is measured before anything is shown — and when the achieved figure sits half a unit or more from the target, the target is printed beside it so you can see the filter declined.

The gap widens on material with a wide loudness range. A programme at −13.15 LUFS with a single full-scale transient in it, asked for −14 LUFS, came out at −26.71 LUFS — nearly thirteen decibels below the target, and audibly quiet. Running the same file through a plain single-pass loudnorm, the thing the tool's own note warns against, landed at −14.75 LUFS. That is not an argument against two passes; two passes are right for the great majority of files. It is an argument for distrusting a readout that was never measured. If the result sounds wrong, it may well be wrong, and the way to find out is to measure the output yourself rather than to read the panel.

Which target, and why louder is not better

Three presets cover most needs. −23 LUFS is the European broadcast target, written into EBU R 128 and expected by television. −16 LUFS is common practice for spoken-word podcasts, not a standard anyone publishes. −14 LUFS is roughly where the big streaming services normalise playback, and it is the default here. The preset hint groups Spotify, YouTube and Apple Music together at −14; published figures for those services have moved over the years and are not all the same number, so treat −14 as the neighbourhood rather than a specification, and use the custom slider if you have been given a figure to hit.

The thing worth internalising is that on a normalising platform, delivering louder than the target gains you nothing. The platform turns your track down to its own reference on the way to the listener. What does not come back is whatever you sacrificed to get loud in the first place — the transients you flattened, the dynamics you squeezed. You arrive at the same playback volume as everyone else, with less left inside the recording. Normalising up front, to the number the destination uses, is how you keep the dynamics and still land at the right volume.

Normalising cannot undo clipping that is already there

Clipping happens when a signal was asked to exceed the maximum value a sample can hold, and the parts above that maximum were simply cut off. What remains is a flat top where a curve used to be, and the sound it produces is the harsh edge people call distortion. The information that was above the ceiling is not attenuated or hidden; it does not exist in the file. No later processing can bring it back, because nothing recorded what it was.

Running a clipped source through this tool demonstrates the point cleanly. A deliberately clipped test file measured −1.55 LUFS with a true peak of +0.10 dBTP — above full scale, which is exactly what a true-peak meter is for: it reconstructs what happens between samples and finds the overshoots a sample-peak meter misses. Normalised to −14 LUFS it came out at −14.35 LUFS with a true peak of −12.67 dBTP. The level is now correct and the ceiling is comfortably respected. The flat tops are still flat. Turning distortion down makes it quieter distortion.

What comes out — and the file you cannot get in

Hand it a video and the picture is copied with -c:v copy, untouched, while the sound is replaced by a fresh AAC track at 192 kbps — Opus at the same rate for a WebM container, since WebM cannot carry AAC. Hand it audio and you choose the output: MP3 at 192 kbps by default, or WAV as 16-bit PCM, M4A as AAC, OGG as Vorbis at quality 5, or FLAC. There is no stream-copy path, which is unavoidable — the samples have been changed, so they have to be written again. If your source is lossless, choose FLAC or WAV; leaving the default on MP3 converts a lossless master into a lossy one as a side effect of adjusting its volume.

One thing used to stop readers before they started. Although the tool is named for audio, offers five audio output formats and prints "Choose an audio or video file" above its drop zone, its file picker was configured for video only: the accepted list held MP4, MOV, WebM, MKV, AVI and M4V and no audio type at all, so dragging an MP3 onto the zone was rejected as the wrong kind and the whole audio-only branch — the format buttons, the MP3 and FLAC outputs — was unreachable through the picker. The picker now accepts both, and the label finally describes what the tool does. It is worth knowing why that kind of fault survives: everything downstream of the picker worked perfectly, so nothing failed, tested, or logged anything. The feature was simply behind a door nobody could open.

Frequently asked questions

Does this tool do peak normalisation as well?

No. It only does loudness normalisation, through ffmpeg's loudnorm filter, which measures in LUFS using the ITU-R BS.1770 method. What it keeps from the peak world is a true-peak ceiling, which is a limit rather than a target: it says how close to full scale the result is allowed to come, not how loud it should be. If you genuinely wanted peak normalisation — every file scaled so its loudest sample sits at the same value — you would find the two clips still sounded quite different from one another, which is why almost nobody wants it once they have heard the alternative.

The panel says it reached my target. Can I rely on that number?

Only the first half of it. The "Measured" figure is real — it comes out of the first pass, which genuinely analysed your file. The second figure is not a measurement at all: it is the target you selected, printed back to you, and the correction shown is simply the arithmetic difference between the two. If ffmpeg declined the linear gain because it would have breached the true-peak ceiling, the output is somewhere else entirely and nothing on the page will tell you. The tell-tale is a source that already peaks near full scale and is quieter than your target: that combination cannot be satisfied, and the result will fall short.

What should I set the true-peak ceiling to?

Leave it at −1 dBTP for anything that will be encoded again after you, which is nearly everything. A lossy encoder does not reproduce your samples exactly; it reconstructs an approximation, and that approximation can overshoot slightly above where your samples were. Leaving a decibel of room means the overshoot has somewhere to go instead of clipping in the listener's player. Raising the ceiling towards zero buys you a little more loudness and spends your safety margin, and it also makes the linear-mode refusal described above more likely, not less — a higher ceiling is easier to breach in absolute terms only if your target is higher too.

Can normalising repair a recording that is already distorted?

No, and this is worth being blunt about. If the recording clipped when it was made, the peaks above the maximum were discarded at that moment; the file contains flat tops where waveforms used to be, and there is no record anywhere of what the missing parts looked like. Normalising changes the level, so the distortion becomes quieter distortion, but the shape stays. A clipped test file measuring a true peak of +0.10 dBTP came out of the tool at −14.35 LUFS with its peaks safely at −12.67 dBTP and its flat tops entirely intact. If you can re-record, re-record. If you cannot, specialised de-clipping software guesses at the missing curve, with mixed results.

What is the loudness-range slider for, and should I touch it?

It describes how much the level is allowed to move across the programme, measured in loudness units, and it defaults to 11 LU. It matters when loudnorm is working dynamically rather than linearly: a lower figure squashes the difference between the quiet and loud parts flatter, a higher one leaves them further apart. When the linear path is taken — the normal case, when there is headroom — the whole programme is moved by one constant and the range is untouched, so the slider changes nothing at all. Leave it where it is unless someone has specified a range for you, and if you find yourself lowering it to make quiet speech audible, what you actually want is a compressor, not a normaliser.