What Is LUFS? Loudness Targets for AI Voice and Audio
Summary
What is LUFS? It is a weighted, gated loudness measurement in which one unit equals one dB. Podcasts usually target -16 LUFS stereo with peaks under -1 dBTP, Spotify uses -14, EBU R 128 broadcast uses -23, and ACX audiobooks use RMS limits instead. For AI voice, measure every render, match lines to a reference, then normalize once at the end.
What is LUFS? It is a loudness unit that measures how loud audio sounds to a listener over time, not how high its peaks reach. One LU equals one dB of gain, and values run negative because the scale is anchored to digital full scale (0 dBFS). For spoken word, you match a target, such as -16 LUFS for most podcasts, and keep true peaks under about -1 dBTP.
How does LUFS actually measure loudness?
LUFS stands for Loudness Units relative to Full Scale. The measurement is defined in ITU-R BS.1770 and adopted by EBU R 128, and LKFS is the same unit under an older name. A meter does three things before it prints a number.
First, it applies K-weighting. This is a filter that rolls off low frequencies and gives a gentle lift to the upper mids, roughly mimicking how ears weigh energy. A voice with heavy 80 Hz rumble reads quieter than its raw level suggests, because the filter discounts that rumble.
Second, it averages the energy over a window. Three windows matter in practice:
Momentary looks at 400 ms and jumps around quickly.
Short-term looks at 3 seconds and is the one to watch while editing a phrase.
Integrated covers the whole file from first sample to last, and it is the number platforms use for normalization.
Third, it gates. Anything below -70 LUFS is ignored outright, and then anything more than 10 LU below the running average is ignored too. Gating is why a long silence between lines does not drag your reading down. It is also why a file that is mostly room tone gives you a strange integrated number.
The session note: if a render is shorter than a second, the integrated reading rests on very few windows. Measure it inside the full scene or chapter instead.
Why are the values negative, and how is this different from dBFS and RMS?
The scale tops out at 0 dBFS, the loudest value a fixed-point digital file can store. Everything you hear is below that ceiling, so everything reads negative. A reading of -16 LUFS is simply 16 units under full scale.
The confusion starts because several meters share the same dB look. Here is how they differ in practice.
Peak (dBFS) is the highest single sample. It tells you about clipping and nothing about loudness.
True peak (dBTP) estimates the highest level the waveform reaches between samples after conversion. Lossy codecs can push it over 0 even when the sample peak sits under it, which is why platforms ask for -1 dBTP of headroom.
RMS averages signal power without K-weighting or gating. It is cruder, and some specifications, like the audiobook standard below, still use it.
LUFS is weighted, gated loudness. It correlates best with what a listener says is louder.
Two files can show the same peak and be 8 LU apart in loudness. A plosive-heavy take with a single spike and a compressed take with flat dynamics prove it. That gap is the whole reason the unit exists.

Which LUFS target should you hit for voice work?
There is no single number. The target depends on where the file ends up, and some destinations do not use LUFS at all. These are the figures to keep on a sticky note.
Music streaming, around -14 LUFS integrated. Spotify's loudness documentation states -14 dB LUFS as its normal playback level, with Loud at -11 and Quiet at -19 for Premium listeners. Its guidance is true peak at or below -1 dBTP, or -2 dBTP if your master is louder than -14.
Podcasts, commonly -16 LUFS stereo and -19 LUFS mono. The mono figure is 3 LU lower because a mono signal duplicated to both channels measures 3 LU louder than the same signal on one channel. Ceilings of -1 dBTP are the usual advice.
Broadcast under EBU R 128, -23 LUFS integrated, with a true-peak ceiling of -1 dBTP and a tolerance of 0.5 LU for file-based delivery.
Audiobooks on ACX, no LUFS at all. The ACX audio submission requirements ask for RMS between -23 dB and -18 dB, peaks below -3 dB, and a noise floor under -60 dB RMS. If you deliver audiobooks, measure with their analyzer, not with a LUFS meter alone.
Notice the order of operations on the last one. A chapter can sit at a perfectly reasonable -20 LUFS and still fail ACX because of a single hot peak or a noisy tail. LUFS tells you about average loudness, while the spec cares about three separate things.
Here is the opinionated bit. Do not master a podcast to -14 just because Spotify's page says -14. That number is for music. Speech with a -14 integrated reading usually means the limiter is working hard on consonants, and listeners hear it as fatigue within ten minutes.

Why does AI voice output need its own loudness check?
You might assume a synthetic voice arrives at a consistent level, since there is no mic distance or preamp drift. Sometimes that holds. Often it does not, and the causes are different from those in a recorded session.
Each render can leave the engine with its own overall gain. Change the voice, the speaking rate or the emotion setting, and the integrated loudness moves with it. A tense, clipped delivery and a calm, breathy one from the same cloned voice can differ by several LU. If you are building a scene from 40 separately rendered lines, you will hear jumps that no one recorded.
Three habits help.
Measure each render before you edit it. Write the integrated reading next to the filename in your log.
Match lines in a scene to each other first, then to the delivery target. Relative consistency matters more than the absolute number inside a mix.
Keep a reference line per voice. Normalize everything else against it, so a cloned narrator does not wander across chapters.
When you control emotion with sliders, as in AnyVoice's 8-slider system, expect the loudness to shift as intensity changes. Treat the integrated reading as part of the parameter notes, not an afterthought. For a game, that means normalizing per voice state before the lines go into middleware, because the engine will not do it for you.
What does a sane loudness workflow look like for a synthetic voice?
This is the order that wastes the least time. It works the same whether the file came from a cloned voice, a stock voice or a human narrator.
Render at the highest quality the tool offers, and keep the unprocessed file. Do not normalize inside the generator if you can avoid it, since you lose the original.
Measure integrated LUFS and true peak on the whole file, with a meter that follows BS.1770. Most DAWs include one, and several free plugins do too.
Calculate the gain. Target minus measured gives the offset in dB. If a render reads -21.4 LUFS and you want -16, you add 5.4 dB. The unit is linear, so 5.4 LU of gain moves the reading by exactly 5.4 LU.
Check the peak after the gain. If the true peak was -8.0 dBTP before, it becomes -2.6 dBTP, which clears a -1 dBTP ceiling. If it would land above the ceiling, you need a true-peak limiter, not more gain.
Apply a limiter only for the leftover problem. A ceiling at -1 dBTP with 1 to 2 dB of gain reduction is transparent on speech. Ten dB of reduction is audible pumping.
Re-measure the exported file, not the session. Codec conversion and dither can move the numbers slightly.
Loudness normalization at this stage is different from compression. Normalizing changes only gain, so the dynamics stay as rendered. If a line has a tense whisper followed by a shout and you want them closer, that is compression or clip gain, and it comes before the final loudness pass.
The session note: run the final check on the delivered format. A 128 kbps file can read a few tenths of a dB different from the WAV it came from.
Which mistakes waste the most time with LUFS?
Most problems come from the same four places.
Measuring the wrong thing. Short-term loudness during one loud phrase is not the integrated value. Chasing the momentary meter leads to overcorrection, and a file mastered to hit -16 on its loudest sentence ends up at -20 overall.
Treating -16 as a rule of nature. It is a convention. Some platforms normalize listening for you, and some do not. A web player or a smart speaker may apply no loudness control at all, so a file that is far too quiet will stay too quiet there.
Skipping the noise floor. Boosting by 5 LU also boosts hiss and room tone by 5 dB. If the source was noisy, the cleanup step has to happen before the gain step. Otherwise the problem scales with the number you are trying to hit.
Forgetting the stereo question. A mono voice delivered as a mono file and one delivered as dual mono can be 3 LU apart at the same fader position. Check which one your destination expects before you export.
Skip any plugin that promises a one-click loudness fix with no meter and no log of what it did. Loudness work is arithmetic. If you cannot see the before and after readings, you cannot defend the result.
Before your next session
Pick the destination first, because it decides everything else. Podcast: -16 LUFS stereo or -19 mono, peaks at -1 dBTP. Music-adjacent streaming: near -14 and respect the true-peak guidance. Broadcast: -23 under R 128. Audiobook: the ACX analyzer and its RMS, peak and noise floor limits.
Then write the number into your session template. Add a column for integrated LUFS and true peak next to every render. If you generate voices in batches, set a reference line per voice and match to that. Once the log exists, a new chapter or a scene rebuilt six months later takes minutes instead of an afternoon of guessing by ear.