Re: De-zippering

+ anybody that has a little bit experience in handling audio knows about
this problem.


2013/11/7 s p <sebpiq@gmail.com>

> What about if you want - on purpose - to create a pop by brutally changing
> a gain value? I have used his technique to do some glitch-like percussions,
> or sound effects like vinyl crackling sound.
>
> + that has a little bit experience in handling audio knows about this
> problem.
>
>
> 2013/11/7 Chris Wilson <cwilso@google.com>
>
>> Chris (Rogers)' reasoning behind implementing this way to begin with was
>> that most users simply don't know about this at all.
>>
>> My personal feeling on this is that there are some scenarios that
>> automatically applying dezippering on makes sense, and some it does not.
>>  For example, it would make sense to dezipper volume control; however, it
>> does not make sense to dezipper frequency control.  This leads me to think
>> that it might be good to apply to gain.gain.value, but not to
>> oscillator.frequency.value, for example.
>>
>>
>> On Thu, Nov 7, 2013 at 3:51 AM, Marcus Geelnard <mage@opera.com> wrote:
>>
>>> 2013-11-07 12:23, Chris Lowis skrev:
>>>
>>>  Hi!
>>>>
>>>> There's a task for me to look into how "dezippering" is performed in
>>>> Webkit and to explain how and why we do it.
>>>>
>>>> I've put together a quick demo to show the effect of dezippering
>>>>
>>>> http://blog.chrislowis.co.uk/demos/dezippering/
>>>>
>>>> And made some notes on how it is implemented on this ticket:
>>>>
>>>> https://github.com/WebAudio/web-audio-api/issues/76
>>>>
>>>> I think it's open for debate whether we clarify dezippering (I think
>>>> I'd prefer to use the term "parameter smoothing") in the spec, and all
>>>> of the parameters to which it applies by default, or whether we move
>>>> to remove mention of it altogether and perhaps add an advisory note
>>>> about preventing glitches by using exponentialRampToValueAtTime() for
>>>> example.
>>>>
>>>> For that reason, I haven't prepared a PR. Perhaps we can discuss it
>>>> here first and I can prepare one later.
>>>>
>>>
>>> In general I prefer not to have too much magic going on behind the
>>> scenes.
>>>
>>> The automatic smoothing (dezippering) in Web Audio reminds me of when
>>> progress bar smoothing logic was added to Windows Vista. In an attempt to
>>> create a more pleasant experience for the user, the new implementation left
>>> developers unable to control the progress bar the way they wanted to [1]
>>> (e.g. reaching 100% progress was almost impossible without fooling the API
>>> by utilizing known quirks in the underlying progress bar smoothing
>>> implementation).
>>>
>>> Let's not repeat that mistake. Unless there are strong use cases for
>>> automatic parameter smoothing that can not be handled using explicit
>>> interfaces, I'd prefer dropping it in favor of explicit interfaces.
>>>
>>> /Marcus
>>>
>>>
>>>
>>> [1] http://stackoverflow.com/questions/1061715/how-do-i-
>>> make-tprogressbar-stop-lagging
>>>
>>>
>>>
>>>> Cheers,
>>>>
>>>> Chris
>>>>
>>>>
>>>
>>> --
>>> Marcus Geelnard
>>> Technical Lead, Mobile Infrastructure
>>> Opera Software
>>>
>>>
>>>
>>
>
>
> --
>
> *Sébastien Piquemal*
>
>  -----* @sebpiq*
>  ----- http://github.com/sebpiq
>  ----- http://funktion.fm
>



-- 

*Sébastien Piquemal*

 -----* @sebpiq*
 ----- http://github.com/sebpiq
 ----- http://funktion.fm

Received on Thursday, 7 November 2013 18:31:33 UTC