Guide
It measured clean at home. The encode put the peaks back
Converting audio to AAC adds true peak that your file did not contain, which is why a limiter set exactly at your target ceiling still delivers a file above it. The fix is to limit a decibel below where you actually want to land, and to slow the limiter down. Both numbers below come from measuring our own delivered files rather than from a rule of thumb.
- Delivered files that overshot the ceiling
- 5 of 12
- Encoder overshoot at one hard transient
- 2 dB
- Limiter attack that stopped causing it
- 15 ms
A lossy encode is a reconstruction, and a reconstruction can overshoot
AAC does not store your waveform. It stores a description that a decoder uses to build a waveform back, and the rebuilt one is not sample for sample identical.
Where it differs most is at the peaks. The reconstruction can rise above the highest point in your original file, which means a master that measured exactly at the ceiling is delivered above it.
We measured this on a batch of twelve finished ads. Five of the twelve came out above the -1 dBTP target, the worst at -0.27, even though the stage before the encode had held every one of them.
The overshoot ran up to about 0.7 dB on ordinary programme material and reached roughly 2 dB at one hard transient. Those are not enormous numbers, and on a laptop speaker you will not hear them.
On a phone speaker at full volume you hear all of them. A small driver being asked to reproduce a square edge is exactly what crackle is.
Where the peak actually ends up
Measured on twelve delivered files. The stage before the encode held; the file people downloaded did not.
- What the mix measured-3.2 dBTP
- Target ceiling-1 dBTP
- Worst delivered file-0.27 dBTP
- Limiting a decibel under-1.3 to -1.5 dBTP
So the ceiling goes under the target, not on it
Limiting at exactly -1 dBTP measured -0.31 on the delivered file. Limiting at -2 measured between -1.3 and -1.5, which is what we actually wanted.
That one decibel is codec headroom. It is the same practice streaming services use for lossy delivery, and it costs you nothing audible.
There is one switch on most limiters that quietly undoes all of it. Auto-level, auto-gain or output-normalize is on by default in several of them, and it takes the limited output and pushes it straight back up to full scale.
Turn it off and check. A limiter with auto-level on is a loudness maximizer wearing a limiter's label, and it will recreate the exact problem you added the limiter to solve.
This is the whole editor
Highlight a phrase and a clip lands on those exact words. No timeline, no keyframes, no layers.
A fast limiter causes the distortion it was added to prevent
This one surprised us. A five millisecond attack produced hard edges in the gain signal, and the encoder turned the spectral splatter from those edges into a transient about two decibels above target.
The limiter was doing its job perfectly. The gain reduction it applied was so abrupt that the encoder could not describe it, and what came back was a spike.
Fifteen milliseconds smooths the gain movement enough that the encoder tracks it, and the delivered peak stays a decibel under target. A hundred and fifty on release does the same on the way out.
If your limiter offers lookahead compensation, turn it on. A fifteen millisecond attack without it drags your audio fifteen milliseconds late against the picture, which on a talking head is visible.
Two limiter settings, same source file
The fast setting is the intuitive one and it is the one that fails, because the failure happens after the limiter in a stage it cannot see.
| 5 ms attack | 15 ms attack | |
|---|---|---|
| Gain movement | Hard edges | Smooth ramp |
| What the encoder does with it | Splatter, then a spike | Tracks it cleanly |
| Delivered peak | Up to 2 dB over | A decibel under |
| Timing | In sync | Needs lookahead compensation |
How to check a file you have already posted
Download the file back from the platform rather than checking your local master. The version people hear is the one that went through the encode, and that is the only one worth measuring.
Run it through any true peak meter. If it reads above -1 dBTP you have found your crackle, and no amount of re-uploading the same master will change it.
Then listen on the worst speaker you own at full volume. A phone held at arm's length in a quiet room is a harsher test than any pair of monitors and it is how most of the audience will hear it.
If none of this sounds like a thing you want to own, an automated chain is a fair trade. Ours limits under the target with a slow attack on every export, and there is no setting for it, which is the point and also the limit.
Questions people ask
- Why does it sound fine in my editor and bad after upload?
- Because your editor is playing the uncompressed timeline. The distortion appears in the encode, so it does not exist in the file you are monitoring. Always audition an exported file, not the timeline.
- Is this the same as my video being too loud?
- No. Loudness is an average across the whole file and peak is a single moment. A quiet file can clip on one consonant and a loud file can be perfectly clean.
- Do I need a true peak meter, or is a normal peak meter enough?
- You need a true peak meter. A sample peak meter reads the values stored in the file, and true peak is what a decoder reconstructs between them, which is where the overshoot lives.
- Does this apply to music as well as speech?
- More so. Dense music has far more transient content for the encoder to overshoot on, which is why mastering engineers have left codec headroom on lossy delivery for years.
Limit a decibel under where you want to land, slow the attack down, and check the file the platform gives back rather than the one on your disk. Our export chain does all three, because these are not decisions worth asking anyone to make twice.