Opened 2 years ago

Last modified 2 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)

bonjour_twice.wav (73.0 KB) - added by p49k26x5 2 years ago.
bonjour_three.wav (109.4 KB) - added by p49k26x5 2 years ago.

Download all attachments as: .zip

Change History (5)

Changed 2 years ago by p49k26x5

Changed 2 years ago by p49k26x5

comment:1 Changed 2 years ago by p49k26x5

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

comment:2 Changed 2 years ago by cehoyos

  • Component changed from ffmpeg to avfilter

comment:3 Changed 2 years ago by p49k26x5

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.

Note: See TracTickets for help on using tickets.