- From: Karl Tomlinson <karlt+public-audio@karlt.net>
- Date: Tue, 04 Feb 2014 15:46:45 +1300
- To: Olivier Thereaux <olivier.thereaux@bbc.co.uk>
- Cc: Audio WG <public-audio@w3.org>, Chris Wilson <cwilso@google.com>, Paul Adenot <padenot@mozilla.com>
> On 16 Jan 2014, at 20:01, Chris Wilson <cwilso@google.com> wrote: > >> I also raised the dynamics compressor issue I'd introduced in email >> (http://lists.w3.org/Archives/Public/public-audio/2014JanMar/0010.html). >> I'd like to specifically propose that we remove the pre-emphasis and >> post-emphasis in the dynamics compressor; either way, we need to document >> how dynamicscompressor works, but removing pre- and post-emphasis rather >> than just documenting it makes it easier to implement multi-band compression >> based on the dynamicscompressor. >> >> Jer expressed that he'd be okay with this; I'd like to hear feedback from >> the Mozilla contingent, as they implemented the same pre/post emphasis >> Webkit/Blink did. On Fri, 31 Jan 2014 11:43:57 +0000, Olivier Thereaux wrote: > Although the proposed resolution would involve no change to the spec (but > change to implementations) I’d like to keep track of the decision and how we > got to it - might be worth creating a test for it too, since this is something > we know has been implemented in ways non-compliant with the spec. > > In effect, this is a call for consensus on the proposal to remove emphasis > from implementations rather than document it in the spec. Silence will mean > consent and I aim to record consensus at our next teleconference, in a week. Removing the emphasis from the implementations sounds reasonable to me. If there were people jumping in with existing use cases requiring pre-emphasis then perhaps we could consider alternative solutions. However, I don't know of any, and Chris has a use case where emphasis is a problem. The lack of any requirement in the spec gives us the freedom to choose to remove the emphasis from implementations. If a need does arise for emphasis one day, I think I'd like to see this addressed through supporting sidechain compression, so there is no need to invert the emphasis. Perhaps this could be provided through an optional additional DynamicsCompressorNode input, which would also give the client the opportunity to select the desired pre-delay through a DelayNode.
Received on Tuesday, 4 February 2014 02:47:36 UTC