Changes between Version 8 and Version 10 of Ticket #9352


Ignore:
Timestamp:
Jul 30, 2021, 3:34:40 AM (5 years ago)
Author:
Gregory Beauregard
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #9352

    • Property Keywords loudnorm added

  • Ticket #9352 – Description

    v8 v10  
    1919
    2020So it seems like there's some odd sensitivity in the `loudnorm` filter to certain inaudible noise that's messing it up where `ebur128` is still ok.
     21
     22Update: You can use the following two `ebur128` filter runs similar to the above without and without inserting a `,aformat=r=192000`, resampling to 192 kHz as the `loudnorm` filter does unconditionally internally (but `ebur128` does not). I've attached the outputs as `192ebur.txt` and `48ebur.txt`.
     23
     24{{{
     25ffmpeg -i loudnorm_samp.mkv -af aresample=ocl=stereo:dither_method=shibata:osr=48000,aformat=r=192000,ebur128 -f null - > 192ebur.txt 2>&1
     26}}}
     27{{{
     28ffmpeg -i loudnorm_samp.mkv -af aresample=ocl=stereo:dither_method=shibata:osr=48000,ebur128 -f null - > 48ebur.txt 2>&1
     29}}}
     30
     31In the 192 kHz resample the `ebur128` filter wrongly measures the integrated loudness to `I:          -0.1 LUFS`, similar to the wrong `loudnorm` measurement, but the 48 kHz case measures -22.2 as you'd expect. My understanding is the two filters share some measurement code, so presumably ffmpeg's measurement code is broken at 192 kHz.