True Peak Limiting for Streaming: Why -1 dBTP Matters
Set your master's true peak ceiling to -1 dBTP because streaming codecs add inter-sample peaks during encoding. A file that reads -0.1 dBFS on a sample meter can hit positive true peaks after the encoder reconstructs it, which clips on the listener's device. The -1 dB of headroom absorbs that.
Here's the thing most people miss about mastering for streaming: the number on your peak meter isn't the number the listener hears. Your DAW shows you sample peaks, the level of the individual digital points in the file. But the moment that file gets converted back to analog or run through a lossy encoder, the waveform between those points can overshoot the ceiling. That's an inter-sample peak, and it's why -1 dBTP exists.
This page covers the true peak side of mastering for streaming. The LUFS targets and the loudness normalization that makes them matter live on the sibling pages. Here I'm just covering peaks: what true peak metering measures, why inter-sample peaks get worse after a codec touches your file, and why every major platform landed on the same -1 dBTP ceiling.
true peak ceiling every major platform converges on
how far an inter-sample peak can exceed the sample peak in extreme cases
extra peak an AAC encoder can add over the source WAV
minimum oversampling a true peak meter uses, per ITU-R BS.1770
Key takeaways
- True peak (dBTP) measures the reconstructed analog waveform between samples. A sample peak meter doesn't see that, so it can read clean while the real peak clips.
- Inter-sample peaks can exceed the sample peak by up to 3 dB in extreme cases. A master reading -0.1 dBFS could have true peaks at +2.9 dBFS.
- Lossy encoding compounds the problem. An AAC encoder can produce peaks higher than the source WAV.
- Set the ceiling to -1 dBTP and you lose almost nothing in loudness, typically under 0.1 LU, but you eliminate a class of distortion you can't fix after encoding.
- A real true peak limiter runs at 4x oversampling or higher. A standard sample-peak brickwall limiter won't catch inter-sample peaks.
What's the difference between sample peak and true peak?
A sample peak meter reads the amplitude of the individual discrete sample points in your file. That's what your DAW's default meter shows. A true peak meter, marked in dBTP for decibels True Peak, measures the maximum level of the reconstructed analog waveform between those sample points. That's the level that comes out when a DAC or an encoder rebuilds the curve.
Those two numbers diverge, and the gap can be large. The signal between two samples isn't a straight line. It's a curve, and that curve can rise higher than either sample on its ends. When it overshoots 0 dBFS, you get an inter-sample peak: a clip that no sample meter ever flagged because no individual sample crossed the line.
To see it, the true peak meter upsamples the signal. ITU-R BS.1770, the standard that defines loudness and true peak measurement, specifies a minimum of 4x oversampling. The meter reconstructs the in-between waveform and reports the real ceiling.
Why a -0.1 dBFS master can still clip
This is the part that surprises people. You can master a track so your sample peak meter never crosses -0.1 dBFS, ship it, and still hear clipping on playback. Inter-sample peaks can exceed the sample peak by up to 3 dB in extreme cases. So a master that reads -0.1 dBFS on a sample meter could have true peaks sitting at +2.9 dBFS. Any DAC or codec encoder that hits that overshoot clips hard.
The meter that lies
High-frequency, high-amplitude material is the worst offender. When the waveform oscillates steeply between samples, like bright cymbals or a loud, dense mix, that's exactly when the in-between curve overshoots furthest. Those tracks often look fine on a sample meter right up until the DAC reconstructs them.
Lossy codecs make inter-sample peaks worse
Streaming doesn't deliver your WAV. Spotify serves Ogg Vorbis and AAC, Apple Music serves AAC, YouTube serves AAC and Opus. Every master gets transcoded at least once before it reaches a listener. Lossy encoders throw away audio data they judge inaudible, then rebuild the signal from a mathematical model. That reconstruction introduces its own inter-sample behavior.
The practical result: a 24-bit/44.1 kHz WAV with modest inter-sample peaks can come out of an AAC encoder with peaks up to 1 dB higher than the source. So even a master that was technically under 0 dBTP can clip after encoding. Without headroom, that transcoding adds harshness and brittleness on loud transients, and it can't be undone after the fact.
This is exactly why Apple's Apple Digital Masters program requires -1 dBTP and makes you run the AURoundTripAAC test, which encodes to AAC and back so you can hear what the codec did. The requirement exists because AAC transcoding of masters without enough true peak headroom produces audible degradation.
Where the -1 dBTP standard comes from
It started in broadcast. EBU R 128 mandates a maximum true peak of -1 dBTP for broadcast content, and that became the basis for the streaming version. AES TD1008, the industry-consensus streaming recommendation from 2021, also lands on -1 dBTP as the true peak ceiling for audio distributed via streaming and download.
Then every major platform converged on the same number independently. Apple Music and Apple Digital Masters want -1 dBTP. YouTube recommends -1 dBTP. Tidal lands at -1 dBTP. Spotify's guidance is a little more specific: keep true peak below -1 dBFS for lossy delivery, and below -2 dBTP for masters louder than -14 LUFS, since a louder, more limited master leaves the encoder less room to work.
| True peak ceiling | Where it's stated | |
|---|---|---|
| EBU R 128 (broadcast) | -1 dBTP max | The original mandate the streaming standard is built on |
| AES TD1008 (streaming) | -1 dBTP | Industry-consensus recommendation, 2021 |
| Apple Music / Apple Digital Masters | -1 dBTP | Required; validated with afclip and AURoundTripAAC |
| Spotify | Below -1 dBFS lossy, -2 dBTP if louder than -14 LUFS | Spotify's own loudness normalization docs |
| YouTube | -1 dBTP recommended | Platform guidance |
| Tidal | -1 dBTP | Platform guidance |
How to actually hit -1 dBTP
You need a true peak limiter, sometimes called an ISP limiter or an oversampling limiter. It runs at 4x or higher oversampling so it can see and catch the inter-sample peaks before they reach the encoder. A standard sample-peak brickwall limiter won't do it: it only watches the sample values, which is the exact blind spot we've been talking about.
Most modern mastering limiters have a true peak mode. FabFilter Pro-L 2, Waves L2, and iZotope Ozone's Maximizer in its IRC IV mode all include true-peak-compliant limiting. Turn the mode on and set the ceiling to -1.0 dBTP.
Setting -1.0 dBTP costs you almost nothing in loudness and eliminates a category of distortion you can't repair after encoding.
Versus a -0.1 dBFS sample-peak ceiling, dropping to -1.0 dBTP usually costs less than 0.1 LU of integrated loudness. A difference no listener will notice, especially after normalization turns everything toward the same target anyway. In return you remove the clipping risk across every DAC and every codec your track will ever pass through.
Frequently asked questions
Does loudness normalization fix inter-sample peaks for me?+
No. Normalization adjusts playback gain to hit a loudness target and on most platforms it only turns audio down. It doesn't re-limit your peaks or repair clipping that's already baked into the file or introduced by the codec.
Is -1 dBTP enough, or should I go lower like -2?+
-1 dBTP covers most material. Spotify suggests going to -2 dBTP specifically for masters louder than -14 LUFS, because a hotter, more aggressively limited master gives the encoder less room and tends to generate bigger inter-sample overshoots. If your master is dynamic and sitting near or below -14 LUFS, -1 dBTP is fine. If you're pushing it loud, -2 is the safer ceiling.
My limiter only has a sample-peak ceiling. Can I just set it to -1?+
It helps, but it doesn't fully protect you. The limiter still can't see the inter-sample overshoots between samples. The peak it's controlling falls short of true peak measurement. Use a limiter with a dedicated true peak or oversampling mode and set that to -1.0 dBTP. That's the setting that catches inter-sample peaks.
Will inter-sample clipping show up on every listener's device?+
It depends on the playback chain. A DAC with its own headroom or a high-quality converter may absorb a small overshoot without audible clipping, while a cheaper one clips hard. The encoder stage is more consistent: if the codec pushes a peak over 0 dBFS during reconstruction, that distortion is in the encoded file for everyone. You can't predict the DAC, so you give the headroom up front.
How do I check my true peak before I upload?+
Look for a meter that reports dBTP. Most mastering limiters display true peak output alongside the sample ceiling, and standalone meters like iZotope Insight will give you an integrated true peak max for the whole track. Apple's free afclip tool also flags clipping in a finished file. The reading you want is the true peak max, confirmed at or below -1 dBTP.
Get better release strategy in your inbox
Release planning checklists, royalty explainers, and artist strategy notes from Velveteen. No daily noise.
Was this useful? Send a signal or flag a correction.
Keep reading
Pillar guide
Mastering for Streaming
LUFS targets, loudness normalization, true peak limits, and file specs for every major DSP, written by a working producer.
Related guide
DSP Loudness Chart
A side-by-side chart of loudness normalization levels across every major streaming platform so you master to the right target.
Related guide
File Specs for Distribution
The exact WAV sample rate, bit depth, and format specs every distributor expects for your master, including where Canadian and US requirements diverge.
Free tool · no signup
Check your metadata before your distributor does
Run your titles, credits, copyright lines, and ISRC and UPC codes through the free checker and catch the rejection-bait errors before you upload. It all runs in your browser.