EBUR128 and LOUDNORM filters compute LRA differently

[hsn]

Summary of the bug:
How to reproduce:

ffmpeg -i song192k.mp4 -af ebur128,loudnorm=print_format=summary -f null -

Outputs:

[Parsed_ebur128_0 @ 000001f413d21a40] Summary:
  Integrated loudness:
    I:         -14.0 LUFS
    Threshold: -24.1 LUFS
  Loudness range:
    LRA:         3.6 LU
    Threshold: -33.9 LUFS
    LRA low:   -15.6 LUFS
    LRA high:  -12.0 LUFS
[Parsed_loudnorm_1 @ 000001f413fc4e40]
Input Integrated:    -14.2 LUFS
Input True Peak:      +0.1 dBTP
Input LRA:             5.9 LU
Input Threshold:     -24.3 LUFS

One LRA is 5.9 and second is 3.6. Song analysed by ​https://youlean.co/file-loudness-meter/ returns:

	Momentary Max = -9.81 LUFS
	Short Term Max = -11.50 LUFS
	Integrated = -14.00 LUFS

LRA definition is here: ​https://tech.ebu.ch/docs/tech/tech3342v2_0.pdf

[Balling]

What is song192k.mp4? eac3? Then you need to set -drc_scale 0.

[hsn]

I uploaded source song but its just normal:

Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 139 kb/s (default)

[Elon Musk]

Invalid command. You need to run separate filters, as ebur128 by default use input sample rate and does not upsample to 192kHz.

Also no sample to reproduce.

[Elon Musk]

Also you have not posted expected/correct LRA at all.

[Balling]

I uploaded source song but its just normal:

Where is the file?

[hsn]

File uploaded to ​https://streams.videolan.org/upload/

I don't believe its specific to file, here it computes different LRA for any file.

upsample to 192k doesn't change LRA.

ffmpeg -i song192k.mp4 -af aresample=192k,ebur128,loudnorm=print_format=summary -f null -

Software from Nugen audio we use in radio reports LRA 3.5, ILA -14.0 so it seems like EBUR128 filter is correct.

[Elon Musk]

How long in seconds are files?

Too short files are known to give invalid results.

[hsn]

45 seconds. TV intro.

[Balling]

Sample is here: ​https://streams.videolan.org/ffmpeg/incoming/10209/

[Balling]

Intersting, but simply first decoding aac to wav (be it 24 bit or 16 bit, or whatever) allows one to produce

Input True Peak: +0.0 dBTP

and not (I also get that when I decode using aac):

Input True Peak: +0.1 dBTP

That happens because

ffmpeg -c:a aac_fixed -i palestine-song192k.mp4 -c:a pcm_s24le -af ebur128,loudnorm=print_format=summary -f null -

(aac_fixed) is not the default, LOLZ.

There is also an issue that AAC is not gapless in the end, but that should not matter much. But will check gapless stuff. Gapless stuff does not affect this, nice!