According to my very rudimentary understanding of the ITU-R BS.1770 standard, I thought that the LUFS (LKFS) value for any audio signals should not ever go positive.
However, there is a 5-second segment from an audio file I have whose integrated loudness level is +1.28 when measured using ffmpeg
, and +1.44 when measured using pyloudnorm
:
(stereo, source audio resampled at 48000 Hz, 16-bit signed little-endian integer waveform PCM)
[Parsed_loudnorm_0 @ 0x7fc245008680]
{
"input_i" : "1.28",
"input_tp" : "0.86",
"input_lra" : "2.90",
"input_thresh" : "-10.16",
...
How is this possible? Could this be an issue related to the implementations (i.e. ffmpeg
and pyloudnorm
) and not the algorithm itself?
I concede that I don't fully understand the math in the algorithm, and so if the algorithm does allow a positive value in certain situations, please explain.
ffmpeg
which doesn't offer the kind of configuration you are describing. Can you explain more on the meaning of this mapping and how it could potentially affect the calculation of LUFS? If it's of any relevance: if I transcode the signed 16-bit .wav into a 32-bit floating point .wav first, then 1. I can see usingnumpy
that there are samples beyond [-1, 1] and 2. I get a different (even greater) LUFS usingffmpeg
: at 1.32 instead of 1.28. $\endgroup$0xFFFF
is interpreted as -32768 or as -1.0 is fully up to your software; but it does scale the output $\endgroup$