If you are running loudnorm inside a -filter_complex graph on ffmpeg 8.1.2 and your audio slowly drifts out of sync with picture, or a seek based extract returns more seconds of audio than you asked for, this is a known gotcha, not your mix.
loudnorm's internal analysis stage runs at 192kHz. Inside a
-filter_complex graph that breaks the downstream presentation timestamps, even if you follow it with aresample=48000. The encoded track ends up carrying roughly 2.5x more samples than its declared duration. Everything downstream that trusts the container duration (players, extractors, transcription tools) starts lying to you in slightly different ways.
The fix: do not run loudnorm in-graph. Render your mix without it, normalize as a separate standalone pass, then remux:
ffmpeg -i mix.wav -af loudnorm=I=-16:TP=-1.5:LRA=11 -ar 48000 out.wav
ffmpeg -i video.mp4 -i out.wav -c:v copy -c:a aac -map 0:v:0 -map 1:a:0 final.mp4
Verify with nb_frames * 1024 / sample_rate ≈ duration from ffprobe, rather than trusting a player's scrubber or a transcript's timestamps (a transcription tool running under music can silently misplace its own timestamps too, so it is not a reliable ground truth here).
Full writeup with the mixed-WAV-format concat gotcha that goes with it:
github.com/locoprowrestling/ffmpeg-tricks
Curious if this reproduces on other ffmpeg versions. If you have hit it, or ruled it out on a different build, I would like to know.
Top comments (0)