Tutorials Audio

What's Actually Happening When You 'Normalize' Audio

By Infinite Creation · Intermediate · ~14 min

A 1960s mid-century comic book style editorial illustration showing two audio engineers at a mixing desk, with a mixing desk, a studio microphone on a boom arm, an audio waveform display visible in the frame.

Overview

'Normalize' is used loosely to describe at least two genuinely different processes, peak normalization and loudness (LUFS) normalization, that can produce very different results on the same file, and understanding the actual mathematical difference explains why a 'normalized' file doesn't always sound as loud as expected.

Steps

The simple version: normalization adjusts overall volume to a target

At the simplest level, normalization looks at a specific measurement of an audio file's level and uniformly raises or lowers the entire file's volume so that measurement hits a specific target. The file's internal dynamics (louder and quieter parts relative to each other) stay the same, only the overall level shifts.

What's really happening: peak normalization measures the single loudest instant

Peak normalization looks only at the single loudest instantaneous sample in the entire file and adjusts overall gain so that peak hits a target level (often just below 0dBFS, the digital maximum). It says nothing about how loud the file sounds overall to a human listener, since a file with one brief loud spike and mostly quiet content will normalize to sound quieter overall than a consistently loud file with the same peak.

What's really happening: loudness (LUFS) normalization measures perceived average loudness

Loudness normalization uses a measurement (LUFS, loudness units relative to full scale) that approximates how loud a human actually perceives the file to be on average over time, accounting for the ear's varying sensitivity to different frequencies. This is what streaming and podcast platforms actually use for their normalization, which is why understanding LUFS matters more than peak level for most modern delivery.

Why the difference matters practically

A file that's been peak-normalized to just below 0dBFS can still sound quieter or louder than a different file peak-normalized to the same level, because peak normalization ignores how the perceived loudness accumulates over the whole file. This is exactly why this site's loudness cheat sheet and myth-busting tutorial on loudness both emphasize LUFS targets specifically, not peak levels, for anything being delivered to a modern streaming or podcast platform.

Tested: five clips, three kinds of normalization

We tested steps 1 to 4 on 2026-09-28 with FFmpeg 8.1.2. We made five 20-second clips with a computer, each with a known shape: loud music-like noise, speech-like bursts with pauses, a quiet room with one door slam, a low bass drone and a high hiss. Each clip was normalized three ways with a plain gain change: its loudest sample to -1 dBFS, its RMS (the average signal level) to -20 dBFS, and its integrated loudness to -16 LUFS. Then every result was measured with FFmpeg's EBU R128 loudness meter. The table shows how loud each clip ended up after the first two, and where its peaks landed after the third.

Clip	Loudness after peak to -1 dBFS	Loudness after RMS to -20 dBFS	True peak after loudness to -16 LUFS
Loud mastered-style music	-8.3 LUFS	-19.2 LUFS	-8.6 dBTP
Speech-like bursts with pauses	-17.8 LUFS	-18.5 LUFS	+0.8 dBTP
Quiet room, one door slam	-40.9 LUFS	-18.0 LUFS	+24.0 dBTP
Bass drone (55 Hz and harmonics)	-9.0 LUFS	-23.3 LUFS	-8.1 dBTP
High hiss (2 to 10 kHz)	-11.6 LUFS	-16.8 LUFS	-5.4 dBTP
Spread from quietest to loudest	32.6 LU	6.5 LU	0.0 LU

Step 2 holds by a wide margin. After peak normalization the music and the door slam both peaked at -1 dBFS, and the slam clip measured 32.6 LU quieter, because one 30-millisecond burst set its level and the rest of the clip is a quiet room. That is Pro Tip 3 in one number: the same peak says almost nothing about how loud a file sounds.

RMS normalization came much closer, with a spread of 6.5 LU, but it treats every frequency alike. At the same RMS the hiss measured 6.5 LU louder than the bass drone, because the loudness meter weights frequencies roughly as the ear does, as step 3 describes, and RMS does not. Loudness normalization brought all five to the same measured loudness, which it does by definition.

The FAQ's first answer holds too. The music, peak normalized to -1 dBFS, measured -8.3 LUFS, so a service that plays everything at -16 LUFS would turn it down by 7.7 dB, whatever its peak level.

Loudness normalization has a cost the steps do not mention. Bringing the slam clip up to -16 LUFS with a plain gain change put its peak at +24.0 dBTP, and the speech-like clip reached +0.8 dBTP, both above full scale, where a fixed-point file or a player would clip them. So a quiet, spiky recording cannot reach a loudness target by gain alone.

Step 1 says normalization leaves a file's dynamics as they were. For a plain gain change that held exactly: the loudness range of every clip was the same before and after all fifteen changes. It does not hold for every tool with "normalize" in its name. We ran FFmpeg's loudnorm filter in two passes with linear=true, which asks it for a plain gain change, with a -16 LUFS target, a -1 dBTP ceiling and a loudness range target wide enough for every clip. For the hiss it did that. For the slam and speech clips a plain gain would have broken the ceiling, so it switched to changing the level over time, as its documentation says it will. The slam clip's peaks went from 40 dB above its loudness to 15 dB, and its loudness range from 8.9 to 4.2 LU. FFmpeg reports which mode it used in its JSON summary, as normalization_type, so read that line.

The music and the drone were a surprise. A plain gain would have left their peaks at -8.6 and -8.0 dBTP, well under the ceiling, yet loudnorm still reported dynamic mode for both. Its first pass measured their loudness range as exactly 0.00 LU, because they barely change from start to finish. FFmpeg's source code treats a measured range of 0 as one that was never supplied, and then skips linear mode. The documentation does not mention this. On clips this steady the result stayed close to a plain gain (loudness range 0.1 and 0.0 LU afterwards), but it was not one. For a truly plain gain on steady material, measure with ebur128 and apply the difference with the volume filter.

To read a file's integrated loudness, loudness range and true peak with FFmpeg before choosing a gain: ffmpeg -i input.wav -af ebur128=peak=true -f null -

Validated. Measured 2026-09-28 with FFmpeg 8.1.2 (volume, astats, ebur128 and loudnorm) and numpy. The clips are computer-generated noise and tones with the shapes described, not real music or speech, so real recordings will give different figures. The pattern does not depend on that. Gain changes were made in 32-bit floating point so that peaks above full scale could be measured. We did not test any streaming or podcast platform's own normalization.

Pro Tips

Check whether your export or streaming target specifies a LUFS loudness target or a peak (dBFS) target. They're measuring genuinely different things and require different tools/settings to hit correctly.
Use a LUFS-capable loudness meter, not just a peak meter, if your delivery platform (most modern streaming and podcast platforms) specifies a loudness normalization target.
Don't assume two files peak-normalized to the same level will sound equally loud. Their average perceived loudness can differ significantly depending on their internal dynamics.

Knowledge Base

What You'll Learn

'Normalization' commonly refers to two different processes, peak normalization (matching the single loudest instant) and loudness normalization (matching average perceived loudness via LUFS), and modern streaming platforms use LUFS specifically, which is why understanding the distinction matters practically.

The Plain-English Version

Peak normalization asks 'what's the loudest single moment, and how do I adjust the whole file so that moment hits my target?' Loudness normalization asks 'how loud does this whole file sound on average to a human, and how do I adjust it so that average hits my target?', very different questions with very different answers on the same file.

The Misunderstanding This Clears Up

People sometimes assume 'normalizing' a file guarantees it will sound appropriately loud on a streaming platform, but if you only peak-normalized rather than loudness-normalized to the platform's actual LUFS target, the platform's own normalization may turn your file down (or up) further than you expected.

Where This Fits

Normalisation changes the level of a finished file, and Mixing a Full Song covers the level decisions made inside the mix.

FAQ

Q: Why did my normalized podcast episode still get turned down by the platform?
A: You likely peak-normalized (matching the single loudest instant to a target) rather than loudness-normalized to LUFS (matching the average perceived loudness). Most platforms specifically normalize based on LUFS, so a peak-normalized file that exceeds the platform's LUFS target still gets turned down regardless of its peak level.

Q: Which type of normalization should I use for streaming or podcast delivery?
A: Loudness (LUFS) normalization, matched to your specific platform's target level, since that's what modern streaming and podcast platforms actually use to normalize incoming audio. This site's loudness cheat sheet covers the specific targets for different delivery contexts.