True Peak, dBTP and the Inter-Sample Peak Problem

Published: 2026-06-06 · Reading time: 17 min read · Author: Nikolay Sapunov, CEO at Fora Soft

Why this matters

If you ship audio for a streaming service, a conferencing product, or any video platform, this is the article that explains why "it sounded fine in the studio" and "it clips on the user's phone" are both true at the same time. A product manager who approves a master at 0 dBFS, an operations lead who sets an encoder ceiling, and an engineer who picks a limiter all touch the same hidden variable, and getting it wrong produces distortion that only appears on the cheapest, most common playback hardware your users actually own. This article defines the true peak precisely, shows the arithmetic with real numbers, and gives you the delivery ceilings that the broadcast and streaming standards actually require in 2026.

The lie your peak meter tells

Open any audio editor and you will see a peak meter. It lights up to show the loudest moment in the file, and digital audio has a hard wall called full scale, written 0 dBFS, that the signal must never cross. Cross it and the samples saturate, producing the harsh crackle everyone recognizes as digital clipping. So the rule looks simple: keep the meter below 0 dBFS and you are safe.

The rule is wrong, and the reason is the most important idea in this article. The numbers stored in an audio file are not the sound. They are measurements of the sound, taken at fixed instants — 48,000 times a second for typical video audio. The actual sound is a smooth, continuous wave, and the file only records where that wave sat at each tick of the sampling clock. (If the idea of sampling a wave into numbers is new, start with what digital audio actually is and the companion piece on why 48 kHz won video.)

The meter on your screen, called a sample-peak meter, reports the largest of those stored numbers. But the playback device does not play the numbers. It rebuilds the smooth wave that ran through them, using a reconstruction filter built into every digital-to-analog converter. And here is the trap: the rebuilt wave can rise higher between two samples than either sample value. The peak you care about — the one that actually leaves the speaker — lives in the gaps the meter never measured.

The international standard puts it plainly. ITU-R BS.1770-5 notes that "the true-peak value may occur between samples" and that existing sample-peak meters "do not reflect the true-peak level contained in a digital signal." The true peak is defined as "the maximum (positive or negative) value of the signal waveform in the continuous time domain," and the standard is explicit that "this value may be higher than the largest sample value in the time-sampled domain."

Figure 1. The samples (dots) all sit below 0 dBFS, so a sample-peak meter reports "safe." The reconstructed wave that the listener's DAC rebuilds rises above full scale between two samples — the inter-sample peak the meter never saw.

Inter-sample peaks, in one picture

The peaks that hide between samples have a name: inter-sample peaks. They are not a bug or a rounding error. They are an unavoidable consequence of how sampling works, and a little arithmetic shows exactly how big they can get.

Picture a pure tone whose frequency sits high in the audible range, close to a quarter of the sampling rate. The sampling clock catches this wave at two points that happen to straddle its crest, one just before the peak and one just after, with neither landing on the peak itself. Both stored samples are below full scale. The true crest, sitting in the gap, is above it.

How far above? The standard's own worst-case analysis gives the formula for how much a sample-peak meter under-reads a tone:

under-read (dB) = 20 · log10( cos( π · f_norm / n ) )

Here f_norm is the tone's frequency as a fraction of the sampling rate, and n is the oversampling ratio of the meter. For a sample-peak meter that does no oversampling at all, the relevant comparison is against a meter that does. The standard tabulates the residual error: a 4× oversampling meter still under-reads by up to 0.688 dB for a tone near half the sampling rate, and a non-oversampling meter is worse still. In practice, real-world program material with hot high frequencies routinely hides 0.5 to 1.5 dB of true peak above its sample peak, and pathological test tones can hide far more. The standard notes that for a tone at exactly half the sampling frequency the under-read "could be almost infinite," though real signals rarely concentrate energy there.

The unit for this real, between-samples maximum is the dBTP — decibels relative to full scale, true-peak. A reading of 0 dBTP means the reconstructed wave just touches full scale. A reading of +0.7 dBTP means it overshoots by 0.7 dB, and the listener's converter has no room above full scale to render it, so it clips.

How a true-peak meter actually measures it

You cannot measure a peak that sits between your samples without first filling in the gap. That is exactly what a true-peak meter does, and the method is specified precisely in Annex 2 of ITU-R BS.1770-5 so that every compliant meter agrees.

The meter rebuilds a higher-resolution version of the signal — the same operation the playback DAC performs — and then reads the sample peak of that. The standard lists four processing stages:

1. Attenuate by 12.04 dB. This is a 2-bit shift that gives headroom for the math that follows, so an overshoot above full scale doesn't itself overflow the meter's arithmetic. It is undone at the end. (In floating-point implementations this step is unnecessary.)
2. Oversample 4×. The signal's sample rate is raised from 48 kHz to 192 kHz by inserting interpolated points between the originals. The standard gives a specific 48-tap, 4-phase FIR interpolation filter for the job. This higher-rate signal "more accurately indicates the actual waveform that is represented by the audio samples."
3. Low-pass filter to keep the interpolation honest, excluding frequencies that shouldn't be there.
4. Take the absolute value, then convert to dBTP by computing 20·log10 of the result and adding back the 12.04 dB removed in step one.

The 4× ratio (48 kHz → 192 kHz) is the standard's minimum; it explicitly says "higher sampling rates and over-sampling ratios are preferred." A signal already at 96 kHz only needs 2× oversampling to reach 192 kHz. The reason 192 kHz is the target is that it is high enough to make the residual under-read negligible for normal program material — the worst-case table shows 4× brings the error down to well under a decibel, and that is good enough for a meter whose output drives a number, not a loudspeaker.

The practical upshot for anyone reading a meter: if your meter says "TP" or "dBTP" and is BS.1770-compliant, it is doing this oversampling internally. If it only says "Peak" or "dBFS," it is a sample-peak meter and it is lying to you by up to a decibel or more.

Figure 2. The four-stage true-peak meter from ITU-R BS.1770-5, Annex 2. Oversampling rebuilds the inter-sample detail; the meter then reads the peak of the reconstructed signal and reports it in dBTP.

Why lossy codecs make it worse

Everything so far assumes the file reaches the listener unchanged. It almost never does. Streaming services and conferencing systems re-encode your audio with a lossy codec — AAC, Opus, or similar — and that encoding step adds true-peak overshoot of its own.

The reason is built into how these codecs work. A lossy encoder does not store your samples; it stores a frequency-domain approximation of the sound and reconstructs new samples on decode. (The mechanics are covered in how audio compression works.) Those reconstructed samples are close to the originals but not identical, and the small differences can push the decoded waveform's true peak above where the original sat. The AES streaming recommendation, technical document AES TD1008, states the consequence directly: "peak overshoot increases as the bit rate decreases." A 320 kbps AAC file overshoots less than a 64 kbps one. Lower bitrate, more overshoot.

This is why the same document recommends measuring and limiting true peak at the codec input: "For all content, it is recommended that the Maximum True Peak level not exceed −1 dBTP at the codec input of lossy-encoded streams." The −1 dBTP is not arbitrary. It is one decibel of headroom reserved so the encoder's own overshoot, added on top, still lands below full scale at the listener's converter. For low-bitrate streams the same document warns the threshold "may need to be reduced below the recommended −1."

The overshoots stack. AES TD1008 notes that codec overshoots and any downstream sample-rate conversion overshoots "can be additive," and that on the decode side, failure to leave headroom "can produce as much as 3 dB of gain reduction in the decode-side peak limiter" on some operating systems — meaning the listener hears your loud moment ducked by 3 dB, not just clipped. A master that ignores true peak doesn't only distort; it can get quietly turned down in ways you never authorized.

A worked example: the master that clips on AirPods

Put numbers to it, because the numbers are the whole argument.

You master a track and your editor's sample-peak meter reads −0.1 dBFS. Looks safe — you left a tenth of a decibel of headroom. But the master has bright, hot high-frequency content (cymbals, sibilance, a synth lead), and a true-peak meter on the same file reads +0.6 dBTP. The inter-sample peaks sit 0.7 dB above your sample peak. On your studio monitors, fed by a high-quality interface with generous headroom, nothing audibly breaks, so you ship it.

Now follow the file to a listener:

Master sample peak:        −0.1 dBFS   (what your meter showed)
Master true peak:          +0.6 dBTP   (already over full scale)
+ AAC 128 kbps overshoot:  +0.4 dB     (encoder adds its own)
= True peak at decoder:    +1.0 dBTP   (1 dB over the wall)

The phone's DAC, the laptop's converter, and the AirPods' tiny amplifier have no headroom above 0 dBFS. They clip the +1.0 dBTP signal on every bright transient. Your listener hears crackle on exactly the cheap, ubiquitous hardware that most of your audience uses, while your studio chain — the one piece of gear that did have headroom — hid the problem from you the entire time.

Run the fix and the arithmetic resolves. Set a true-peak limiter to −1 dBTP before encoding:

Master true peak after limiter:  −1.0 dBTP
+ AAC 128 kbps overshoot:        +0.4 dB
= True peak at decoder:          −0.6 dBTP   (safely under the wall)

One decibel of reserved headroom absorbs the encoder's overshoot, and the signal lands below full scale everywhere. Nothing about the audible loudness changed in a way anyone would notice — the platform's loudness normalization sets playback level anyway — but the distortion is gone.

The delivery ceilings you actually need in 2026

True peak is one of two numbers every delivery spec carries; the other is the integrated loudness target in LUFS, covered in the per-platform targets article. Here are the true-peak ceilings the standards and major platforms require. Values are maximum true peak; lower is safer.

The pattern: −1 dBTP is the default ceiling almost everywhere, and the destinations that demand −2 dBTP do so precisely because they expect heavy lossy encoding downstream and want more headroom for the overshoot. When in doubt, −1 dBTP is safe for high-bitrate delivery and −2 dBTP is safe for everything; you lose nothing audible by being conservative, because normalization controls the loudness the listener hears, not the peak ceiling. The full set of standards behind these numbers — EBU R128, ITU-R BS.1770, ATSC A/85 — is unpacked in the loudness normalization article.

Common mistake: limiting sample peak instead of true peak

The single most common failure is using an ordinary peak limiter — one that watches sample peaks — and trusting it to protect your true peak. It cannot. A sample-peak limiter happily passes a file whose samples all sit at −1.0 dBFS but whose reconstructed wave hits +0.2 dBTP, because the limiter never looks between the samples. You set the ceiling to −1 and still ship inter-sample overs.

The fix is a true-peak limiter: one that oversamples internally (the same BS.1770 operation) and limits the reconstructed peak. AES TD1008 is specific that when limiting is required you should "use a true-peak limiter, which anticipates and controls the peak level after the player device's digital-to-analog converter and reconstruction filter." Every serious limiter plug-in built since roughly 2012 offers a true-peak mode; it is sometimes off by default. Turn it on, and set the ceiling in dBTP, not dBFS.

A second, subtler trap: true-peak limiting before a sample-rate conversion does not protect against overshoot the conversion itself introduces. AES TD1008 notes that downward sample-rate conversion "can remove program energy and thus induce overshoot," and that "placing a true-peak limiter after the SRC is the only way to reliably prevent peak overshoot." If your pipeline downsamples — say, 96 kHz masters to 48 kHz delivery — measure and limit true peak after that step, not before.

Where Fora Soft fits in

In the OTT and Internet TV pipelines we build, true-peak limiting lives in the transcode-and-package stage, not in the upload. A single mezzanine master is true-peak-measured once, then each lossy rendition gets a limiter ceiling chosen for its bitrate — tighter for the low-bitrate mobile profiles, looser for the high-bitrate ones — so no profile clips on a phone. In the video conferencing and telemedicine products we ship, the same discipline applies to the real-time Opus path, where clipped peaks on a clinician's or student's cheap earbuds are not cosmetic but a failure of the product's core job. Wiring true-peak control into packaging, per profile, is the difference between a catalogue that plays cleanly on the hardware people own and one that generates distortion complaints from exactly the devices you cannot test on.

What to read next

• LUFS Targets per Platform in 2026 — the loudness number that travels alongside your dBTP ceiling.
• Loudness Normalization: EBU R128, ITU-R BS.1770, ATSC A/85 — the standards that define the −1 dBTP ceiling.
• Loudness in Practice: Dialnorm, Replay Gain, Normalize — why a boost can push a quiet master past its true-peak ceiling.

Call to action

• Talk to a audio engineer — book a 30-minute scoping call to talk through your true peak dbtp plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the True Peak & dBTP Cheat Sheet — The dBTP definition, the four ITU-R BS.1770-5 meter stages, the per-platform true-peak ceilings, the worked overshoot example, and the FFmpeg test command on one page.

References

1. ITU-R BS.1770-5, "Algorithms to measure audio programme loudness and true-peak audio level" (November 2023), Annex 2. The normative true-peak definition ("maximum value of the signal waveform in the continuous time domain"), the four-stage meter (12.04 dB attenuation, 4× oversampling 48→192 kHz, low-pass filter, absolute value), the 48-tap FIR coefficients, and the worst-case under-read table. Tier 1. https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-5-202311-I!!PDF-E.pdf
2. EBU R128 v5.0 (November 2023), recommendation (m). "The True Peak Level of a programme shall not exceed −1 dBTP during production… measurement tolerance is ±0.3 dB" and the note that "Permitted Maximum True Peak Levels may be lower for different distribution systems and data reduction rates." Tier 1. https://tech.ebu.ch/docs/r/r128.pdf
3. AES TD1008 (AESTD1008.1.21-9, September 2021), "Recommendations for Loudness of Internet Audio Streaming and On-Demand Distribution." "Maximum True Peak level not exceed −1 dBTP at the codec input of lossy-encoded streams"; "peak overshoot increases as the bit rate decreases"; codec and SRC overshoots "can be additive"; up to "3 dB of gain reduction in the decode-side peak limiter"; use a true-peak limiter; limit after downward SRC. Tier 1. https://aes2.org/wp-content/uploads/2024/01/20210924_TD1008_v3.13.pdf
4. EBU Tech 3341, "Loudness Metering: 'EBU Mode' metering to supplement loudness normalisation in accordance with EBU R 128." Defines the EBU-mode meter (including the BS.1770-based true-peak indication) that R128 compliance requires. Tier 1. https://tech.ebu.ch/publications/tech3341
5. EBU Tech 3344, "Guidelines for Distribution and Reproduction of Programmes in accordance with EBU R 128." The distribution-side guidance R128 points to for lower true-peak ceilings on data-reduced (lossy) paths. Tier 1. https://tech.ebu.ch/publications/tech3344
6. ATSC A/85 (current revision), "Techniques for Establishing and Maintaining Audio Loudness for Digital Television." US CALM Act technique document; the true-peak and dialogue-loudness framing for broadcast against which streaming ceilings are often compared. Tier 1. https://www.atsc.org/atsc-documents/a85-techniques-for-establishing-and-maintaining-audio-loudness-for-digital-television/
7. Apple, "Apple Digital Masters" technical overview. First-party guidance recommending true-peak-limited masters (−1 dBTP) so AAC encoding does not introduce inter-sample clipping. Tier 4. https://www.apple.com/apple-music/apple-digital-masters/
8. Spotify for Artists, "Loudness normalization on Spotify." −14 LUFS Normal target with a −1 dBTP recommendation, and a −2 dBTP recommendation for masters louder than −14 LUFS to leave Loud-mode limiter headroom. Tier 4. https://support.spotify.com/us/artists/article/loudness-normalization/
9. Netflix Partner Help Center, "Sound Mix Specifications & Best Practices" / "Audio Mix Loudness." The −27 LKFS dialogue-gated target with a −2 dBTP true-peak ceiling for delivered mixes. Tier 4. https://partnerhelp.netflixstudios.com/hc/en-us/articles/360001794307
10. FFmpeg, loudnorm and ebur128 filter documentation, and the loudnorm reference write-up. The JSON input_tp (true peak) output, 192 kHz upsampling for true-peak detection, and the two-pass measure-then-limit workflow. Tier 4. http://k.ylo.ph/2016/04/04/loudnorm.html
11. iZotope, "How to master for streaming platforms: normalization, LUFS, and loudness." Practitioner cross-check on −1 dBTP delivery and the inter-sample clipping risk on consumer DACs; corroborates the standards-derived ceilings. Tier 4. https://www.izotope.com/en/learn/mastering-for-streaming-platforms