A file whose highest sample reads 0.0 dBFS is not a file whose signal reaches 0 dB. Between any two samples the reconstructed waveform can rise above both of them, and a sample-peak meter is structurally incapable of seeing that. Then a lossy codec — the thing every streaming service applies to your master before anyone hears it — pushes those excursions higher still. The result is a master that measured clean in your DAW and distorts on playback, and none of it is a matter of opinion. It is a consequence of how sampled audio is reconstructed.
This article covers what a sample peak and a true peak actually are, why oversampling is the only way to measure the second, what a 4× meter can and cannot see, and which of the three standardised loudness meters answers which question. What each service publishes as a target, and what happens to quiet masters, is covered separately in what actually happens to your master.
A sample peak is the tallest point in the file. A true peak is not in the file.
A sample-peak meter reports the largest absolute sample value in the file. That is a real number and it is easy to compute — you look at every sample and keep the biggest.
But samples are points on a continuous waveform, not the waveform itself. The waveform passing through those points can rise above both of them between them. The reconstructed analogue waveform can exceed the highest sample in the file, and a sample-peak meter has no mechanism for detecting this. Those excursions are inter-sample peaks. The level of the reconstructed waveform, including them, is true peak, expressed in dBTP.
This is why "nothing is clipped" and "nothing will clip" are two different claims. A digitally safe file whose samples top out at −0.1 dBFS can have true peaks well above 0 dBTP. Nothing in the file is over. Everything downstream that reconstructs the waveform — a DAC, a sample-rate converter, a lossy decoder — may clip it.
The practical test is blunt: a meter without an explicit true-peak or dBTP mode is a sample-peak meter, whatever its manual implies. That includes most of the level meters built into DAWs, and it includes the ceiling control on a great many limiters.
Why lossy encoding makes it worse, not neutral
Streaming does not deliver your WAV. It delivers an AAC, Ogg Vorbis or MP3 encoding of it, and a lossy codec does not reproduce your waveform sample for sample. It reproduces a perceptually similar one. The decoder's output routinely overshoots the encoder's input.
That overshoot is not a bug in any particular encoder. It is an unavoidable consequence of quantising and discarding spectral detail, and — this is the part that matters for mastering decisions — it scales with how hard the source was limited. The more aggressively you flattened the signal against the ceiling, the more overshoot the codec produces on the way back out.
So a master sitting at exactly 0.0 dBTP decodes with peaks above 0 dBFS, and the decoder clips them. You never hear this on your own file. You hear it on the version the listener gets.
Every published specification that addresses this reaches the same conclusion. AES TD1008 states: "For all content, it is recommended that the Maximum True Peak level not exceed −1 dBTP at the codec input of lossy-encoded streams." Spotify asks you to keep true peak "below −1dB TP (True Peak) max", and, for masters louder than −14 LUFS, to "keep True Peak below −2dB to avoid extra distortion."
The second Spotify figure is the interesting one. It exists precisely because harder-limited material overshoots more in the codec. The ceiling is not a fixed superstition; it tightens as the material gets denser.
What oversampling is doing, and what 4× cannot see
To measure a peak that is not in the file, you have to reconstruct the waveform between the samples. ITU-R BS.1770 specifies doing that by oversampling — interpolating additional sample points and then measuring the peak of the denser signal.
The recommendation sets a minimum of 4× oversampling at 48 kHz, and notes that "Higher sampling rates and over-sampling ratios are preferred."
Read that as written. 4× is a conformance floor, not the accurate answer. A 4× meter is guaranteed to catch more than a sample-peak meter and is not guaranteed to catch everything; at 4×, the measurement can still under-read genuine peaks by a few tenths of a dB. Those tenths are exactly the size of the margin people try to shave off a ceiling.
| What you are using | What it reports | What it misses |
|---|---|---|
| Sample-peak meter | Largest sample value in the file | Every inter-sample peak; the entire codec overshoot question |
| 4× true-peak meter | Reconstructed peak at the BS.1770 conformance floor | Can still under-read genuine peaks by a few tenths of a dB |
| 8× or 16× true-peak meter | A closer estimate of the reconstructed peak | Progressively less, at trivial CPU cost |
Use 8× or 16× oversampling if your meter offers it. The additional CPU cost is trivial and the additional accuracy is not.
There is a companion trap on the limiter side. A true-peak ceiling set to −1.0 dBTP only means something if the limiter is actually doing true-peak limiting. Many limiters' ceiling controls are sample-peak, and setting one to −1.0 gives you inter-sample peaks somewhere above −0.5 dBTP — half your margin gone before the codec has touched the file.
Which edition of the standard your meter is citing
BS.1770 has six editions: 2006, 2007, 2011, 2012, 2015 and 2023. BS.1770-4 (October 2015) is the edition most deployed meters cite; BS.1770-5 (November 2023) is the edition currently in force. The 4× oversampling floor, the filter stages and both gates described here are verified against BS.1770-5 as published.
This is worth knowing mainly so you read your meter's documentation correctly. A meter citing -4 is not thereby wrong, but -5 is the current text and is the one to name when you are checking a claim against a document.
Momentary, short-term, integrated: three meters, three questions
The other half of the problem is that most people read the wrong loudness meter for the decision they are making. EBU Tech 3341 defines three windows, and they answer three genuinely different questions.
Momentary (M) — 400 ms, ungated. The same window as a BS.1770 gating block. Momentary loudness tracks individual events: a snare, a vocal consonant, a downbeat. Use it for catching things — a kick that spikes 6 LU above everything around it, a section that jumps out. Do not use it to make level decisions. It is far too twitchy, and chasing a momentary meter produces exactly the over-compressed result that playback normalisation punishes.
Short-term (S) — 3 s, ungated. Three seconds is roughly a musical phrase. Short-term loudness is the right meter for balance decisions inside a track, because three seconds is the timescale on which listeners actually perceive a section as loud or quiet. Use it to compare a verse against a chorus, to check that a bridge does not collapse, and to see the shape of your arrangement as a number.
Integrated (I) — whole programme, doubly gated. This is the number services normalise against and the only one that belongs in a delivery spec. It is measured over the entire track, first sample to last, not over a selected section. Integrated loudness is a delivery specification, not a mixing tool; if you are watching it while you work, you are watching the wrong meter.
| Meter | Window | Gating | The question it answers |
|---|---|---|---|
| Momentary | 400 ms | None | What just happened? |
| Short-term | 3 s | None | Is this section balanced against that one? |
| Integrated | Whole programme | Absolute −70 LKFS, then relative −10 LU | What will the service measure at delivery? |
The rule that follows: mix and master by short-term, verify by integrated, investigate anomalies with momentary.
The mistake this actually causes
The common error is watching integrated loudness while mastering and adding limiting until it reads the number someone told you to hit. That behaviour has two separate failures stacked on top of each other.
The first is that integrated loudness is doubly gated, and the gating means it is not measuring what people assume. Blocks below −70 LKFS are discarded outright. Then the mean of the surviving blocks is computed, 10 is subtracted from it, and every block below that relative threshold is discarded too. The relative gate sits 10 LU below the absolute-gated mean, not 10 LU below the ungated mean of the whole file. The consequence for your working session is direct: the integrated loudness of your track is effectively the average loudness of its loud parts, not of the track as a whole. A song with a whispered 40-second intro and a wall-of-sound chorus is measured almost entirely on its choruses. Adding a quiet intro to a finished master barely moves the integrated reading, and engineers who expect it to are surprised.
The second failure is that Loudness Range uses a different gate again. LRA, specified in EBU Tech 3342, is the difference between the estimates of the 10th and 95th percentiles of the short-term loudness distribution, and Tech 3342 sets its relative threshold at −20 LU below the absolute-gated loudness level, not −10 LU. The wider gate is deliberate — LRA is characterising variation, so it must admit the quieter passages the integrated measurement is designed to exclude. Meters that reuse the integrated −10 LU gate for LRA report values that are systematically too small. If your meter reports an LRA noticeably lower than another meter on the same file, suspect a −10 LU gate where −20 LU belongs.
You can test this in a few minutes. Append 20 seconds of material 15 LU below the body of the track. A correct implementation's LRA rises substantially. A broken one barely moves.
What to actually deliver
The guidance is short, and every figure in it is published.
- Fix the ceiling first: −1.0 dBTP, true-peak, oversampled. This is the only genuinely hard constraint in the list. Use −2.0 dBTP if your master is louder than −14 LUFS integrated — the tighter figure exists because harder-limited material overshoots more in the codec.
- Master for the music. Get balance, tone and dynamics right with the limiter doing as little as possible, and do not look at the integrated meter during this stage.
- Measure the result. Whatever integrated loudness you arrived at is your candidate. If it sits between roughly −14 and −9 LUFS, every published target and every reported figure lives within a few LU of you. Louder than −9 LUFS, ask what the limiting bought.
- Adjust by changing the mastering, not by adding limiting. Targeting a LUFS number by adding limiting until the meter reads correctly is the exact behaviour normalisation was designed to make pointless.
Two things not to do. A ceiling of −0.1 dBTP is a delivery error for streaming, not a stylistic choice. And do not cut different masters for different services — the published and reported targets span roughly 2 LU, hitting a number exactly changes nothing audible, and one master at −1 dBTP with sensible dynamics is correct everywhere.
If you want to check a finished file before you deliver it, Mazufa hosts a free loudness and true-peak checker at /loudness-checker. It runs entirely in your own browser and uploads no audio.
Sources
ITU-R BS.1770 — measurement algorithm, K-weighting, gating, true peak
- Recommendation ITU-R BS.1770-5 (11/2023), Algorithms to measure audio programme loudness and true-peak audio level (full text PDF): https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-5-202311-I!!PDF-E.pdf
- BS.1770 recommendation page and edition history (BS.1770-0 through BS.1770-5): https://www.itu.int/rec/R-REC-BS.1770/en
EBU — meter windows and Loudness Range
- EBU Tech 3341, Loudness Metering: EBU Mode metering to supplement EBU R 128 (momentary 400 ms, short-term 3 s): https://tech.ebu.ch/publications/tech3341
- EBU Tech 3342, Loudness Range: A measure to supplement EBU R 128 loudness normalisation (−20 LU gate; 10th/95th percentiles), PDF: https://tech.ebu.ch/docs/tech/tech3342.pdf
AES — true-peak ceiling at the codec input
- AES TD1008.1.21-9, Recommendations for Loudness of Internet Audio Streaming and On-Demand Distribution (−1 dBTP at the codec input), PDF: https://aes2.org/wp-content/uploads/2024/01/20210924_TD1008_v3.13.pdf
- AES TD1008 document page: https://aes.org/technical-council/technical-document-aestd1008/
Spotify — published true-peak ceilings
- Spotify for Artists, Loudness normalization (−1 dBTP; −2 dBTP for masters louder than −14 LUFS): https://support.spotify.com/us/artists/article/loudness-normalization/