- From: Kim Patch <kim@redstartsystems.com>
- Date: Wed, 18 Nov 2009 17:16:47 -0500
- To: Markku Hakkinen <markku.hakkinen@gmail.com>
- CC: Jan Richards <jan.richards@utoronto.ca>, UAWG list <w3c-wai-ua@w3.org>
- Message-ID: <4B04724F.1010509@redstartsystems.com>
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