Re: Meaning of audio track kind 'descriptions'

On Mon, Jun 20, 2011 at 10:47 PM, David Singer <singer@apple.com> wrote:
> I'd like to return to a general question of the client software and the user.  It seems we should enable the client software to expose the choices to the user (or match them against user preferences), and enable the client software to enable or disable the right tracks to get that effect -- ideally, without having special-purpose decisions based on the actual adaptation.  So if, for example, we introduce a new accessibility adaptation in future, old clients that don't recognize the keyword can still ask the user "do you want/need X?" and still 'do the right thing' with the content (in terms of enable/disable actions).
>
> So, here are two simple ways to achieve this.  I am sure there are others.  Both of these allow multiple tags in a 'kind' label.
>
> A) In the set of tags for a given track's kind, have either "+" or "-" before each tag.  "+X" means 'enable this track if the user wants X' and "-X" means 'disable this track if the user wants X.  Disables over-ride enables, that is, if a label says "+X -Y" and you want both X and Y, you disable the track.
>
> In both cases I think the labelling can be complete enough that the initial state is irrelevant - the labels and algorithm give a clear outcome for every track - but perhaps it could be said that the initial state has "main" tracks enabled and everything else disabled.
>
> [examples below]
>
> B) In the set of tags for a given track, say that the tag set "alternate X" means 'disable the main content of the same media type if you want X, and enable this track' and "X" means just 'enable this track if you want X'.
>
>
> Examples:
>
> 1) text captions as an add-on text track
>  A) the text track has kind="+captions" (or whatever the word is)
>  B) the text track has kind="captions"
>
> 2) burned-in captions in an alternative video track
>  A) the main video has kind="+main -captions" and the alternative video with captions has kind="+captions"
>  B) the main video has kind="main" and the alternative video has kind="alternative captions"
>
> 3) audio description as an add-on to the main audio - just like example 1.
>
> 4) audio description as a replacement to the main audio - just like example 2.
>
> 5) clean audio as an alternative to the main audio - just like example 2.
>
> 6) clean audio, where the main audio is delivered in two tracks - the dialog and the background music separately - and the background music is disabled for the user needing clean audio:
>  A) the two tracks say kind="main" and kind="main -cleanaudio"
>  B) ... I don't see how to express this.
>
> 7) Repetitive stimulus avoidance as an alternative - just like example 2.
>
> 8) Repetitive stimulus avoidance as an overlay (e.g. a black square in front of the flashing light) - just like example 1.
>
>
>
> I really don't like the case where you have to recognize that a kind of "Q", when wanted, implicitly means disable the main content of the same media type, whereas "R" doesn't.
>
> Nor am I crazy about this implicit matching over media type - there are people (especially in asia) that use alpha-coded images (aka a video track) to deliver captions on occasion, for example.
>
>
> Why is it hard to come up with a simple scheme to enable the client software to get out of the business of being *required* to understand the labels?

What you are proposing above *is* hard: it takes the complexity of
announcing what is available in a track one step further towards a
language of how to compose tracks together. I really think that is
over-engineering for the 10% use case.


The way I look at things is that the most optimal content is delivered
in tracks that are always additions to the main track and can be
turned on/off. Anything that is not an addition is legacy content and
should not get special treatment so as to discourage it. There are
always means to deal with such content in JavaScript anyway and we
have the capture-all phrase of "alternate" for such content.

Cheers,
Silvia.

Received on Tuesday, 21 June 2011 02:13:53 UTC