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

[Andreas Cadhalpun]

On 21.04.2015 01:13, Claudio Freire wrote:
> 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).

Yeah, that's rather ugly and FLT_EPSILON isn't really a good minimum anyway.

>>> 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).

Are you sure your plots were done correctly?
Because I'm quite sure this is the correct first order approximation
of the minimum.

For ATH_ADD = 4 this gives 3407.068, which is quite close to Michael's value
(3407.080774800152).

> 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).

I actually derived the dependency of the minimum on ATH_ADD in first
order around ATH_ADD = 0 (using sagemath).

> Otherwise, handling the division by zero closer to where it happens is
> probably easier to do properly.

OK.

>>> 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.

I see.

>> 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.

OK, than let's keep doing that.

Best regards,
Andreas