RE: Meaning of audio track kind 'descriptions'

The use case today in cable is descriptive video service where the description and main dialogue are pre-mixed and delivered as a single channel. The single channel is preferred because the majority of video receivers (set-top-boxes and TVs) do not have the capability to mix audio. There are emerging regulatory requirements to provide descriptive video service (audio descriptions) so in the short term the single channel approach might be more prevalent. Related to this is a desire by content owners to not have to re-author content to deliver it on the Web.

If pre-mixed description and dialogue is identified as @kind = alternative then there will need to be a way to distinguish it from other types of alternative audio. @label could be used but then it will be desirable to have some definition of @label string semantics so clients know how to interpret them.

Bob

> -----Original Message-----
> From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com]
> Sent: Wednesday, June 15, 2011 10:56 PM
> To: Mark Watson
> Cc: Bob Lund; HTML Accessibility Task Force
> Subject: Re: Meaning of audio track kind 'descriptions'
> 
> Note that I haven't yet seen a use case that absolutely requires us to
> know if a track is additional or alternative. If we do, we can always
> use a data-* attribute for this right now. If we see the data-*
> attribute being required to solve use cases, then we can ask for the
> introduction of an additional marker.
> 
> Bob: what was your use case?
> 
> Cheers,
> Silvia.
> 
> On Thu, Jun 16, 2011 at 2:53 PM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
> > On Thu, Jun 16, 2011 at 1:07 PM, Mark Watson <watsonm@netflix.com>
> wrote:
> >> I had a different understanding.
> >>
> >> We keep coming back to these cases where we can imagine both
> "alternative" and "additional" tracks as solutions to some problem.
> >>
> >> I've argued at length before that it doesn't work to have a blanket
> mechanism whereby any track can be labeled as either "alternative" or
> "additional" - and indeed we have no such mechanism: it's implicit in
> the track kind - you need to understand the kind to know whether it is
> alternative or additional.
> >>
> >> I actually thought that all our audio kinds were alternatives. I'm no
> expect, but I would guess that it's hard to create a descriptions track
> which can be freely mixed with the original audio.
> >
> >
> > I've done so before. It's not hard at all. You listen to the original
> > track and you speak into the microphone. It is easier to record it in
> > this way because the quality of the original audio doesn't degrade. It
> > is also the way in which for example the jwplayer works:
> > http://www.longtailvideo.com/support/addons/audio-description/15136/au
> > dio-description-reference-guide
> > .
> >
> > It would be bad if you have to mix in the original audio because that
> > both degrades the quality of that track, increases the required
> > bandwidth (because compressed silence is smaller than compressed
> > sound), requires re-recording the original content (which might end up
> > in copyright trouble), and requires switching between tracks rather
> > than just adding and removing a track. Switching between tracks will
> > be a lot more perceptible than adding/removing a second track.
> >
> > So, I can only see advantages to having an audio description provided
> > as a separate track.
> >
> >
> >> If both kinds exists (alternative descriptions and additive
> descriptions), then we need two kind values. Given that it's an
> accessibility requirement it would be nice for it to be explicit, so I
> would expect to have two "descriptions" kinds e.g. descriptions-add and
> descriptions-alt.
> >
> > I've only ever seen audio descriptions that come as separate tracks.
> > In the TV case you would have had to mix it for transmission because
> > there was only one channel available for transmission, but I believe
> > that is the artificial case. The more natural case is to have them
> > separate.
> >
> >
> > Cheers,
> > Silvia.
> >

Received on Thursday, 16 June 2011 14:50:03 UTC