True peak (dBTP) and inter-sample peaks, explained

Why a master that peaks at −0.1 dBFS can still clip on Spotify: what inter-sample (true) peaks are, how dBTP measures them with oversampling, why lossy codecs make them worse, and how much headroom to leave for each platform.

July 4, 2026 8 min read mixlabtrue peakdbtpinter-sample peakloudnessmasteringclippingbs.1770

Your master peaks at −0.1 dBFS. Your DAW’s peak meter never once touched red. You upload it, and on Spotify it sounds subtly crunchy on the loud parts. Nothing in your session predicted it.

The culprit is a peak your sample-peak meter can’t see: the inter-sample peak. Measuring it, as true peak, in dBTP, is the one loudness number that, if you get it wrong, produces audible distortion rather than just a level change. Here’s what it is and how to stay under it.

→ Read a file’s true peak in MixLab

A sample peak measures the dots, not the curve

Digital audio is a series of samples, snapshots of the waveform 44,100 (or 48,000) times a second. A normal peak meter reports the highest single sample value. Simple, and slightly wrong.

Playback doesn’t step from dot to dot. Your DAC (and every codec before it) reconstructs a smooth analog curve that passes through those samples, and between two samples, that curve can rise higher than either sample. Picture two adjacent samples both sitting at −0.3 dBFS on a fast transient: the reconstructed peak that threads between them can land above 0 dBFS. Your meter, only looking at the dots, says −0.3 and calls it safe.

That hidden overshoot is the inter-sample peak. On percussive, transient-rich material (snares, hats, synth stabs, distorted guitar) it commonly sits 1–2 dB above the highest sample, and in pathological cases higher still.

Why “−0.1 dBFS, never clipped” still clips

Two things turn a harmless inter-sample peak into audible distortion:

The D/A converter. When the analog curve is reconstructed on playback, an inter-sample peak above 0 dBFS has nowhere to go, the converter clips it.
Lossy codecs, the big one for streaming. AAC, MP3, and Ogg Vorbis don’t store your samples; they re-encode the signal. That process shifts peaks and typically adds another 1+ dB of inter-sample overshoot on decode. Every streaming platform transcodes your upload to a lossy format. So a master sitting at −0.1 dBFS can decode on the listener’s device at well over 0 dBFS and clip, even though your original file, played as lossless PCM, never would.

This is why “it looks fine in my DAW” and “it distorts on Spotify” are both true at once.

dBTP: measuring the curve, not the dots

True peak measures the reconstructed curve’s real maximum. The technique, defined in ITU-R BS.1770, is oversampling: upsample the signal (at least 4×) through an interpolation filter so you have samples between the original samples, then read the peak of that denser series. Now the meter sees the overshoot the DAC and codec will see.

The result is expressed in dBTP, decibels relative to full scale, true-peak. It’s the same 0-dBFS reference as dBFS; the difference is dBTP accounts for what happens between samples, so it’s the honest ceiling. A reading of −1.0 dBTP means the true reconstructed peak is 1 dB below full scale, with real headroom to survive conversion and transcoding.

dBFS (sample peak): highest sample. Optimistic.
dBTP (true peak): highest reconstructed value via oversampling. Honest.

How much headroom to leave

The standards and platforms converge on a small set of ceilings:

−1 dBTP, the EBU R128 recommendation, and what Spotify, Apple Music, YouTube, TIDAL and Deezer ask for.
−2 dBTP, the safer, stricter ceiling. Required by Amazon Music and broadcast (ATSC A/85), and what Spotify recommends if your master is louder than −14 LUFS (so their downward normalization doesn’t push peaks back up into clipping).

Practical rule: master to −1 dBTP for streaming, −2 dBTP if Amazon or broadcast is in scope. −2 dBTP satisfies everyone. The cost of the extra dB of headroom is essentially nothing once platforms normalize your loudness anyway, see loudness targets per platform.

A brickwall limiter at −0.1 won’t save you

A normal ceiling/brickwall limiter set to −0.1 dBFS operates on sample values, so it happily lets inter-sample peaks through. To actually control true peak you need a true-peak (ISP) limiter: one that oversamples internally, detects the reconstructed overshoots, and limits those. Most modern mastering limiters have a “true peak” mode, turn it on and set the ceiling to −1 (or −2) dBTP.

But limiting is a fix, not a diagnosis. First you need to see the true peak.

Measuring true peak without a plug-in

MixLab computes true peak client-side with 4× polyphase oversampling (a Hann-windowed sinc kernel), the BS.1770 method, right in the browser, drop a file in and read its dBTP alongside integrated LUFS and LRA. Nothing uploads; the DSP runs on the Float32 audio your browser already decoded.

For pipelines and QA gates, the same measurement is available as an API and MCP server: POST a file (or give your AI agent the analysis tool) and get true peak back as JSON, so a publish step can reject anything above −1 dBTP automatically, before it ever reaches a listener.

For the full DSP walkthrough, see Building MixLab Analyzer: BS.1770-4 LUFS in the browser.

FAQ

What’s the difference between dBFS and dBTP? Both use 0 dBFS (full scale) as the reference. dBFS reads the highest sample; dBTP reconstructs the curve between samples via oversampling and reads the real peak. dBTP is always equal to or higher than dBFS, and it’s the one that predicts clipping.

Is −1 dBTP enough? For streaming, yes. If you also deliver to Amazon Music or broadcast, use −2 dBTP, it covers everything.

Does loudness normalization fix true-peak overshoots? No. Normalization changes level; it doesn’t add headroom. In fact, a platform that turns a quiet master up can push its true peaks higher. True peak is your responsibility at master time.

Do I need a true-peak limiter, or can I just leave more headroom? Leaving headroom (mastering to −1.5 or −2 dBFS on a normal meter) reduces the risk but doesn’t guarantee it, inter-sample peaks are content-dependent. Measuring true peak tells you exactly where you stand; a true-peak limiter guarantees the ceiling.

Why do my peaks get worse after uploading? Lossy encoding (AAC/MP3/Ogg) reshapes the waveform and adds inter-sample overshoot on decode, often more than 1 dB. That’s why a true-peak ceiling below 0 dBFS, not a sample-peak ceiling at 0, is what keeps you clean after the platform transcodes.