Re: Meaning of audio track kind 'descriptions'

On Mon, Jun 20, 2011 at 9:09 PM, Mark Watson <watsonm@netflix.com> wrote:
>
> On Jun 20, 2011, at 11:19 AM, Silvia Pfeiffer wrote:
>
>> On Mon, Jun 20, 2011 at 6:55 PM, Mark Watson <watsonm@netflix.com> wrote:
>>> Is it not the case than when authoring audio descriptions you might want to make decisions to attenuate part of the main audio track to make the descriptions more audible ?
>>>
>>> That would be a reason other than legacy technical restrictions for creating "alternative" audio descriptions tracks.
>>
>> You can do ducking better when you have separate tracks and the
>> ducking can then even be controlled by the user. That's a much better
>> experience than a premixed audio track.
>
> Always ? Surely the professionals who created the content are better at creating a new mix which keeps the most important audio elements and ducks the less important ones. Where "important" is even defined as artistic importance ?


If that was the case, I'd never have a problem understanding speech in
movies, since it was mixed by professionals. A premix is always doomed
to be less useful than a flexible mix, which I can tune to my own
requirements.


>>> Silvia: I didn't understand you comment of not seeing a need to distinguish between alternative and additional tracks: surely I need to know this so that I know whether to enable this track in addition to the main track or instead of the main track.
>>
>> Who is enabling the audio track? Surely the user is enabling the audio
>> track! So, when the user selects the track that has a label of "audio
>> with descriptions" (and a kind="alternate"), the browser knows to turn
>> off the main audio. I don't see a problem with this.
>
> Two things:
> - I'd like the user to be able to enable this track through preferences - ticking the "play descriptions by default" button
> - I'd like this track to appear on the same accessibility menu, or under the same accessibility keyboard shortcuts as kind="descriptions" tracks. The user does not care how the descriptions were delivered and doesn't want to see these tracks on different menus etc. based on how they are labeled.


If we regard the situation where audio descriptions are delivered as
pre-mixed as the legacy use case, it probably makes not much sense to
make an explicit solution for this case. We could announce it as a
kind="main+descriptions" , but I'm not convinced that is helpful.


The way I look at the "kind" declaration is that in general we should
keep additional features separate from the main content and allow the
user the flexibility to bring in tracks as needed. Anything that is
premixed should be regarded as a legacy content (e.g. burnt-in
captions, e.g.pre-mixed audio descriptions, e.g. burnt-in sign
language) and should not be given special treatment such as to
discourage people from creating such legacy and inflexibly content.


>>> It seems like we have use-cases for both alternative and additional audio descriptions. I think the track should be explicitly marked as descriptions in both cases, so we can apply user preferences, include it in the right menu etc.
>>
>>
>> Browser settings for user preferences may be a case where we could do
>> with an explicit marker on an alternate descriptions track. For
>> including it in a menu we don't need it - all we need is a label that
>> is explicit enough for the user to choose it, as described above.
>
> No, because the machine can't understand the label. I imagine keyboard shortcuts or other selection mechanisms are useful for people who can't see well.
>
> If it's useful to mark an additive "descriptions" track as such in a machine-readable way then it is also useful to label a alternative "descriptions" track as such. Why does the delivery mechanism affect the utility of the kind marking ?


Starting to explain what is contained in pre-mixed tracks and making
them all equivalent to singular tracks is a slippery slope to take.
What if you have a video that has an alternative video track with
main+captions burnt in and an alternative video track with
main+captions+sign language video burnt in and a text track with
captions. What does your shortcut to turn on captions select?


>>> So, how should be distinguish the two cases ? We could have two kind values or use data-*as Silvia suggested (Silvia, could you explain how that works ?).
>>
>> A Web developer can add a data-* attribute on any element. It's like
>> inventing your own attribute. The Web developer has access to this
>> attribute through the JS interface and can do everything with it that
>> you can do with attributes. It's very handy for things that are a
>> specialized use case.
>
> Sounds like it wouldn't help for in-band tracks, though.

I think we are trying to over-engineer a solution for problems that we
haven't even come across yet. Let's wait and see once all the track
APIs are implemented what real issues we come across.

Regards,
Silvia.

Received on Tuesday, 21 June 2011 08:55:05 UTC