0
$\begingroup$

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.

$\endgroup$
7
  • $\begingroup$ Are your sample valued bounded by +1 and -1? $\endgroup$ – Jazzmaniac Jan 24 at 12:58
  • $\begingroup$ @Jazzmaniac Do you mean the .wav file itself? Right now it's a signed 16-bit integer LPCM file so it can't overflow. $\endgroup$ – Tony Wu Jan 24 at 15:28
  • $\begingroup$ yes, but the values in that LPCM file, are they mapped to [-1; +1], or to some other range, after being read into your software? The fact that it's PCM doesn't say anything about the scaling! $\endgroup$ – Marcus Müller Jan 24 at 19:05
  • $\begingroup$ @MarcusMüller I am using 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 using numpy that there are samples beyond [-1, 1] and 2. I get a different (even greater) LUFS using ffmpeg: at 1.32 instead of 1.28. $\endgroup$ – Tony Wu Jan 24 at 20:12
  • $\begingroup$ well, there's bytes in your file. Whether a pair of bytes 0xFFFF is interpreted as -32768 or as -1.0 is fully up to your software; but it does scale the output $\endgroup$ – Marcus Müller Jan 24 at 20:51
1
$\begingroup$

I did download this annoying video and analyzed the part with a vuvuzela. You should take a note that:

  • This part is clipped
  • The audio is stereo

And that pretty much solves the mystery.

enter image description here

If you calculate the loudness for each of the channels separately you will get approximately -1.4 LUFS. Since this is a stereo track you add those levels together. For incoherent sources, you would roughly expect a 3dB of boost. Lo and behold, the total loudness calculated from the stereo track is approximately 1.6 LUFS (+3.2).

If you think about it, this makes perfect sense. What happens if you take one of those clipped channels and play it back through a speaker? You gonna get some SPL. Now, add a second speaker and play the other channel, you would expect to be even louder (3dB louder to be precise). Therefore LUFS accounts for that.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.