[FFmpeg-devel] [Issue 664] [PATCH] Fix AAC PNS Scaling
Alex Converse
alex.converse
Tue Oct 7 22:53:57 CEST 2008
On Tue, Oct 7, 2008 at 4:12 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> 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.
>
I recommend you complain to the head of your national delegation.
ISO is insufferable more than once I've found an issue that's caused
them to get all quiet then pop out a TC months later. Or send me an
already approved TC that's still broken.
> 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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iD8DBQFI68LHYR7HhwQLD6sRAkFaAJ99B6sLzK8c4uJe8lo/zgp3lxKbgQCeKeHX
> uvpTxg3mxhj1wSCev0TuLaU=
> =hFYv
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>
More information about the ffmpeg-devel
mailing list