[FFmpeg-devel] [libav-devel] [PATCH] aacpsy: avoid norm_fac becoming NaN

[Claudio Freire]

On Mon, Apr 20, 2015 at 7:18 PM, Andreas Cadhalpun
<andreas.cadhalpun at googlemail.com> wrote:
> On 20.04.2015 22:15, Claudio Freire wrote:
>> TL;DR, band->thr should not be negative ever, band->thr == 0.0f would
>> cause lots of issues on its own if band->energy != 0.0f in such a case
>> (though I don't see how band->thr can be 0.0f if band->energy is not),
>
> This could happen in pathological cases:
>     band->energy = 1e-37f
>     band->thr    = band->energy * 0.001258925f = 0.0f

That's an unhappy situation, but I don't see a fix for it (in theory,
band->thr = FFMAX(FLT_EPSILON, band->energy * ...), but that's quite
fragile).


>
>> The long version:
>>
>> ath should approximate the shape of the absolute hearing threshold, so
>> yes, it's best if it really uses the minimum, since that will prevent
>> clipping of the ath curve and result in a more accurate threshold
>> computation.
>
> So you agree with my patch fixing minath?
> Or would you prefer a version with:
>     minath = ath(3410 - 0.733 * ATH_ADD, ATH_ADD)

Well, that's not really closer to the minimum (a few tests with gnuplot say).

But yeah, something that makes it closer, sure.

I'd try to symbollicaly deriving the minimum if you really mean to
improve that (should be doable, it's all differentiable stuff).
Otherwise, handling the division by zero closer to where it happens is
probably easier to do properly.

>> But it's hard to enforce that
>> without clipping it, and it's not worth the trouble attempting it.
>
> Why would clipping be a problem?

It would flatten the masking floor around the part where it matters
most (the surroundings of the minimum).

Still, we're talking about extremely faint signals, so it's still a
very edgy case.

> What about the attached patch?

It's no guarantee. Math can still push that into zero. It's better to
handle the underflow where it matters (ie: where the division by ath
or thr happen, as in the previous patches).

>
>> I don't believe accurate computation of ath to that point would improve
>> encoding that much. Any reasonable approximation will do.
>
> It's more about avoiding nasty problems with division by 0.

Agreed.

Thus, I favor handling it where the division is attempted.