The short answer
Digital audio does not store a continuous wave. It stores a row of evenly spaced measurements, called samples, and your level meter reports the tallest one it has seen. That tallest sample is the sample peak, measured in decibels below full scale, or dBFS, where 0 is the absolute digital maximum.
The catch is that nobody listens to samples. A converter, the chip in your headphones or interface, rebuilds a single smooth curve that passes through every sample and plays that. Between two samples the curve is free to swing higher than either one, and once in a while it swings past 0. The highest point of that rebuilt wave is the true peak, measured in dBTP (decibels true peak). A file that never showed above 0 on a sample meter can still push its true peak over the line, and that overshoot is where a clean-looking master starts to distort.
Why the wave rises between the samples
Picture the loudest instant of a signal landing not on a sample but in the tiny gap between two of them. Each of those two samples measures a value just below the true crest, so both come in under the ceiling and your meter is satisfied. The converter, rebuilding the smooth wave the samples describe, arcs up through the gap and reaches the crest they were both leaning toward. This is not a converter bug. It is exactly what faithful reconstruction is supposed to do; the samples are a sketch, and the played wave is the drawing they imply.
The overshoot is largest when the loud content is high in frequency, because a fast wave spends less time near each sample and more of its travel happens in the gaps. It also grows the closer your samples already sit to 0. A signal squashed hard against full scale, the kind a clipped or maximized master produces, has almost no room left, so its inter-sample peaks routinely poke over. A signal with a little headroom rarely does.
Sample peak versus true peak
Sample peak and true peak answer two different questions. Sample peak asks how tall is the tallest number I stored, and true peak asks how tall does the wave actually get when it is played. For quiet or gently mixed material the two numbers are nearly identical. For anything pushed near the ceiling they diverge, and the true peak is always the higher of the two, never lower.
The reason this matters downstream is that the true peak is what has to survive the rest of the journey. When your audio is turned back into an analog wave, or squeezed through a lossy codec on the way to a listener, the process works from that rebuilt curve, not from your samples. A file that reads a comfortable -0.1 dBFS on its samples can present a true peak above 0, and a codec, which reshapes the waveform, can push it higher again. The result is distortion that was never visible on the meter that signed the file off.
How true peak is measured
You cannot read a true peak off the samples directly, because the crest lives between them. So a true-peak meter does the reconstruction itself, in miniature: it oversamples, calculating a batch of extra points between every pair of real samples (four times the rate is the common minimum, and more is better), then reports the tallest value across that denser grid. It is estimating the played wave and measuring that estimate.
dBTP = max( |reconstruct(samples, oversampled 4x or more)| ) in dBFSReconstruct extra points between the samples, then take the maximum of that finer grid. Sample peak only ever sees the original dots; true peak looks in the gaps where the crest actually hides.
The two consequences that make true-peak metering awkward in a live path both come from that reconstruction step. It needs to buffer a short run of samples before and after each point to estimate the curve, which costs a little delay, and it costs real arithmetic per sample. In a finished master neither is a problem. In a signal you are hearing back in real time, both are, which is the crux of the next section.
Deliver with a dB of headroom
The fix is not a clever meter, it is a habit: do not deliver a file parked at 0. Leave a margin so that even after reconstruction and a codec the true peak stays legal. The widely used ceiling is -1 dBTP, which is why so many limiters default their ceiling near -1 rather than 0. That single dB is enough room for almost every inter-sample peak ordinary program material can produce.
For audio bound for a low-bitrate lossy format, drop the ceiling further, to around -2 dBTP. Aggressive compression reshapes the waveform more violently, so it can add true-peak overshoot that was not in your original at all, and the extra dB of headroom absorbs it. The headroom is not wasted loudness, either. Playback systems judge loudness separately from peak and normalize it on their own, so a peak ceiling a dB or two down costs you nothing a listener will hear.
Why a live limiter cannot catch it
A true-peak limiter catches these overshoots before they happen, but only by paying for the reconstruction up front. It has to look ahead, buffering the incoming audio by a few milliseconds so it can oversample the region around each peak, find the inter-sample crest, and pull the gain down before that crest arrives at the output. Lookahead plus oversampling is the price of seeing between the samples, and it is not refundable.
That delay is invisible in a mastering session. In a live monitoring path, where you are hearing your own voice as you speak, it is the opposite of invisible: every millisecond of lookahead stacks on top of your buffer delay and drifts your voice out of sync with your face. A true-peak limiter is the wrong tool for a path you listen to in real time, not because it does a bad job, but because doing its job well requires the one thing that path cannot spend.
True peak in patchd
patchd is a live monitoring mixer, so it makes the live-path choice openly. Its channel meters show sample peak in dBFS, a real-time readout of the loudest sample per channel, from silence at negative infinity up to 0. They are sample-peak meters, not true-peak meters and not loudness meters, and calling them anything else would be a lie about what they watch.
The free limiter node makes the same honest trade. It is a brickwall limiter with zero lookahead and zero added latency, default ceiling -1.0 dB, so it clamps sample peaks the instant they hit the line without delaying your audio at all. It does not do true-peak limiting, because that would mean adding the lookahead a monitoring path deliberately refuses. What saves you is the default ceiling itself: holding sample peaks a full dB under 0 leaves exactly the headroom that keeps ordinary inter-sample peaks from clearing the top. Reach true-peak compliance where it belongs, with a true-peak limiter at export or on the platform, and let the live path stay fast and in sync.
The takeaway
Sample peak is the tallest number you stored; true peak is how high the rebuilt wave actually climbs when it is played, and it is measured in dBTP by oversampling the reconstruction. The two agree until you push near the ceiling, and then the true peak pulls ahead and can slip over 0 while your sample meter still reads legal. Deliver with about a dB of headroom, two for low-bitrate lossy, and you sidestep the whole problem.
patchd is a pre-launch Windows audio mixer with an honest sample-peak meter on every channel and a free, zero-latency limiter that keeps your live signal a safe dB below the ceiling. Join the waitlist and we will tell you the moment it is ready to install.