[FFmpeg-devel] [Issue 664] [PATCH] Fix AAC PNS Scaling

[Alex Converse]

On Mon, Oct 6, 2008 at 8:22 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Mon, Oct 06, 2008 at 03:46:55PM -0400, Alex Converse wrote:
>> On Tue, Sep 30, 2008 at 11:25 PM, Alex Converse <alex.converse at gmail.com> wrote:
>> > Hi,
>> >
>> > The attached patch should fix AAC PNS scaling [Issue 664]. It will not
>> > fix PNS conformance.
>>
>> Here's a sightly updated patch (sqrtf instead of sqrt). The current
>> method of PNS will never conform because sample energy simpl doesn't
>> converge to it's mean fast enough. The spec explicitly states that PNS
>> should be normalized per band. Not doing it that way causes PNS-1
>> conformance to fail for 45 bands.
>
> elaborate, what part of the spec says what?

14496-3:2005/4.6.13.3 p184 (636 of the PDF)

> what is PNS-1 conformance ?

14496-4:2004/6.6.1.2.2.4 p94 (102 PDF)
14496-5/conf_pns folder

> the part that feels a little odd is normalizing random data on arbitrary
> and artificial bands, this simply makes things non random.
> This would be most extreemly vissibly with really short bands of 1 or 2
> coeffs ...
> another way to see the issue is to take 100 coeffs and split them into
> 10 bands, if you now normalize litterally these 10 bands then the 100
> coeffs will no longer be random at all, they will be significantly
> correlated. This may be inaudible, it may or may not sound better and
> may or may not be what the spec wants but still it feels somewhat wrong
> to me ...
>

Ralph Sperschneider from FhG/MPEG spelled it all out:
http://lists.mpegif.org/pipermail/mp4-tech/2003-June/002358.html

I'm not saying it's a smart way to design a CODEC but it's what MPEG picked.

>
>>
>> However with this patch there appears to be no audible difference
>> between the approaches.
>
>> I don't know the ideal mean energy so I'm
>> using the sample mean energy for 1024 iterations of the LCG.
>
> i assume cpu cycles got more expensive if people can only spare a few
> thousand
>

How many do you propose then? I tried running it over the whole period
and the result seemed low, I think it's a classic case of adding too
many equal size floating point values.

> anyway, without looking at the old thread (i would if i remembered the subj)
> and without redoing the math ...
> i suspect we have a 2^31 * 3^0.5 vs 2^31 / 3^0.5 issue somewhere
>

I tried a few values like that and I got more bands failing not fewer.

[...]