- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 10 Jun 2010 12:03:55 +1000
On Thu, Jun 10, 2010 at 11:55 AM, Ashley Sheridan <ash at ashleysheridan.co.uk>wrote: > On Thu, 2010-06-10 at 11:52 +1000, Silvia Pfeiffer wrote: > > I don't think that is possible in the way that the volume attribute is > currently defined as a value between [0;1]. That is an orthogonal, but > still important question about the volume attribute then. > > So, if you say 300%, I assume you mean 3 times louder than what the > track is given as? I do wonder how to do that with the current volume > attribute - right now the spec says that the default value set is 1.0 > [1]. It seems that means we cannot amplify a quiet audio track but > have to rely on the user to turn up the volume on their computer? I > would actually prefer if the default setting was something like 0.5 > and we could then turn the volume up or down in javascript or > preferably event through a content attribute as mentioned. > > Cheers, > Silvia. > > [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-volume > > > On Thu, Jun 10, 2010 at 10:05 AM, Kevin Marks <kevinmarks at gmail.com> wrote: > > Setting volume above 1.0 can be very useful if the original is too quiet. > > For example, Quicktime allows a volume of 300% to amplify quiet tracks > > > > On May 31, 2010 11:30 PM, "Philip J?genstedt" <philipj at opera.com> wrote: > > > > On Tue, 01 Jun 2010 14:17:03 +0800, Silvia Pfeiffer > > <silviapfeiffer1 at gmail.com> wrote: > > > >> On Tue, Ju... > > > > This would make volume even more special, as a float that reflects as an > > integer percentage. Just using the existing definition for reflecting a > > float would be simpler. > > > >>> So, I am neither in favor or against of reflecting volume and mute as > >>> content attributes. Im... > > > > I'd be fine with reflecting muted if many people think it would be useful. > > I'm not the one to make that judgment though. > > > > Volume isn't a huge problem, just not as trivial as one might suspect. > > Another thing to consider is that it is currently impossible to set volume > > to a value outside the range [0,1] via the DOM API. With a content > > attribute, volume="-1" and volume="1.1" would need to be handled too. I'd > > prefer it being ignored rather than being clamped. > > > >>> [1] > >>> > >>> http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#reflect > >> > >> > >> > >> Ch... > > > > -- > > Philip J?genstedt > > Core Developer > > Opera Software > > > Or you could just raise the volume of the audio track itself. I think being > able to raise the volume like this (beyond 100% of what it is) with script > just makes it something more likely to be abused (think how the TV adverts > always seem twice as loud as the programs they surround) and so will end up > getting blocked more often. > > That requires editing the resource. Think about it from a process point-of-view: you're a Web developer and have been given a set of media resources to put on a Website. As you put it all together, you notice that the volume of the different files is different and thus playing them back next to each other will create a very confusing user experience. Do you really want to shoot the files back to the production to adjust the volume settings so they are all similar? If you're under time pressure, you'd probably much prefer just setting a volume attribute on each so they all play back with the same level. Your example of TV ads being louder than the rest of the program is indeed a production issue but would not replicable through a volume setting for the resource, since that volume applies to the whole resource and not just to the ad clip inside it. I don't think that kind of abuse would originate from JavaScript - it already originates from production and doesn't really apply to this issue. Cheers, Silvia. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100610/536c1c9f/attachment-0001.htm>
Received on Wednesday, 9 June 2010 19:03:55 UTC