Re: [Bug 21550] New: PannerNode - include informative note on HRTF, point to reference/open examples

On Wed, Apr 17, 2013 at 4:42 AM, Chris Pike <chris.pike@bbc.co.uk> wrote:

> On 4 Apr 2013, at 18:49, Chris Rogers <crogers@google.com> wrote:
>
> On Thu, Apr 4, 2013 at 3:28 AM, Robert O'Callahan <robert@ocallahan.org>
>  wrote:
>
>> On Thu, Apr 4, 2013 at 10:22 PM, Chris Lowis <chris.lowis@bbc.co.uk>
>>  wrote:
>>
>>> My thinking here was that there's a couple of nodes in the spec that are
>>> perhaps hard to specify mathematically (the compressor node, for
>>> example) and that even if we could, my preference leans towards
>>> attempting to specify the intended effect while leaving implementations
>>> to compete in terms of performance or sound quality. Is that even a
>>> desirable goal?
>>>
>>
>> I think allowing browsers to compete on quality is fine if authors always
>> agree on which outputs are higher quality, i.e. that for given outputs A
>> and B either everyone agrees that A is at least as good as B, or everyone
>> agrees that B is at least as good as A, and everyone understands that both
>> A and B are acceptable outputs according to the spec, and the difference in
>> output is not so large that authors don't trust it.
>>
>> I worry that this won't be the case for competing HRTF models. I don't
>> know enough about HRTF but isn't it the case that different developers
>> favour different models?
>>
>
> This is a valid concern.  For these types of effects (HRTF spatialization,
> dynamics compression) people are not always in agreement about the best
> sound quality.  At the extremes, for very bad and very good sounding
> algorithms most people may agree.
>
> I'm not sure if I understand the point around authors agreeing on which
> outputs are higher quality. Are you able to provide an example in terms of
> dynamic range compression? To my mind the nature of competition would be in
> trying to improve quality using novel techniques or fine tuning, rather
> than text-book methods.
>

Since this discussion has gotten a little confusing I just thought I'd
clarify my opinion:
1) I'm neutral on whether or not we standardize an exact HRTF data-set for
the default - same goes with the exact compressor algorithm.  I actually
have a slight preference for *not* requiring exact algorithms in these
cases because of your points.
2) Authors do *not* always agree on quality issues.  Given two HRTF
datasets, it's not always clear which one is better since different people
hear them differently.  For compressors, people favor different styles and
sound qualities and many companies compete in the market for hardware racks
and plugin effects (VST, AU, etc.).  So there's no "universal" agreement on
these things.




>
> In the case of the HRTF setting for the Panner node my preference would
>>> be:
>>>
>>> - allow developers to load their own HRTF into the Node[1]
>>> - word the spec such that an implementation MAY provide a default HRTF
>>>   set, and if they do,
>>>
>>
> I believe the implementation must implement a default HRTF set.
>  Otherwise, the PannerNode will not "just work" out of the box.
>
>
>> - it SHOULD be derived from the IRCAM set that Webkit have used up to
>>>   this point.
>>>
>>
>> I don't think we should allow implementations to vary based on whether an
>> HRTF set is provided. Either all should or none should, and since Webkit
>> does, that means all should.
>>
>> Letting authors supply their own HRTF sounds great but it could wait for
>> a later iteration of the spec I think.
>>
>
> Seems reasonable for the current spec.  But, I hope that people like the
> BBC can start some early work on what a reasonable API might look like,
> along with some prototype implementation.
>
> I agree that allowing developers to load their own HRTF into the Node
> would be a nice feature at some point. However I also agree that it can
> wait for a later iteration of the spec, as currently I expect it would not
> get much use. Things may change in the future.
> I think all implementations should provide an HRTF set with the
> PannerNode. But in my opinion this should not be fixed to a particular set
> e.g. the IRCAM LISTEN derived set in the WebKit implementation. Allowing
> different implementations to decide the HRTF set that they provide gives
> room for competition over sound quality. Informative notes could be
> provided in the spec so that implementers who are not particularly
> concerned with this feature can be directed to the IRCAM sets. Or the set
> used in WebKit could be made available as an example.
>

That seems reasonable.


> Best regards,
> Chris
>
>
> http://www.bbc.co.uk
>
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>