Re: Meaning of audio track kind 'descriptions'

On Jun 21, 2011, at 10:58 AM, Silvia Pfeiffer wrote:

On Tue, Jun 21, 2011 at 5:58 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:

On Jun 21, 2011, at 4:13 AM, Silvia Pfeiffer wrote:

On Mon, Jun 20, 2011 at 10:47 PM, David Singer <singer@apple.com<mailto:singer@apple.com>> wrote:

<snip>



Furthermore, even for the cases where delivering the track as an addition is likely to be common (e.g. descriptions or commentary), professional content authors are able to do a better job of ducking/modifying the original audio than the client will. There are audio formats which include instructions for mixing the tracks, in which case the descriptions/commentary can still be delivered as an additional stream with these detailed mixing instructions, but this still implies that there is no change to the audio mixing *within* the original audio (e.g. changing relative volume of dialog vs music).


See other email - I disagree that professional mixing is always better
at ducking than user-controlled.

I think this is a matter of opinion and eventually gets resolved through feedback from real users. I doubt *users* want to continuously adjust the relative volume of the tracks, so we're talking about automatic client capabilities, perhaps based on user preference settings, which do the ducking. But still these have only one degree of freedom (relative volume of the two tracks), whereas the content creator has many (relative volume of the many source tracks).

So I think it's equally unlikely that client-side ducking is always better than professional mixing.



This is not a "legacy" concern - authors may still want to construct a descriptions or commentary as an alternative track.

That's what the "alternative" label is for.

Again, I think it's unacceptable there could be a descriptions track which doesn't get enabled even if I have "auto-enable descriptions" in my preferences. And it's a bad user experience if descriptions sometimes appear under the "enable descriptions" option and sometimes just as "Audio alternative 1".



There are
always means to deal with such content in JavaScript anyway and we
have the capture-all phrase of "alternate" for such content.

We should always ensure that tracks provided for accessibility purposes are marked with their specific accessibility purpose (e.g. descriptions) for the reasons discussed in another mail. Otherwise we make these tracks more difficult to use when the exact purpose of the track is to make the service easier (or even just possible) to use for some people.

During a transition phase, we can probably do something like
kind="main+descriptions" as a marker for what the track provides. I
would be open for this, though I believe that we really need
implementation experience first before we should make any more changes
to those parts of the specification.

So this is fine and can be applied as a general principle - tracks can have multiple kinds with the rule that you should not enable multiple tracks containing the same kind (i.e. don't enable both "main" and "main+descriptions"). This answers the example in your other mail too.

Regarding implementation experience, we do have experience with these kind of description tracks, exposed as explicitly marked alternative description track to the Javascript UI, so they do exist.

I think it's reasonable to use the existence of a non-negligable amount of source material as a criteria for including a kind for that in HTML <video>: we need to include the it so that people can experiment with it and we can gain the implementation experience we need.

...Mark


Cheers,le
Silvia.