[Mp4-tech] AAC - PNS - Testing

John Cox jc sj.co.uk
Tue Aug 5 11:52:49 EDT 2003


Whilst I hestitate to argue with you I believe that PNS may be a bit
more complex than that.  I had a discussion in this forum a month and a
bit ago in which we concluded that the current text of the standard was
probably wrong.  Here is probably the relevant part of the discussion
(which should allow you to find the rest of the thread if you are
interested):
To: John Cox <jc sj.co.uk>
Subject: [M4IF Technotes] Re: AAC: PNS scale factors
From: Ralph Sperschneider <sps iis.fhg.de>
Date: Mon, 23 Jun 2023 19:04:10 +0200
Cc: technotes lists.m4if.org
Dear John,
the reference software comes with the following code:
  norm = 1.0 / sqrt( size * MEAN_NRG );
  for (i=0; i<size; i++) {
    spec[i] = (Float)(random2( state ) * norm);
    nrg += spec[i] * spec[i];
  }
  s = 1.0 / sqrt( nrg );
  for (i=0; i<size; i++) {
    spec[i] *= s;
  }
Due to the second rescaling, the first scaling is obsolete. Thus,
MEAN_NRG can have any non-zero value, the output will always be the
same.
Beside this, the rescaling formula in the standard seems to be wrong,
and the formula used in the software seems to be correct.
However, the algorithm using MEAN_NRG does not assure that the energy
per band fits the requirements, since the delivered random values (its a
finite number) might have another mean energy. Therefore, the second
rescaling has been added in the software.
Subsequently, we tend to propose a correction of the pseudo code in the
standard as follows:
nrg=0;
gen_rand_vector( &spec[g][b][sfb][0], size );
for (i=0; i<len; i++) {
   nrg += spec[g][b][sfb][i] * spec[g][b][sfb][i];
}
/* avoid division by zero */
sqrt_nrg = sqrt (nrg);
if (sqrt_nrg <= 0.0f ) {
   sqrt_nrg = FLT_MIN;
}
scale = (2.0^(0.25*noise_nrg [g][sfb]))/sqrt_nrg;
/* Scale random vector to desired target energy */
for (i=0; i<len; i++) {
   spec[g][b][sfb][i] *= scale;
}
The subsequent text needs than to be adopted as follows:
"The function gen_rand_vector( addr, size ) generates a vector of length
<size> with signed random values. A suitable random number generator can
be realized using one multiplication/accumulation per random value."
What do you think about this?
Best regards,
Ralph
John Cox wrote:
> Hi
> 
> Thanks for the pointer.  If those reference wav files are definitive
> then the published standard is wrong and the reference software is
> right.  The scale factor should read:
> 
> scale = 1/sqrt(size * MEAN_NRG);
> 
> Many thanks
> 
> John Cox
> 
> 
>>Dear John,
>>
>>I don't have an answer to your first question.  But for the reference wav 
>>files, you can fetch them from:
>>ftp://mpaudconf:[email protected]/guests/mpeg4audio/incoming/testSequences/mpeg4audio-conformance/referencesWav/
>>
>>Regards,
>>Eddie
>>
>>At 04:09 PM 6/18/2003 +0100, John Cox wrote:
>>
>>>Hi
>>>
>>>The standard says (ISO/IEC 14496-3:2001(E); 4.6.13.3 page 174) that the
>>>initial scale factor for PNS values is:
>>>
>>>scale = 1/(size * sqrt(MEAN_NRG));
>>>
>>>however the reference software from the ISO site (both refSoft &
>>>rewrite) seems to calculate it as:
>>>
>>>scale = 1/sqrt(size * MEAN_NRG));
>>>
>>>Which is "correct" and what have other people done?
>>>
>>>I've found the PNS reference streams AL18*.mp4 & AL19*.mp4 (though not
>>>AL09,10,11) but no corresponding .wavs to check against - do they exist
>>>anywhere?
>>>
>>>Many thanks
>>>
>>>John Cox
>>>SJ Consulting
> 
> 
> 
> _______________________________________________
> Technotes mailing list
> Technotes lists.m4if.org
> http://lists.m4if.org/mailman/listinfo/technotes

On Mon, 4 Aug 2023 15:42:30 -0400, you wrote:
>AAC - PNS - TestingIf you are developing an MPEG-4 AAC profile decoder, then
>it must process PNS. As to the type of random noise generator, the exact
>type is neither stated nor constrained, so you can choose one that fits your
>complexity tradeoff. An finally for performance/complexity: I don't know of
>any tests showing the performance of just the PNS tools (i.e. on vs off),
>but the complexity of PNS in the decoder is very low (some lines of program
>code and a few multiplies per PNS sample.
>
>Schuyler Quackenbush
>---
>Schuyler Quackenbush    Chair, MPEG Audio Subgroup
>CEO, Audio Research Labs
>336 Park Ave, Suite 200, Scotch Plains, NJ 07076
>phone: 908 490 0700     srq audioresearchlabs.com
>fax:   908 842 9151     www.audioresearchlabs.com
>
>
>
>
>
>  -----Original Message-----
>  From: mp4-tech-bounces lists.mpegif.org
>[mailto:mp4-tech-bounces lists.mpegif.org]On Behalf Of Kannan GS Nambiar
>  Sent: Monday, August 04, 2023 7:28 AM
>  To: 'mp4-tech lists.mpegif.org'
>  Subject: RE: [Mp4-tech] AAC - PNS - Testing
>
>
>  Hi All,
>
>  A small correction to my previous query.Instead of Quality improvement in
>my 2nd line, please read it as Compression Improvement.Sorry for the
>trouble.
>
>  Regards
>  Kannan
>    -----Original Message-----
>    From: Kannan GS Nambiar [mailto:kannan.g.s.nambiar celstream.com]
>    Sent: Monday, August 04, 2023 4:02 PM
>    To: mp4-tech lists.mpegif.org
>    Subject: [Mp4-tech] AAC - PNS - Testing
>
>
>    Hi All,
>
>    I would like to get some info regarding the tradeoff between Utilization
>and processor power required for Perceptual Noise Substitution (PNS) as used
>in MPEG 4 AAC.Here by  Utilization I mean the Quality improvement of audio
>by using PNS.
>
>    I would also like to get some info on testing PNS.In case testing is
>going to take more time for the probable quality addition, I was wondering
>whether I can opt out of using PNS.Is there a correct way of generating the
>Random numbers,or can we define our own method???There was no mention to be
>seen regarding this in the standard.
>
>    Thanks and Regards,
>    Kannan
>



More information about the Mp4-tech mailing list