[FFmpeg-devel] [Issue 664] [PATCH] Fix AAC PNS Scaling
Tue Oct 7 02:52:06 CEST 2008
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/188.8.131.52 p184 (636 of the PDF)
> what is PNS-1 conformance ?
14496-4:2004/184.108.40.206.2.4 p94 (102 PDF)
> 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:
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
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.
More information about the ffmpeg-devel