PolishMyTrack
Delivery safety · Technically verified 31 August 2026

True peak vs sample peak: why a file below 0 dBFS can still clip

A digital file stores points. Your converter reconstructs a continuous waveform between them. That reconstructed curve can rise above every stored sample.

Sample peak asks: “what is the tallest number in the file?” True peak estimates a different thing: “how high can the continuous waveform become when those samples are reconstructed?” That difference is where intersample peaks live.

Stored samples below zero and a reconstructed waveform above zeroSix sample points remain below the zero dBFS line, while a smooth curve passing through them rises above it between two points.0 dBFStrue peak above the samplesblue dots = stored samples · green curve = reconstructed signal
The curve is illustrative, but the mechanism is real: ITU-R BS.1770 defines true peak in the continuous-time domain and estimates it by oversampling and filtering.

Why meters disagree

A sample-peak meter can be perfectly accurate and still miss the reconstructed maximum because it only inspects stored values. ITU-R BS.1770-5 describes true peak as the maximum positive or negative value of the continuous-time waveform and provides an estimation path using four-times oversampling at 48 kHz.

Then there is a second boundary: encoding. AAC, MP3 and Opus reshape the signal. A PCM master that is safe before encoding can decode with a higher true peak afterwards. This is why a ceiling is not merely a neat-looking number on the final limiter.

The failed assumption that changed our export path

In our five-file codec gate, an audible EQ change invalidated the assumption that a −2 dBTP PCM ceiling was automatically enough for every lossy derivative. At a −1 dBTP comparison ceiling, AAC reconstructed two files to +0.27 and +0.70 dBTP.

A ceiling sweep on the same EDM master was not even monotonic: −2 dBTP PCM decoded to −0.69 dBTP, −3 decoded to +0.28, and −4 decoded to −2.02. Codec behavior is content-dependent; moving a ceiling by one decibel does not guarantee the decoded peak moves by exactly one.

The shipped policy therefore keeps WAV/FLAC and foreground PCM masters at −2 dBTP, while AAC, Opus and MP3 receive one constant trim to −4 dBTP immediately before encoding. Across the five raw sources, decoded AAC landed between −3.88 and −2.02 dBTP and Opus between −3.65 and −3.30 dBTP, with zero detected clipped runs.

This is our measured safety policy, not a universal law. Spotify currently recommends below −1 dBTP around −14 LUFS and below −2 dBTP for louder masters. Apple provides AAC round-trip tools specifically so engineers can audition encoded output. Different material and encoders can justify different margins.

What to look for in a mastering report

PolishMyTrack exposes true peak because the delivery question is not “did the limiter stop at its knob setting?” It is “did the file remain safe after the transformations a listener will actually encounter?”

Method: ITU-R BS.1770-5 true-peak measurement, local AAC and Opus encode/decode round trips, five unfinished sources. Inputs remained untouched; derivatives were written separately and temporary codec files removed.

Check the reconstructed peak, not only the samples

The free PolishMyTrack scan reports true peak before any mastering move. The export path then uses format-aware headroom.

Scan true peak locally