W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: AnalyzerNode - magnitude/phase

From: Srikumar Karaikudi Subramanian <srikumarks@gmail.com>
Date: Sat, 28 Sep 2013 07:11:23 +0530
Cc: Chris Lowis <chris.lowis@gmail.com>, public-audio@w3.org
Message-Id: <DDB3A7C8-F786-485D-B978-B84B4BA9AAE1@gmail.com>
To: Chris Lilley <chris@w3.org>
(replying inline)

On 27 Sep, 2013, at 10:48 PM, Chris Lilley <chris@w3.org> wrote:

> Hello Chris,
> Friday, September 27, 2013, 11:22:52 AM, you wrote:
>> i) Allow getFloatFrequencyData() to return an array of complex values somehow.
> Seems more technically correct and less likely to be implemented (oh
> no, complex numbers)
>> ii) Add methods for getRealFrequencyData() and getImaginaryFrequencyData()
> ditto (name is correct but scary)

An independent getComplexFrequencyData(realArray, imagArray) would serve
these purposes I think.

>> iii) Add getFloatPhaseData() which would return the phase of the
>> calculated spectrum, and leave getFloatFrequencyData() returning the
>> magnitude.
> That seems like the best option to me. And yes, getting the phase is
> useful. What about an allpass filter as an example? Square waves in,
> tilted square waves out, that sort of thing.

If such a getFloatPhaseData() is specified, then the standard would need
to include a specific way of dealing with phase continuity - i.e. phase is
modulo range [-PI, PI] or [0, 2PI] or decide that jumps across the 2PI boundary 
are resolved by offsetting the phase to be continuous, etc. The Real/Imag
split would simplify these decisions and put the power in the hands of the
dev. R/I would also be computationally simpler (no log->exp and arctan->sin/cos 
ops) when passing to an IFFT function for synthesis.


> -- 
> Best regards,
> Chris                            mailto:chris@w3.org

Received on Saturday, 28 September 2013 01:41:56 UTC

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