You've exported a batch of podcast episodes, and the files sound fine in isolation. Then you play them back-to-back. One episode feels quiet, another jumps out of the speakers, and the short clips cut for social media sound harsher than the original mix. That's the point where FFmpeg normalize audio stops being a one-command task and becomes a delivery decision.
A podcast export might target -23 LUFS for a broadcast-style workflow, while a streaming-oriented version might use -16 LUFS. A short-form edit may need a conservative true-peak ceiling rather than more average volume. These targets come from different loudness priorities, so the right filter depends on where the file is going and how much of its original dynamics you need to preserve.
Table of Contents
- What Audio Normalization Really Means in FFmpeg
- Peak and Volume Normalization the Fast Way
- Understanding EBU R128 and the loudnorm Filter
- Running a Two-Pass loudnorm Workflow Step by Step
- Choosing Between loudnorm, ffmpeg-normalize, and loudgain
- Batch Normalization and Running FFmpeg at Scale
- Common Pitfalls and a Quick Normalization Checklist
What Audio Normalization Really Means in FFmpeg
Audio normalization can mean several different operations. The simplest is peak normalization, which raises or lowers the entire waveform until its highest sample reaches a ceiling. A second approach changes average level with compression or dynamic processing. The third measures perceived loudness across the program and targets an integrated loudness value, usually expressed in LUFS.
Those methods solve different problems. A fixed gain can make one file quieter or louder, but it can't make a quiet episode match a loud episode unless you first measure both. It also can't bring buried dialogue forward without changing the balance between voice, music, and effects.
Start with the delivery target
Before writing a filter, answer three questions:
- Do I only need a ceiling? Use a measured gain adjustment when the mix already sounds consistent.
- Do I need consistent perceived loudness? Use
loudnorm, which measures integrated loudness, loudness range, and true peak. - Do I need to preserve the mix exactly? Prefer a linear, two-pass workflow, then validate the result rather than relying on a quick single-pass conversion.
A volume filter is a scalar operation. If you apply volume=0.5, FFmpeg multiplies every sample by the same factor. True loudness normalization requires analysis because the file's peak amplitude doesn't tell you how loud the whole program feels.
For related media workflows, see this guide to extracting audio from video with FFmpeg. The same target-driven thinking applies whether the source is a WAV master, an MP4 export, or an audio track extracted from a video.
Peak and Volume Normalization the Fast Way
Peak normalization is the right tool when the mix already works and you only need to prevent overload. It fits short voiceovers, social clips with a stable mix, and files that are slightly hot but don't vary much in perceived level.
Start by measuring the source:
ffmpeg -i input.wav -af volumedetect -f null -
FFmpeg prints values such as max_volume to the log. If the maximum sample is -7.0 dB, and your desired ceiling is -1.0 dBFS, the required gain is approximately +6 dB. Apply that gain like this:
ffmpeg -i input.wav -af "volume=6dB" -c:a pcm_s16le output.wav
You can also use a scalar when that's more convenient:
ffmpeg -i input.wav -af "volume=0.5" -c:a pcm_s16le quieter.wav
The scalar is useful when you already know the adjustment. It isn't a measurement-based normalizer, though, so it won't adapt from one file to the next.
Automate the measurement loop
For a quick shell workflow, capture the detected peak, calculate the gain, and run a second command:
peak=$(ffmpeg -i input.wav -af volumedetect -f null - 2>&1 | awk '/max_volume/ {print $5}'); gain=$(awk -v p="$peak" 'BEGIN {print -1-p}'); ffmpeg -i input.wav -af "volume=${gain}dB" output.wav
This assumes the log format is available as expected and that the source contains a meaningful detected peak. Test it on representative files before using it in production.
Peak normalization can't solve episode-to-episode loudness variance, dialogue masked by music, or a mix with excessive dynamics. It can also raise the noise floor along with the wanted signal. When perceived loudness is the actual requirement, use loudnorm instead of treating peak amplitude as a substitute.
Understanding EBU R128 and the loudnorm Filter
The EBU R128 recommendation defines a loudness-based way to evaluate program material. Its reference target is -23.0 LUFS, with live-material tolerance commonly described as ±0.5 LU to ±1.0 LU, depending on context. This differs from peak normalization because it evaluates the program as a listening experience rather than only inspecting its highest sample.
FFmpeg's loudnorm filter exposes three important targets:
I, integrated loudness, describes the program's overall loudness in LUFS.LRA, loudness range, describes variation across the program in LU.TP, true peak, limits reconstructed peaks that can appear between samples or after codec processing.
The FFmpeg loudnorm documentation supports dynamic and linear modes, as well as single-pass and double-pass workflows. A single-pass command is straightforward:
ffmpeg -i input.wav -af "loudnorm=I=-16:LRA=8:TP=-1" output.wav
The I, LRA, and TP values are delivery choices, not universal laws. These practical presets provide a useful starting point:
| Target | Integrated (I) | Loudness Range (LRA) | True Peak (TP) |
|---|---|---|---|
| Broadcast-oriented | -23 LUFS | 7 LU | -2 dBTP |
| Streaming-oriented | -16 LUFS | 8 LU | -1.5 dBTP |
| Short-form social | -14 LUFS | 11 LU | -1 dBTP |
The broadcast-oriented values align with the EBU R128 target family, while streaming-oriented examples commonly use -16 LUFS with a true-peak ceiling near -1.5 dBTP. Social content often benefits from retaining more range rather than aggressively compressing every transient.
Dynamic versus linear mode
In linear mode, loudnorm attempts to apply a static gain based on the measured source. That preserves the internal relationships of a mix, but it can't always satisfy the integrated, range, and true-peak targets simultaneously. A single-pass linear command may reach the intended I value while missing LRA or TP.
Dynamic mode can alter level over time to meet the requested constraints. That makes it more adaptable for inconsistent material, but it can also change the feel of speech and music. For a library that must match closely, measure first and use two-pass linear processing when the source supports it. Use single-pass dynamic processing when convenience and streaming behavior matter more than exact repeatability.
For inspecting streams before selecting a filter, use this practical FFprobe tutorial.
Running a Two-Pass loudnorm Workflow Step by Step
A two-pass workflow separates measurement from rendering. The first command analyzes the entire input and prints JSON. The second command feeds those measurements back into loudnorm, allowing FFmpeg to apply a more deliberate correction.
For a streaming-oriented podcast target, run:
ffmpeg -i input.wav -af "loudnorm=I=-16:TP=-1.5:LRA=11:print_format=json" -f null - 2> measurement.txt
The JSON block contains the measured integrated loudness, true peak, loudness range, threshold, and target offset. Keep that output associated with the source file. Don't mix measurements from one target profile with a different second-pass target.
Apply the measured values
After extracting the values from the JSON, construct the second pass:
ffmpeg -i input.wav -af "loudnorm=I=-16:TP=-1.5:LRA=11:measured_I=-19.6:measured_TP=-5.9:measured_LRA=0.6:measured_thresh=-29.6:offset=0.1:linear=true" -c:a libmp3lame -b:a 192k normalized.mp3
The measured values in this example are placeholders for the values produced by your own first pass. Replace them with the actual JSON fields. A production script should parse the output rather than rely on manually copied values.
For a WAV deliverable, preserve an uncompressed PCM output:
ffmpeg -i input.wav -af "loudnorm=I=-23:TP=-2:LRA=7:measured_I=MEASURED_I:measured_TP=MEASURED_TP:measured_LRA=MEASURED_LRA:measured_thresh=MEASURED_THRESH:offset=TARGET_OFFSET:linear=true" -c:a pcm_s16le broadcast.wav
The filter's true-peak detection can use upsampling, and the documentation notes behavior around 192 kHz detection unless linear mode is used. That matters when you compare measurements between modes or validate a file after encoding.
Validate the rendered file
Don't assume the second pass succeeded because FFmpeg exited cleanly. Run a measurement pass against the output:
ffmpeg -i normalized.mp3 -af "loudnorm=I=-16:TP=-1.5:LRA=11:print_format=summary" -f null -
You can also inspect sample peaks with:
ffmpeg -i normalized.mp3 -af volumedetect -f null -
An offset cap is useful when processing already-loud masters. It prevents the workflow from applying excessive gain solely because a target is configured without considering the source. Keep the cap aligned with your delivery policy, and reject or flag files that require corrective mixing rather than normalization.
Choosing Between loudnorm, ffmpeg-normalize, and loudgain
The built-in loudnorm filter gives you the most direct control. It ships with FFmpeg, works well in scripts, and avoids another runtime dependency. The trade-off is operational work. You must manage the measurement pass, parse JSON from stderr, construct the second command, and decide how to handle failed or unusual inputs.
ffmpeg-normalize wraps FFmpeg in a Python workflow. It can simplify batch processing and automate two-pass behavior, but your pipeline now depends on Python packaging as well as the FFmpeg binary. That added layer is useful for teams that want a repeatable command-line interface, but it introduces another component to pin, test, and monitor.
loudgain is a separate ReplayGain-oriented tool. It suits music libraries where tagging or applying gain based on loudness analysis is more important than building a custom FFmpeg filter graph. It isn't a replacement for every media-transcoding pipeline, especially when you need to re-encode audio inside a video container.
| Feature | loudnorm filter | ffmpeg-normalize | loudgain |
|---|---|---|---|
| Installation | Included with FFmpeg | Python package plus FFmpeg | Standalone utility |
| Batch handling | You script it | Wrapper automates more of it | Suited to library-style workflows |
| Two-pass control | Manual but explicit | Generally automated | ReplayGain-oriented analysis |
| Dynamic or linear choice | Direct filter parameters | Exposed through wrapper options | Depends on its tagging or gain workflow |
| Video containers | Native FFmpeg support | Uses FFmpeg underneath | Less suited to video remux pipelines |
| CI integration | Strong with shell or scripts | Strong when Python is already standard | Useful for music-focused jobs |
| Re-encode requirement | Required when filtering audio | Required when filtering audio | May apply tags or gain depending on workflow |
Match the tool to the operator
A solo creator usually benefits from the direct loudnorm command because there are fewer moving parts. A podcast team processing recurring batches may prefer ffmpeg-normalize to reduce boilerplate around measurement and output naming. A broadcast engineer often wants the built-in filter exposed directly, since target profiles, validation, logs, and failure handling belong in the delivery system.
The key trade-off isn't brand preference. It's whether you need precise, inspectable filter behavior, convenient batch orchestration, or music-library loudness management.
Batch Normalization and Running FFmpeg at Scale
Batch processing fails when the workflow treats every file as an isolated command. A reliable pipeline gives each source its own measurement record, output path, target profile, and validation result. Cache the first-pass JSON beside the source or in a dedicated metadata directory, then reuse it only when the input and target profile haven't changed.
For a folder containing WAV and MP3 sources, a Bash loop can establish the basic shape:
mkdir -p measurements normalized
`find . -maxdepth 1 -type f ( -name '.wav' -o -name '.mp3' ) -print0 | while IFS= read -r -d '' input; do
base=$(basename "$input")
stem="${base%.*}"
json="measurements/${stem}.json"
output="normalized/${stem}.mp3"
if [ ! -f "$json" ]; then
ffmpeg -hide_banner -i "$input"
-af "loudnorm=I=-16:TP=-1.5:LRA=11:print_format=json"
-f null - 2> "$json"
fi
values=$(python3 parse_loudnorm.py "$json")
eval "$values"
ffmpeg -hide_banner -i "$input"
-af "loudnorm=I=-16:TP=-1.5:LRA=11:measured_I=$measured_I:measured_TP=$measured_TP:measured_LRA=$measured_LRA:measured_thresh=$measured_thresh:offset=$target_offset:linear=true"
-c:a libmp3lame -b:a 192k "$output"
done'
The parser is intentionally external because FFmpeg's stderr includes logs around the JSON block. In production, parse the JSON defensively, verify that every required field exists, and write a manifest containing source hash, target profile, command, and validation status.
Add controlled concurrency
GNU parallel is appropriate for CPU-bound jobs when your machine has spare capacity. xargs -P can fan out simpler tasks, but unrestricted concurrency can cause disk contention, thermal throttling, or memory pressure. Start conservatively and measure the whole pipeline, not just FFmpeg's individual process time.
For recurring cloud jobs, RenderIO's batch-processing practices provide a useful model for queueing, retries, and webhook-driven completion. RenderIO accepts FFmpeg commands through an API and can run normalization without requiring your team to maintain local workers. Account for queue policy, rate limits, storage handling, and the cost model before moving a workload off a local machine. Local parallel processing can remain the simpler choice for a modest, predictable library.
Common Pitfalls and a Quick Normalization Checklist
The most damaging normalization errors come from treating the target loudness value as the whole specification. A linear gain can push true peaks too high, while dynamic processing can flatten speech that was intentionally mixed with breathing room. Loudness is only correct when the output also survives encoding, playback, and the intended delivery context.
Source and output formats deserve equal attention. A WAV master and a broadcast MP4 may use different sample-rate and codec requirements, so validate the final encoded file rather than only the pre-encode audio. Likewise, don't assume an AAC profile and an Opus profile will behave identically after encoding. The codec, bitrate, container, and playback device all belong in the test plan.
Practical rule: Normalize the file you will deliver, then measure that delivered file again.
Mixed-content masters need judgment. A voice-and-music program may meet the integrated target while dialogue still feels masked. In that case, normalization isn't a substitute for balancing the mix. Multi-language masters also need care because loudnorm supports up to two streams, so separate language tracks may require separate filter passes and validation.
Use this pre-flight checklist:
- Verify the sample rate: Confirm that the source and delivery format meet the receiving specification.
- Choose the target profile: Select integrated loudness, loudness range, and true-peak values for the actual destination.
- Run the measurement pass: Capture
print_format=jsonoutput for every source. - Validate the JSON: Check that the measured loudness, range, threshold, true peak, and offset are present.
- Apply the correction: Use the matching measured values and
linear=truewhen preserving the mix is the priority. - Confirm true peak: Measure the final encoded output, not only the input or intermediate render.
- Re-listen on the target device: Check speech intelligibility, music balance, pumping, clipping, and perceived consistency.
RenderIO lets you submit FFmpeg normalization commands to cloud workers, track jobs through polling or webhooks, and receive the processed output without managing local queues or storage. If you're building a recurring podcast, social-video, or media automation pipeline, visit RenderIO to test the workflow with your own loudnorm commands.