LUFS Explained: How Loud Should Your Audio Actually Be?
Two files peak at exactly 0.0 dBFS. One is twice as loud as the other. Peak meters cannot tell you this, which is why they were replaced.
Why peak level is not loudness
A peak meter reports the single highest sample. Loudness is a function of energy over time, weighted by how sensitive human hearing is at each frequency — and hearing is dramatically less sensitive at the bottom of the range. A bass-heavy track and a vocal track with identical peaks are not remotely equally loud.
LUFS (Loudness Units relative to Full Scale) measures the thing you actually perceive. The standard is ITU-R BS.1770, and the mechanics are:
- Filter the signal with a K-weighting curve — a high shelf that approximates the head’s effect on incoming sound, plus a high-pass that discounts inaudible low frequencies.
- Take mean square energy in 400ms blocks.
- Gate — discard blocks more than 10 LU below the ungated average, so silence and quiet passages do not drag the number down.
- Sum across channels with defined weights.
The gate is the part that makes it useful. Without it, a podcast with long pauses measures quieter than the same voice with the pauses edited out, which is obviously wrong.
1 LU equals 1 dB. The units are relative to full scale, so the numbers are negative.
The targets
| Platform | Normalises to |
|---|---|
| Spotify | −14 LUFS |
| Apple Music | −16 LUFS |
| YouTube | −14 LUFS |
| Amazon Music | −14 LUFS |
| Tidal | −14 LUFS |
| Broadcast (EBU R128) | −23 LUFS |
| Podcasts (common practice) | −16 LUFS mono, −19 stereo |
These are normalisation targets, not limits. Deliver a master at −8 LUFS and Spotify turns it down 6 dB. Nothing is clipped and nothing is damaged — but every bit of dynamic range you crushed to get to −8 is still crushed, and it is now playing back at the same volume as the version you did not crush.
That is the whole argument against the loudness war in one sentence: the loudness is normalised away and the damage is not.
What to actually do
- Master to roughly −14 LUFS integrated for streaming, with true peak at −1 dBTP. If your material genuinely wants more dynamic range, go quieter; normalisation will bring it up.
- Do not master to −8 to “compete”. It has not worked since platform normalisation became universal.
- Leave 1 dB of true-peak headroom before lossy encoding. A file that never clips at its own sample rate can clip once decoded, because reconstruction between samples overshoots. Normalising to 0.0 dBFS guarantees this happens.
- Check loudness and clipping together. They are different questions — one is how loud, the other is whether anything was destroyed — and a file can fail either independently.
The bug in most loudness code
Worth knowing if you ever implement this, and worth being suspicious of in tools that do.
The BS.1770 K-weighting filter is published as twelve coefficients at 48kHz. A great deal of loudness code ships those constants and applies them to 44.1kHz audio. The filter shape is then wrong for the material — worth up to 0.4 dB of error around 2kHz.
The correct approach is to derive the coefficients at whatever sample rate the file actually has, and then verify against the published values: derive at 48kHz and you should reproduce the twelve published numbers essentially exactly. A second check worth running is a mono 1kHz sine, which should read its own RMS to within a fraction of a dB at every sample rate.
That second identity is not academic. A mis-assembled high shelf in an early implementation of this read every file 0.28 dB hot — a small, consistent, entirely invisible error that no amount of listening would have found, and that the compliance test caught immediately.
Check a file
Upload one audio file and DiffALL reports integrated loudness measured to BS.1770 with filters derived at the file’s own sample rate, alongside clipping as both a percentage and the longest flat run, the frequency range the content actually reaches, the bitrate adjusted for the real codec, and whether a stereo file carries stereo content or is two copies of a mono one.
Comparing a master against its export is the other question entirely — that is the comparison tool, and it answers what a specific encoding step changed, second by second.
No original to compare against? DiffALL measures one file on its own and names what is wrong with it.
Check a file — free