[FFmpeg-trac] #9352(avfilter:new): loudnorm filter goofs loudness measurements in some cases

[FFmpeg]

#9352: loudnorm filter goofs loudness measurements in some cases
-------------------------------------+-------------------------------------
             Reporter:  Gregory      |                    Owner:  (none)
  Beauregard                         |
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:  avfilter
              Version:  unspecified  |               Resolution:
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Description changed by Gregory Beauregard:

Old description:

> Summary of the bug: The loudnorm filter can badly goof the integrated
> loudness in certain situations (e.g. particular noise after a resample)
> resulting in significant distortion if attempting to use it.
>
> Using the attached file `loudnorm_samp.mkv` (4.7 MB), 48 kHz DTS-HD,
> analyze the loudness with loudnorm to get integrated loudness ~-21:
> `"input_i" : "-21.57"`:
> {{{
> ffmpeg -i loudnorm_samp.mkv -af
> aresample=ocl=stereo,loudnorm=print_format=json -f null -
> }}}
>
> However, when we reanalyze it by giving the resampler a dither and
> specifying 48 kHz, the loudnorm filter goofs the integrated loudness with
> 0.13: "input_i" : "0.13"`:
> {{{
> ffmpeg -i loudnorm_samp.mkv -af
> aresample=ocl=stereo:dither_method=shibata:osr=48000,loudnorm=print_format=json
> -f null -
> }}}
>
> This results in really wrong re-normalization resulting in significant
> distortion. If we run `ebur128` to analyze the loudness instead of
> `loudnorm` in the situation where it goofs, `ebur128` outputs an expected
> -22.2 integrated loudness, and doesn't change between the two situations
> above:
> {{{
> ffmpeg -i loudnorm_samp.mkv -af
> aresample=ocl=stereo:dither_method=shibata:osr=48000,ebur128 -f null -
> }}}
>
> So there's some odd sensitivity in the `loudnorm` filter that's messing
> it up where `ebur128` is still ok.

New description:

 Summary of the bug: The loudnorm filter can badly goof the integrated
 loudness in certain situations (e.g. particular noise after a resample)
 resulting in significant distortion if attempting to use it.

 Using the reproducer file at
 [https://stream.gably.net/images/loudnorm_samp.mkv], `loudnorm_samp.mkv`
 (4.7 MB), 48 kHz DTS-HD, analyze the loudness with loudnorm to get
 integrated loudness ~-21: `"input_i" : "-21.57"`:
 {{{
 ffmpeg -i loudnorm_samp.mkv -af
 aresample=ocl=stereo,loudnorm=print_format=json -f null -
 }}}

 However, when we reanalyze it by giving the resampler a dither and
 specifying 48 kHz, the loudnorm filter goofs the integrated loudness with
 0.13: "input_i" : "0.13"`:
 {{{
 ffmpeg -i loudnorm_samp.mkv -af
 aresample=ocl=stereo:dither_method=shibata:osr=48000,loudnorm=print_format=json
 -f null -
 }}}

 This results in really wrong re-normalization resulting in significant
 distortion. If we run `ebur128` to analyze the loudness instead of
 `loudnorm` in the situation where it goofs, `ebur128` outputs an expected
 -22.2 integrated loudness, and doesn't change between the two situations
 above:
 {{{
 ffmpeg -i loudnorm_samp.mkv -af
 aresample=ocl=stereo:dither_method=shibata:osr=48000,ebur128 -f null -
 }}}

 So there's some odd sensitivity in the `loudnorm` filter that's messing it
 up where `ebur128` is still ok.

--
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/9352#comment:1>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker