# How can an audio segment report an integrated loudness (LUFS) greater than 0

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.

• Are your sample valued bounded by +1 and -1? Jan 24 at 12:58
• @Jazzmaniac Do you mean the .wav file itself? Right now it's a signed 16-bit integer LPCM file so it can't overflow. Jan 24 at 15:28
• 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! Jan 24 at 19:05
• @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. Jan 24 at 20:12
• 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 Jan 24 at 20:51