W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

[Bug 17404] (OscillatorFolding): Oscillator folding considerations

From: <bugzilla@jessica.w3.org>
Date: Sat, 06 Oct 2012 01:24:02 +0000
Message-Id: <E1TKJ7a-0006Nk-Sj@jessica.w3.org>
To: public-audio@w3.org

--- Comment #4 from Chris Rogers <crogers@google.com> 2012-10-06 01:24:02 UTC ---
(In reply to comment #3)
> Over all, the new text is non-normative, except for the phrasing "care must be
> taken to discard (filter out) the high-frequency information". Here, it is said
> that something must be done, without specifying what must be done.
> At this point, I don't really have a preference for whether we should strive to
> have a common method for synthesizing sound, or allow for variations between
> implementations. However, I think it should be clear what the upper/lower
> quality bound is.
> For instance, if we disregard the anti-aliasing requirement, it would be
> possible for an implementation to simply do an inverse FFT of the wave table as
> a pre-processing step, and then do nearest neighbor interpolation into that
> time-domain signal without any anti-alising or interpolation efforts at all.
> Would that be acceptable?

>From a purist perspective, I don't consider that an acceptable technique for
synthesis of high-quality oscillators because it will generate considerable
aliasing.  But, I consider it ok for a basic implementation, especially if it's
used as a performance optimization for low-end hardware.  Once again, I'd make
the analogy with drawing lines.  It's "allowed" for a browser to draw jagged
lines, but they might not look so great compared with nicely anti-aliased
smooth lines.

I'm happy to share implementation techniques for getting reasonably
high-quality oscillators.  In WebKit, the approach we're currently taking is a
multi-table approach where we generate a dozen or so tables with successively
filtered out partials, then index dynamically into the table appropriate for
the instantaneous playback frequency.  We have code to share, or we could
discuss the general approach in more technical detail (without code).  In any
case, that would be an informative section if we added something to the spec

Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Saturday, 6 October 2012 01:24:03 UTC

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