Normalize Audio

What this does

Every sample in the file is scanned to find the single loudest peak, and then the whole signal is multiplied by one gain factor so that peak lands exactly on the target you chose. The relative dynamics are untouched — quiet passages stay proportionally quiet, loud ones stay proportionally loud — and the entire file simply moves up, or occasionally down, to a known ceiling.

Because it is one multiplication applied uniformly, nothing is compressed, limited or coloured. Run it twice and the second pass does nothing, since the peak is already where you asked for it. That predictability is the point: it is the safe operation to reach for when you do not know what else has been done to a file.

Which target to pick

The number is dBFS, decibels relative to full scale, and it is always negative because 0 dBFS is the loudest a digital file can represent. The setting you want depends entirely on where the audio goes next.

• -1 dB for something a person will listen to directly — a voice memo, an interview, a lecture recording. It is as loud as the file can honestly go with a sliver of headroom left.
• -3 dB when the file is going to be converted again afterwards. Lossy encoders can overshoot the original peak slightly on decode, and that margin absorbs it.
• -6 dB when the audio is one layer of something larger: a stem going into Ableton or Logic, a bed under a voiceover, a clip that will be mixed with others. Leaving room is what makes the mix possible.

Why it sometimes seems to do nothing

This is the most common surprise, and it is not a bug. Peak normalization is governed entirely by the single loudest instant in the file. One door slam, one coughed microphone bump, one stray clipped transient, and that sample is already near full scale — so the calculated gain is close to 1.0 and everything else stays exactly as quiet as it was.

The fix is to find and remove the offender rather than to normalize harder. Cut it out with the cutter, or if the recording is generally quiet with occasional spikes, compression is the tool that actually raises the average level rather than the peak.

Peak is not loudness

Two files normalized to the same peak can sound wildly different in volume, because human loudness perception tracks average energy over time, not the highest instantaneous sample. This is why streaming services use LUFS instead: Spotify targets around -14 LUFS, Apple Music about -16, YouTube roughly -14. Those platforms will turn your track down to hit their number regardless of what you did here, so normalizing to -1 before uploading buys nothing except a smaller safety margin. If that is the job, use the LUFS normalizer.

Peak normalization is the right tool when you need a known ceiling — no clipping, predictable headroom, nothing else changed. It is the wrong tool when you need two files to sound equally loud to a listener. For that, the LUFS normalizer measures loudness the way the platforms do and moves the file to their target.

What it will not repair

If the audio was recorded so hot that it already clipped, the waveform is squared off and the information is gone. Turning it down afterwards makes a quieter distorted file, not a clean one. Nothing recovers a clipped recording, here or anywhere, which is why every meter is worth watching on the way in rather than on the way out.

Equally, a recording that is quiet because the microphone was too far away has a noise floor that comes up with the signal. Normalizing a hissy file gives you a louder hiss along with the louder voice; run noise reduction first, then normalize, in that order.