W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > December 2012

[Bug 20327] Continuous splice flag

From: <bugzilla@jessica.w3.org>
Date: Mon, 10 Dec 2012 20:59:52 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-20327-2486-FRH2uyuH0W@http.www.w3.org/Bugs/Public/>

--- Comment #3 from Aaron Colwell <acolwell@chromium.org> ---
(In reply to comment #2)
> Right. This is not about avoiding taxing UA resources, but rather giving a
> chance to the UA to avoid audible artifacts at splice points unless
> necessary -- the UA can always ignore the flag.
> When processing audio splices in the baseband domain (whether from native
> baseband signals or obtained from coded signals), the UA will need to
> introduce a fade of some sort (which can be audible if there is energy)
> unless it is told that the audio signal is identical on each side of the
> splice.
> The purpose of the continuousSplice flag would be to signal to the UA that
> the audio signal is identical on each side of the splice. The UA could try
> to determine on its own whether the signals are identical, but then we would
> need to define what "identical" means.

I don't understand. If the audio is identical then how would the fade be
audible? I'm assuming the fade would be something like out[i] = a * frame1[i] +
(1-a) * frame2[i]. If these two frames contain the same data then I don't think
this would be audible. If there is any sort of level shift, difference in
quantization or something similar, I would think that you'd want the fade there
to make the transition less jarring.

Can you please provide a concrete use case where this would be used and how the
current spec would lead to an unacceptable experience.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Monday, 10 December 2012 20:59:56 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:36 UTC