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

[Michael Niedermayer]

On Tue, Oct 07, 2008 at 03:38:54PM -0400, Alex Converse wrote:
> 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

I did know what i was talking about, the text i used as reference 
(14496-3:1998)
contains:
The noise substitution decoding process for one channel is defined by the following pseudo code:
nrg = global_gain - NOISE_OFFSET - 256;
for (g=0; g<num_window_groups; g++) {
   /* Decode noise energies for this group */
   for (sfb=0; sfb<max_sfb; sfb++)
      if (is_noise(g,sfb))
          noise_nrg[g][sfb] = nrg += dpcm_noise_nrg[g][sfb];
   /* Do perceptual noise substitution decoding */
   for (b=0; b<window_group_length[g]; b++) {
      for (sfb=0; sfb<max_sfb; sfb++) {
          if (is_noise(g,sfb)) {
             offs = swb_offset[sfb];
             size = swb_offset[sfb+1] - offs;
             /* Generate random vector */
             gen_rand_vector( &spec[g][b][sfb][0], size );
             scale = 1/(size * sqrt(MEAN_NRG));
             scale *= 2.0^(0.25*noise_nrg [g][sfb]);
             /* Scale random vector to desired target energy */
             for (i=0; i<len; i++)
                  spec[g][b][sfb][i] *= scale;
          }
      }
   }
}
---------------

You should direct your aggressive tone toward ISO for changing the specs
somewhere between 1998 and 2005.
Or maybe someone should tell them that international standards should be
freely available, makes it kinda more likely to have implementations
actually conform to them. But then maybe ISO just doesnt give a damn if
anyone does conform, in that case making incorrect drafts available and
asking for lots $$ for the correct specs is the best of course.

besides that, iam of course sorry for making rob replace correct code by
wrong ...


> , who likes to argue the finer points of the AAC
> specification without even having access to a copy of the conformance
> rules.

Any implementation following the spec is conformant. Thats pretty much by
definition.
Thus the spec should in principle be sufficient ...


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

They should have standarized the actual PRNG.
That would have made the normalization unneeded and have kept the data
globaly random, the way it is in aac:2005 is just wrong. per band
data that has been normalized to a quantized energy just isnt random
anymore.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- 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/55166f89/attachment.pgp>