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

[Alex Converse]

On Tue, Oct 7, 2008 at 3:24 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Tue, Oct 07, 2008 at 01:48:40PM -0400, Alex Converse wrote:
>> On Tue, Oct 7, 2008 at 1:01 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> > On Mon, Oct 06, 2008 at 11:30:56PM -0400, Alex Converse wrote:
> [...]
>> >>
>> >>
>> >> >
>> >> >>
>> >> >> >
>> >> >> >>
>> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> 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++;
>> >> >> >    }
>> >> >> > }
>> >> >> >
>> >> >>
>> >> >> That will only hold 5 or 6 big values 2^64/((2^31)^2) = 4.
>> >> >
>> >> > read the code again please, especially var2
>> >> > also, just to make sure you have the types correct
>> >> >
>> >> > int min= -(1<<31)+1;
>> >> > int max=  (1<<31)-1;
>> >> > int64_t i;
>> >> > uint64_t var=0;
>> >> > uint64_t var2=0;
>> >> >
>> >>
>> >> Why are we leaving out (int)0x80000000?
>> >
>> > because otherwise the mean would be -0.5.
>>
>> But isn't it in the output space?
>
> yes, approximately once every 2^32 values
>
>
>> We're trying to find the energy of
>> one period of the LCG no?
>
> yes
>
>
>> If we are going to ignore it shouldn't the
>> LCG be written to explicitly reject it?
>
> not really, no
>
>
>> And adding logic to explictly
>> reject it seems nutty for such a small deviation in the mean.
>
>> It has
>> far more significance in energy.
>
> .0000000008065490087349327716857165436802471967650737954699499861349...
> vs.
> .0000000008065490090166167590309147460339081318382480645839026837603...
> for the normalization constants
>
> iam not sure how you can call that "far more significance" on one hand and
> pretend that skiping per band normalization would be ok OTOH.
>

Says the man who made Rob change it from the correct per band
implementation in the first place because he didn't know what he was
talking about, who likes to argue the finer points of the AAC
specification without even having access to a copy of the conformance
rules.

Per band is what MPEG asks for. Not doing it per band results in
statistics that deviate significantly from the sample statics measured
by the encoder that the decoder is trying to mimic. They have made
this clear on numerous occasions.

--Alex