RE: (SSML prosody@duration / voice-duration:<time>) Comments from PFWG on CSS3 Speech Module

Thanks Paul!

paul.bagshaw@orange.com wrote:

The SSML:prosody@duration attribute is easily implemented by TTS systems (which have always had the ability to change the duration and fundamental frequency of an acoustic unit of speech). One typical use case of this attribute by SSML document author's is when synchronising multimedia data, such as audio commentaries with visual presentations (particularly videos).
An example is in dubbing an animated film (a single video sequence) with scripts from multiple languages. 

Regards,
Paul

-----Original Message-----
From: Daniel Weck [mailto:daniel.weck@gmail.com] 
Sent: Tuesday, October 18, 2011 8:41 AM
To: fantasai; Dan Burnett; www-voice@w3.org
Cc: Janina Sajka; www-style list; Bert Bos; List WAI Liaison; List WAI PF; BAGSHAW Paul RD-TECH-REN
Subject: Re: (SSML prosody@duration / voice-duration:<time>) Comments from PFWG on CSS3 Speech Module

I would love to hear whether SSML's prosody@duration is a commonly-used feature. Perhaps we are unaware of an obvious use-case? Aslo, were there any major challenges with speech synthesizers when this feature was implemented in voice browsers?
Regards, Daniel

On 18 Oct 2011, at 01:16, fantasai wrote:

> On 10/15/2011 02:23 AM, Daniel Weck wrote:
>> 
>> On 15 Oct 2011, at 02:35, fantasai wrote:
>>> Hm, I'd say, if there isn't a use case, and it seems likely to have
>>> implementation and/or usability issues, and nobody has expressed a
>>> desire to have it, then it seems fair to drop it until someone
>>> requests it. We can copy the spec prose from the LC into a later
>>> spec if it turns out it's needed. What do you think?
>> 
>> (CC Voice-Browser group)
>> 
>> I assumed that the "at-risk" status was the most appropriate device to ensure that unwanted features do not end-up cluttering the final specification. The 'voice-duration' property has been in the CSS Speech drafts for a very long time [1], and it corresponds to a "non-disputed" feature in SSML. I wonder if removing it at this stage of the design process is judicious. Wouldn't running the course "as normal" be equally effective? (i.e. CR references implementations, or lack thereof)
> 
> The at-risk status defers the decision of whether it stays in the standard
> to whether it will be implemented correctly or not. If we think a feature
> is not good to have, then we shouldn't include it even at-risk. Leaving
> it in the spec isn't entirely cost-free: it complicates the spec, and it
> encourages implementers to try implementing it. If we don't think it's useful,
> that's a waste of resources.