On Sun, 19 Nov 2023, Paul B Mahol wrote:

> On Fri, Nov 17, 2023 at 7:38 AM Kyle Swanson <k@ylo.ph> wrote:
>
>> Hi,
>>
>> On Wed, Nov 15, 2023 at 12:39 PM Paul B Mahol <onemda@gmail.com> wrote:
>> >
>> > Attached.
>>
>> Only had a few minutes to look at this. Seems like more than just
>> merging two filters, I see a bunch of new filter options for example.
>> Can you explain?
>>
>
> The linear mode and scanning, both input to filter and filter output itself
> should give similar results.
> The dynamic mode now actually can be configured how aggressively it will
> expand / compress audio.
> Because current state of filter have numerous issues:
>
> - using unmaintained old libebur128 module, when same functionality is
> already available in existing filter.
> - code duplication and functionality duplication due the above
> - buggy limiter - causing clipped samples randomly
> - buggy first and final frame filtering
> - over-complicated flow path for dynamic code in filter
> - excessive compressing of audio dynamic range, causing extreme smaller
> LRU from output audio
> - and probably more that I forgot
>
> Some options from this patch can be probably removed, like attack/release
> options, and just use defaults as currently in patch.

Previously ebur128 functionality was decoupled from specific filters, so 
there was a chance that multiple filters can use it. Unfortunately 
f_ebur128.c was never migrated to use internal ebur128 lib, as far as I 
remember the maintaner rejected the idea for some reason back then.

IMHO having some generic ebur128 functionality would be preferable. I 
have an old patch for example which adds EBUR128 mode to af_dynaudnorm, 
see attached for reference. Looks much cleaner than af_loudnorm, which was 
always a bit overcomplicated and slightly buggy, as you mentioned.

So please consider two things:

- Can you keep some generic ebur128 functionality which can easily reused
   by multiple filters? I don't mind if it is the old code from ebur128 lib
   or current code from f_ebur128, but it should be reusable internal ff_
   functions.

- Does it make sense to maintain a separate loudnorm filter for EBUR128
   loudness, or it can be integrated into af_dynaudnorm? Because I kind of
   think that having this as a option of af_dynaudnorm would be
   cleaner, at least for the dynamic normalization functionality. For the
   linear mode, well, we already have compressor filters, so I am not sure
   if that mode is worth keeping. But maybe it is easier for the end user,
   I don't know.

Thanks,
Marton