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

[Michael Niedermayer]

On Mon, Oct 06, 2008 at 08:52:06PM -0400, Alex Converse wrote:
> 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

do you happen to have URLs for these?


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

yes, so i guess the most sensible solution would be to precalculate
a second of noise normalized to the band sizes and randomly pick from
these.


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

real mathematicans tend not to use floats that are bound to rounding errors

try:
for(i=min; i<=max; i++){
    uint64_t a= i*i;
    var += a;
    if(var < a){
            var2++;
    }
}

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081007/b1efe564/attachment.pgp>