Re: Discrepancy in the definition of calculateNormalizationScale

On Tue, Apr 2, 2013 at 8:47 PM, Chris Rogers <> wrote:

> On Tue, Apr 2, 2013 at 3:09 PM, Ehsan Akhgari <>wrote:
>> The calculateNormalizationScale function in the spec has been copied
>> verbatim from the WebKit source code, and the WebKit function has changed
>> since then <
>> If these changes have been intentional, they should be reflected in the
>> spec.  Otherwise we should probably file a WebKit bug to revert them.
> Hi Ehsan, the only differences I can see are that the WebKit code is using
> an optimized function vsvesq() and is using "GainCalibration = -58" as a
> decibel value (later converted to scalar value) which is essentially
> identical to "GainCalibration = 0.00125" in the spec.
> I could be missing something, so am happy to change things as necessary...

Hmm, no after a closer look, you're right.

>> Also, it seems like that function is specific to an AudioContext with a
>> sampling rate of 44100.  If that is the case, the function in the spec
>> should be reworded to use AudioContext.sampleRate instead.
> The code works with an AudioContext of any sample-rate.  The 44100 is a
> reference sample-rate, but the actual sample-rate is taken into account.
>  What's not really clearly stated in the spec is that the .buffer attribute
> must be set to an AudioBuffer of the same sample-rate as the AudioContext.
>  That's a quick fix I can do right now...  The good news is that
> decodeAudioData() will return an AudioBuffer of this sample-rate, so things
> just work out.

I see, yes it would be nice if you could spec that restriction.


Received on Thursday, 4 April 2013 13:28:51 UTC