Re: [css3-speech] voice-volume

Let's reset the 'voice-volume' discussion <rolleyes>...I was referring  
to the SSML 1.0 but SSML 1.1 changed the definition quite a bit (and  
introduced support for dB relative changes). I clicked on the SSML  
reference in the CSS-Speech draft but forgot that it is outdated. My  
bad. I'll re-write the definition and will commit the changes probably  
in the next few hours. Dan

http://www.w3.org/TR/speech-synthesis/#edef_prosody

http://www.w3.org/TR/speech-synthesis11/#edef_prosody

http://www.w3.org/TR/CSS21/aural.html#volume-props

On 11 May 2011, at 18:18, fantasai wrote:

> On 05/10/2011 11:50 PM, Daniel Weck wrote:
>>
>> On 11 May 2011, at 04:23, fantasai wrote:
>>> I think 'linear' is somewhat misleading, since the normal
>>> 0-100 scale /could/ be linear. (I think 'absolute' would be a  
>>> better keyword
>>> because 'absolute 0' is absolutely silent, but I'm open to  
>>> suggestions.)
>>
>> The 'relative' keyword is used somewhere else, with a totally  
>> different
>> meaning (e.g. the syntax "+5" can denote an absolute value, but it  
>> may
>> also express a relative change based on another; usually-inherited;  
>> value).
>
> I don't understand why the 'relative' keyword elsewhere prevents us  
> from
> using 'absolute' here?
>
>>> x-soft
>>> The minimum audible level. Equivalent to '0'.
>>> soft
>>> Equivalent to '25'.
>>> medium
>>> The listener's preferred volume level. Equivalent to '50'.
>>> loud
>>> Equivalent to '75'.
>>> x-loud
>>> The maximum tolerable level. Equivalent to '100'.
>>
>> 'x-soft' must correspond to 'silent' when expressed on the "linear"  
>> scale,
>> so your suggestion doesn't work.
>
> I don't think 'linear' should be combinable with the keywords. It does
> not afford the author any extra capability, and it confuses the  
> meaning
> of the keywords.
>
>> To be compatible with SSML, we need to allow the 'linear' keyword  
>> with
>> named values as well (I must update the draft, actually).
>
> I don't see where SSML uses an option to redefine its keyword values
> to fall on a linear scale such that x-soft is equal to silent.
>
>> The way I see it, the 5 enumerated values are "shortcuts" to the 5  
>> defined points on the numerical scale, so I prefer to
>> define the actual meaning of the values (which depends on the  
>> 'linear' keyword) in the <number> section only.
>
> Ah, see, I disagree. The keywords are defining which points of the  
> scale
> correspond to what actual volumes. The scale is nonlinear because of  
> those
> anchor points. We're defining 50 to be the preferred volume / 
> because/ it
> is mapped to the 'medium' keyword, not the other way around.
>
>>> linear
>>> When present, the 'linear' keyword indicates that the <number>  
>>> represents
>>> a value on the linear volume scale between 'silent' and 'x-loud'.
>>
>> That's not true, it is still the range 'x-soft' to 'x-loud', but 'x- 
>> soft' now means "silent" :)
>> (as per my other remarks above)
>
> I disagree with those remarks. :)
>
>> http://www.w3.org/TR/CSS21/aural.html#propdef-volume
>>
>> Could you please point to a CSS 2 property definition that  
>> exemplifies good editorial practice? Thanks.
>
> Like the propdef-volume link you have there?
>
>> The "relative" keyword is mandatory for pitch values expressed in  
>> Hz or semitone units. Would you advice to break down
>> <relative-change> into separate fields, and to allow the keyword on  
>> either left or right of the actual numerical value ?
>>
>> http://dev.w3.org/csswg/css3-speech/#voice-pitch
>
> Yes.
>
>>> For cues, do we really need 'silent'? Why wouldn't the author just  
>>> remove the
>>> cue, replacing with a rest if necessary?
>>
>> User stylesheets must be able to silence audio cues with "! 
>> important" rules. I agree that the use-case is limited (one would
>> normally specify "none" to completely remove a cue), but we need to  
>> be consistent with voice volume.
>
> I'm not convinced of this use case. Do we really have users who would
> rather silence a cue than remove it?
>
> ~fantasai

Daniel Weck
daniel.weck@gmail.com

Received on Wednesday, 11 May 2011 17:32:19 UTC