Opened 6 years ago
Last modified 6 years ago
#6071 new defect
loudnorm filter always returns LRA of 0.0 LU with short files (less than ~3 seconds)
Reported by: | p49k26x5 | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avfilter |
Version: | git-master | Keywords: | loudnorm |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
I was trying to execute a 2 pass loudnorm filter on a file less than 1 second and it wouldn't work properly - the output of the second pass was not changed by much and the target output values were missed by a long way.
On the first pass, the measured input_lra value was always 0.0 which seems wrong and the output_i is nowhere near the target.
I verified my build was working ok by running a test on the loudnorm_before.mp3 found at http://k.ylo.ph/2016/04/04/loudnorm.html
ffmpeg version N-83034-gf48b6b8 Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 4.8.3 (GCC) 20140911 (Red Hat 4.8.3-9)
configuration: --prefix=/root/ffmpeg_build --extra-cflags=-I/root/ffmpeg_build/include --extra-ldflags='-L/root/ffmpeg_build/lib -ldl' --bindir=/root/bin --pkg-config-flags=--static --enable-gpl --enable-nonfree --enable-libfdk_aac
libavutil 55. 43.100 / 55. 43.100
libavcodec 57. 71.100 / 57. 71.100
libavformat 57. 62.100 / 57. 62.100
libavdevice 57. 2.100 / 57. 2.100
libavfilter 6. 68.100 / 6. 68.100
libswscale 4. 3.101 / 4. 3.101
libswresample 2. 4.100 / 2. 4.100
libpostproc 54. 2.100 / 54. 2.100
I setup a new test file and concatenated it together several times. The file bonjour.wav is 1.17 seconds long and the LRA could not be measured.
The file bonjour_twice.wav is 2.33 seconds and the LRA could not be measured.
The file bonjour_three.wav is 3.49 seconds and the LRA CAN be measured.
I have successfully used those measurements to properly normalise all 3 input files. ie. the normalisation pass works properly on small files.
ffmpeg -i bonjour_twice.wav -af loudnorm=I=-16:tp=-1.5:LRA=11:print_format=json -f null -
size=N/A time=00:00:02.33 bitrate=N/A speed=74.1x
{
"input_i" : "-22.85",
"input_tp" : "-10.19",
"input_lra" : "0.00",
"input_thresh" : "-32.85",
"output_i" : "-22.33",
"output_tp" : "-9.66",
"output_lra" : "0.00",
"output_thresh" : "-32.33",
"normalization_type" : "linear",
"target_offset" : "6.33"
}
ffmpeg -i bonjour_three.wav -af loudnorm=I=-16:tp=-1.5:LRA=11:print_format=json -f null -
size=N/A time=00:00:03.49 bitrate=N/A speed=46.2x
{
"input_i" : "-22.84",
"input_tp" : "-10.19",
"input_lra" : "0.30",
"input_thresh" : "-32.84",
"output_i" : "-15.94",
"output_tp" : "-3.29",
"output_lra" : "0.00",
"output_thresh" : "-25.94",
"normalization_type" : "dynamic",
"target_offset" : "-0.06"
}
Attachments (2)
Change History (5)
by , 6 years ago
Attachment: | bonjour_twice.wav added |
---|
by , 6 years ago
Attachment: | bonjour_three.wav added |
---|
comment:1 by , 6 years ago
comment:2 by , 6 years ago
Component: | ffmpeg → avfilter |
---|
comment:3 by , 6 years ago
Sorry, I was wrong about the normalisation pass. The filter does not properly normalise the audio of short files - even when it has accurate measurements from a much longer, concatenated file.
I should have mentioned that I was able to duplicate this behaviour on versions 3.2.2 and 3.1.2 - with the same, latest, 3rd party/non-ported libebur128