Versely
    Guides

    True-Peak Limiters for AAC Delivery

    Catch inter-sample peaks with a true-peak limiter at −1.0 dBTP before AAC, because a brickwall at 0 dBFS still fails QC after the encode.

    Versely Team••9 min read

    A generated music bed can read clean on a sample-peak meter, sail through the bounce, and still clip after AAC. The spikes were never on a sample. They sat between samples, the encoder's reconstruction filter put them into the analogue-equivalent waveform, and the file that sounded fine in the DAW now ticks on a phone. Quality control that only looks at 0 dBFS sample peak will pass that file. The listener will not.

    The control that actually catches this is a true-peak limiter, set before the encode, at −1.0 dBTP for ordinary AAC delivery. A brickwall limiter whose ceiling is 0 dBFS on the sample meter is doing a different job, and it is the job that fails.

    Sample meters do not see between the samples

    Digital audio is a sequence of points. The waveform that comes out of a DAC, or out of a codec's reconstruction filter, is a continuous curve through those points. Nothing requires the highest point on that curve to land on a sample. When it does not, you have an inter-sample peak (ISP). The sample-peak meter, the red clip light on a channel that only looks at sample values, and a brickwall limiter that only compares against 0 dBFS sample peak all miss it.

    ITU-R BS.1770 Annex 2 is the measurement that does not miss it. True-peak level is defined as the maximum of the waveform in the continuous-time domain. The Annex 2 meter estimates that by oversampling: at 48 kHz the standard path interpolates 4× (48 kHz → 192 kHz) through a specified FIR, then reads the peak of the rebuilt signal and reports it in dBTP. EBU R 128 uses that meter and sets production true peak at −1 dBTP, with a ±0.3 dB measurement tolerance for 20 kHz-bandlimited signals.

    That −1 dBTP is not a taste setting. It is headroom for the next process that will reconstruct the waveform: a DAC, a broadcast limiter, or a lossy codec. R 128 is explicit that permitted maximum true-peak levels may be lower for some distribution systems and data-reduction rates, and points at EBU Tech 3344 for those ceilings. AAC is data reduction. The sample-peak brickwall you already have does not implement Annex 2, so it does not know about this.

    Bounce a 48 kHz / 24-bit WAV with no limiter and read both numbers. If true peak is higher than sample peak, the extra is inter-sample. Generated drums, trailer hits, and already-mastered text-to-music tracks are where the gap shows up first. Do not invent a conversion ("add 1 dB and call it true peak"). Measure. The Annex 2 meter is the definition.

    Why AAC still clips a file that looked clean

    AAC is an MDCT codec. On decode it reconstructs a continuous-looking waveform from spectral coefficients, not from your original samples. Two things happen in that reconstruction that a 0 dBFS sample brickwall cannot see:

    • The decoder interpolates. Same class of problem as a DAC: the curve between samples can overshoot 0 dBFS even when no sample did.
    • The quantiser is lossy. At typical delivery bitrates the encoder is allowed to distort the spectrum to hit the budget. That distortion is not required to preserve your sample-peak ceiling. Apple's podcast audio requirements say the quiet part out loud: precondition loudness and true peak before encoding, because compression algorithms typically do not modify loudness and may clip if the true-peak value is not respected.

    YouTube's upload page wants AAC-LC (or Opus, or Eclipsa), 48 kHz. It does not publish a dBTP cap. The encode still happens, on their side and often on yours before upload. A WAV that true-peaks at −0.1 dBTP will not get safer because you wrapped it in an MP4.

    Generated music is a special case because it often arrives already limited as a record. A music generate that was prompted as a finished track will sit loud, with transients already against a sample ceiling. Putting that file under a voice, then encoding, is two reconstruction stages on a signal that had no true-peak headroom to start with. The brittle high end on generated music is a spectral problem; this is the peak problem sitting next to it. Both want you to work from a WAV, not from the MP3 or AAC the model gave you.

    Netflix, for a different delivery, is stricter on paper: the mix spec says peaks must not exceed −2 dB true peak, and the best-practice note is to set a true-peak limiter at −2.3 dBFS on deliverables so meter disagreement does not throw a false fail. That is a destination ceiling, not a reason to ignore −1.0 for AAC social. Use the ceiling the next codec or QC sheet named.

    Set the limiter at −1.0 dBTP, then encode

    The chain that survives AAC, stated as a sequence rather than a plugin list:

    1. Finish the mix at 48 kHz / 24-bit WAV. No AAC in the session. If the generate was 44.1 or already lossy, resample and decode to WAV first.
    2. Measure integrated loudness and true peak with a BS.1770 meter (EBU Mode for R 128 destinations; whatever the destination sheet named). Sample peak is a curiosity, not a pass.
    3. Insert a true-peak limiter, not a sample-peak brickwall. Turn on the limiter's true-peak / ISP mode so it is looking at an oversampled reconstruction, not at sample values. ITU-style 4× oversampling is the baseline that matches Annex 2.
    4. Ceiling −1.0 dBTP for AAC delivery and for R 128 production. Ceiling −2.3 dBFS if the bounce is a Netflix near-field deliverable. Do not use 0 dBFS "because the meter is not clipping."
    5. Lookahead long enough to catch the overshoot without chewing transients. A true-peak limiter without lookahead can only react after the ISP has started. If the limiter is pumping, you are asking it to do loudness work; turn the mix down and leave the limiter as a ceiling.
    6. Bounce the limited WAV. Measure again. True peak should read at or under the ceiling, within the meter's tolerance (−1 dBTP ±0.3 dB is R 128's production tolerance). If it does not, the limiter is in sample-peak mode, or the ceiling is not what you think.
    7. Encode AAC once, from that WAV. Do not encode, decode, limit, encode. Each extra MDCT is another chance to grow an ISP.

    ffmpeg will encode. It will not save you if the WAV is already hot:

    ffmpeg -i mix_limited.wav -c:a aac -b:a 192k -ar 48000 -ac 2 mix.m4a

    Run a true-peak read on mix.m4a after the encode as well. If the AAC file true-peaks above the WAV, the encode added overshoot; drop the limiter ceiling another few tenths (try −1.3 dBTP) and encode again from the WAV. Do not "fix" the AAC with a second limiter.

    On the Versely side, generating the track and attaching it does not include a true-peak limiter. attach_audio_to_video is a static mix. Do the Annex 2 pass on the WAV before you replace the video's audio with the limited file, or do it on the finished mix bounce before the AAC wrap. The editor's 480p preview is free, with a short per-user cooldown, and it will not show you an ISP; a BS.1770 true-peak meter will.

    Brickwall at 0 dBFS is not QC

    A 0 dBFS sample brickwall is a legal-peak limiter for a world that no longer delivers that way. It will:

    • Let inter-sample peaks through, because it never computed them.
    • Report "not clipping" on a meter that agrees with it, while a BS.1770 meter reports +0.5 dBTP or more.
    • Hand AAC (or the platform's transcode) a file with no reconstruction headroom.

    QC that asks for true peak is not being precious. R 128 production, Apple Podcasts, and Netflix's mix spec all name a true-peak ceiling. A screenshot of a sample-peak meter at −0.1 dBFS does not answer those sheets. Put the true-peak number on the delivery note, with the meter and the BS.1770 version you used. If you cannot name those, you have not measured true peak.

    If a file still clips after a −1.0 dBTP true-peak pass, the remaining causes are a limiter that was in the wrong mode, an encode that was not from the limited WAV, or a destination that wanted −2 dBTP and you sent −1. Measure the file that actually got uploaded, not the session.

    FAQ

    Is −1.0 dBTP the same as −1.0 dBFS?

    No. dBFS on a sample meter is the largest sample. dBTP is the largest point on the reconstructed waveform, per BS.1770 Annex 2. A file can be −1.0 dBFS sample peak and +0.4 dBTP. Those two numbers are why the brickwall failed.

    Why not limit to −3 dBTP "to be safe"?

    You can, and some distribution chains ask for a lower ceiling than −1 (R 128 points at Tech 3344 for those). What you should not do is steal 3 dB of level as a superstition and then turn the mix back up into the limiter. Set the ceiling the destination named (−1.0 for AAC / R 128 production, −2.3 for Netflix's recommended deliverable limiter), then stop.

    Do I need this on a quiet voiceover with no music?

    If the true-peak meter already reads under −1 dBTP, the limiter will not touch it. You still measure. Plosives and generated consonants can ISP on an otherwise conservative VO. Skipping the meter because "it's just speech" is how a single P hits the encode.

    Can I true-peak limit after AAC to save a pass?

    No. Limit the WAV, encode once. Limiting decoded AAC is limiting codec error plus signal, and a second encode after that is a new reconstruction. The Apple podcast note is the right order: precondition, then encode.