Re: Audio

On Sun, 8 Aug 2004 13:02:33 +0100 (BST), Dave Raggett <dsr@w3.org> wrote:

> The "sound-salad" idea of overlapping sounds is a bit like the sound
> environment in the natural world. Your ears are exposed to lots of
> different sounds overlaying each other - some people talking, a
> passing car, a sea gull flying overhead, the sound of the wind,
> people's footsteps and so on.
>
> Sound effects for web pages can be effective or a jarring cacophany,
> authors will learn what works, or users will turn away from their
> pages. In this view sounds should be mixed rather than serialized.

I see you are here opening a completely new perspective on what we have  
until now called the 'speech' media type: an 'audio' media type that would  
somehow give the chance to designers to 'compose' their page the way they  
would compose a musical piece.

But you are suggesting an aleatory 'multiphony' that seems to draw  
inspiration from natural sounds, and from sounds of our everyday's  
environment. Now this is a fascinating approach, but I am sure not every  
'web composer' (as opposed to web designer) would love this approach -  
some might need a very clear placing of sounds on the page (i.e. in the  
time frame), would need, in other words, serialzation rather than mixing;  
or, even better, serialization *and* mixing, which traditionally goes  
under the term of 'polyphony'.

"Sound-salads" that are well-balanced, that are not cacophonies, might be  
one aspect, neat and clear serialization might be another aspect.

I have the impression that the field which needs some attention is the  
interaction between the visual and the aural canvases - until now CSS has  
been built as almost only visual, and the somehow marginal 'aural' has  
developped into an autonomous 'speech' - I am looking forward to 'audio'.

CSS3 Speech does not address the interaction between the aural and the  
visual canvases; the media type 'reader' has been proposed as one such  
means, but IMHO it would not be an indeal solution, as it represents too  
many use cases to fit them into one definition (screen+speech,  
handheld+speech, projection+speech, etc...) - and the author would need to  
include lots of redundant coding, would have to copy all information of  
'screen' and 'speech' into 'reader', as 'reader' explicitly is exclusive.

The 'speech' media type has addressed solely the spoken words, with some  
minimal audio icons ('cue') - in any case, 'speech' is a serilaized media  
type with one dimension only, the time flow - with the one exception that  
the user can also jump back, and play (read) the paragraphs in inversed  
order, can play one paragraph repeatedly, etc.

A possible 'audio' media type, on the other hand, could be a collector for  
all audio events on a web page - addressing thus not only the pure aural  
enjoyment of the document, but also the visual experience enriched by some  
audio events. As such, IMHO, the 'audio' media type represents the ideal  
crosspoint between visual and aural, and could be the missing link between  
'speech' and any of the visual CSS.

The 'audio' media type thus IMHO needs:

1. 'background-sound':
1.1. 'background-sound-source': <uri> | none | inherit
1.2. 'background-sound-loop': loop [<number>] | inherit
1.3. 'background-sound-balance': takes values from 'voice-balance'
1.4. 'background-sound-volume': takes values from 'voice-volume'
1.5. 'background-sound-clip': cue | "padding" (still no property name for  
this: it is the aural padding between cue and the element)
1.6. 'background-sound-offset': <time> in ms (milliseconds) or s (seconds)  
after the state it should play becomes true
1.7. 'background-sound-duration': takes values from 'voice-duration'
If 'background-sound' seems to be verbose, you could use 'backsound'. One  
more entry needed as a shorthand.

2. 'audio'
2.1. 'audio-balance'
2.2. 'audio-volume'
2.3. 'audio-loop': loop [<number>] | inherit
2.4. 'audio-duration': <time>
For embedded audio files (e.g. in OBJECTs)

3. 'volume': 'voice-volume' 'background-sound-volume' 'audio-volume'

4. 'balance': 'voice-balance' 'background-sound-balance' 'audio-balance'

5. a means for precise serialization of sounds.

> p.s. I think that :visible is addressing a different issue
> and has value in its own right.

:visible has the big problem that it mainly relies on the size of the  
screen.

Regards,
/c

-- 
[Quote]
And she, remembering other things, to me trifles but torturing to her,  
showed me how life withers when there are things we cannot share.
~~~ Virginia Woolf

Received on Monday, 9 August 2004 15:37:43 UTC