W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2013

Interpolation on WaveShaperNode?

From: Russell McClellan <russell@motu.com>
Date: Thu, 4 Apr 2013 18:27:09 -0400
Message-Id: <15996249-51AF-4858-908A-F3357FE06DC6@motu.com>
To: "public-audio@w3.org WG" <public-audio@w3.org>
It doesn't seem like the spec says anything about how WaveShaperNode interpolates between points on the wave shaping curve.  

If it's really meant to be for distortion curves or that sort of thing, linear or better interpolation might be appropriate to reduce quantization noise.

Currently the WebCore implementation does nearest neighbor interpolation, which could be quite useful for quantizing audio signals (i.e. for "bit crushing" or for exotic "creative uses" such as quantizing continuous LFO values to scales to be routed to a frequency parameter or similar).  

However, as a developer it feels wrong to rely on nearest neighbor interpolation as it is currently not guaranteed by the spec, and it seems decidedly suboptimal for the node's stated purpose.

As perhaps you know, one can approximate the SNR of quantization to around 6dB * number of bits.   "CD Quality" is 16 bits, which would require a 65kb table.  This works in my tests, but it may surprise some developers that one needs a table that large to create high quality output.  Even simple linear interpolation would significantly reduce the number of samples needed to produce high quality output from a wave shaper node.

Basically, my argument is this: currently, there's no advantage to using nearest neighbor interpolation because developer's can't depend upon it because it's not in the spec.  Either the webkit implementation should change to a better interpolation (even linear would be much better), or the spec should be modified to explicitly state that no interpolation will occur.  I guess I'd prefer the latter because it would allow developers to use the wave shaper as a quantizer, and it would only be a one-line change to the spec.

Thanks,
-Russell
Received on Thursday, 4 April 2013 22:27:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:18 UTC