Re: ACTION-238 Revise guidelines 4.9.6

A couple of things to maybe think about. Is there a technical downside 
to wider versus narrower percentages, for instance 33-300% versus 25-400%?

Second, if there's no downside, should guidelines like these be wide 
enough to make sure to cover any possible situations, maybe even with a 
discernible margin because sometimes when people have a tool that goes 
further they use it? It's not uncommon for people who create technology 
to be surprised at how far experienced users can push it when the 
technology allows them to. The speed of some folks who use a single 
switch to control the computer using scanning software comes to mind.

Cheers,
Kim

Markku Hakkinen wrote:
> Hi Jan,
>
> Yes, they do need to be normalized (and then resolve precision, 33.3%,
> if going with percentages).
>
> I put this out as a first pass at redrafting 4.9.6 to address both
> media slow down and speed up.  Discussion needed.
>
> What I am lacking is empirical data to back the upper and lower limits
> for both speech and visual, and I am a hesitant to cast these numbers
> in stone (even when drawn from other standards, e.g., talking books)
> without being able to point to specific data saying why these numbers
> are optimal (de facto recommendations?).
>
> There is empirical data suggesting that speed up and slow down have
> benefit, but what I don't have is data saying what rates are ideal.
>
> I'll add that the software algorithms for time scale modification used
> by both Windows Media Player and Quicktime player currently support
> the desired range (though the quality of the original encoding may
> affect perceived quality at the high and low ends of the range).   The
> question remains, what should that range really be?
>
> br,
> mark
>
> On Wed, Nov 18, 2009 at 2:22 PM, Jan Richards <jan.richards@utoronto.ca> wrote:
>   
>> Hi Mark,
>>
>> I think we could be more consistent in the way these are stated. In one case
>> we say "1/3 to 3 times" implying 33%-300% and in another we say at least one
>> setting between 40% and 60% which implies a lowest setting of 60% would be
>> ok.
>>
>> Cheers,
>> Jan
>>
>>
>> Markku Hakkinen wrote:
>>     
>>> 4.9.6 Playback Rate Adjustment for Multimedia Content.
>>>
>>> The user can adjust playback rate of prerecorded content containing
>>> speech audio tracks such that all of the following are true (Level A):
>>>
>>> -  The playback rate should be user adjustable between 1/3 and 3 times
>>> real time of the recorded content.
>>>
>>> -  Recorded speech, whose playback rate has been adjusted by the user,
>>> should utilize pitch maintenance in order to avoid degradation of the
>>> speech quality.
>>>
>>> If only a visual track is present, provide at least one setting
>>> between 40% and 60% of the original speed. (Level A)
>>>
>>> When audio and video tracks are expected to be synchronized,
>>> synchronization is maintained as long as they are played at 75% of the
>>> original speed or higher. (Level A)
>>>
>>> The UA should provide a function that resets the playback rate to
>>> normal (1x) . (Level A)
>>>
>>>       
>> --
>> Jan Richards, M.Sc.
>> User Interface Design Lead
>> Adaptive Technology Resource Centre (ATRC)
>> Faculty of Information
>> University of Toronto
>>
>>  Email: jan.richards@utoronto.ca
>>  Web:   http://jan.atrc.utoronto.ca
>>  Phone: 416-946-7060
>>  Fax:   416-971-2896
>>
>>
>>
>>     
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com 
>> Version: 8.5.425 / Virus Database: 270.14.72/2511 - Release Date: 11/18/09 07:50:00
>>
>>     


-- 
___________________________________________________

Kimberly Patch
President
Redstart Systems, Inc., makers of Utter Command
(617) 325-3966
kim@redstartsystems.com

www.redstartsystems.com <http://www.redstartsystems.com>
- making speech fly

Patch on Speech <http://www.redstartsystems.com/blog/> blog
Redstart Systems <http://twitter.com/RedstartSystems> on Twitter
___________________________________________________

Received on Wednesday, 18 November 2009 22:18:03 UTC