Sounds

The Web is alive with the sound of music! At least, many Web sites are, as they take advantage of features of some popular browsers that support embedded sounds. But do you really want to do this on your site?

TIP: As with so many "way-cool" enhancements to Web sites, embedded sounds are likely to be more of an annoyance and distraction than an enhancement. Think carefully about whether you really need to use them. A plain link to a sound file that a user can select if he wishes may be better.

Reasons to avoid using embedded sounds

• Many users find it annoying or distracting to have their eardrums assaulted with a sound when they enter a site.
• Some users may be accessing your site within earshot of other people trying to work, study, or sleep, who might not appreciate the interruption.
• An embedded sound stops playing when the user goes to a different Web page, even within your site, which could be annoying if the user wants to hear the rest of it. Some developers have dealt with this by putting the embedded sound in a frame, but the use of frames has many annoying aspects of its own. Sounds added as normal Web links will be brought up, in many browsers, in a separate window that can stay around when the user surfs on.
• Users with browsers not supporting embedded sounds won't be able to hear your sound at all, while they might have helper applications that could play the sound if you had it as an ordinary Web link. So you may be cutting off some of the audience that actually wants to hear it.
• If some of the links on the page are to sound files, the background sound may interfere with the linked-to sound if it starts playing (in a pop-up window as many browsers do sound links) while the background sound is still going.

So, all things considered, it's probably better to use the less-"kewl", but more-functional alternative of providing a simple old-fashioned link to your sound files. This not only lets your sounds be heard by the people who want to hear them and nobody else, but it also lets you provide multiple options for the widest user support:

Hear me rant and rave in a high-quality stereo WAV file (3.5 megabytes), or a crappy-quality mono AU file (1.2 megabytes), or a so-so quality but quick-loading Real Audio file (45K), or if you can't or won't listen to any of these, read a transcript of my rantings in a text file!

But if you must use embedded sounds...

If I haven't managed to persuade you out of using an embedded sound in your Web page, here are some methods you can use to do it. Unfortunately, in keeping with the old quip that "The great thing about standards is that there are so many to choose from!", there are several different methods of embedding sounds (and other multimedia objects), most are nonstandard and proprietary to some browser version or other, and all have compatibility issues.

Method 1: Old-Fashioned Proprietary Tags

Here's the method I've exhibited on this page since I first created it in 1997. Actually, it's two methods, both of them nonstandard and proprietary, placed in a manner so that browsers that don't support one "fall back" to the other:

<embed src="yoursound.mid" hidden="true" autostart="true">
<noembed><BGSOUND SRC="yoursound.mid"></noembed>

At the time, the BGSOUND tag worked only in Internet Explorer, and the EMBED tag worked only in Netscape. The BGSOUND tag is within a NOEMBED block so it's ignored by browsers that support the EMBED tag, ensuring that a browser supporting both tags doesn't try to play both sounds at once -- in fact, later MSIE versions actually did support both tags, and the lazy developers who just stuck both in a page without "protecting" the BGSOUND tag in a NOEMBED element sometimes found that those newer browsers actually tried to play two copies of the sound at once, for a highly discordant effect.
Some people maintain that a closing </EMBED> tag is needed at the end of this code block; given that it's a nonstandard proprietary tag to begin with, one can't consult a validator or standards document to resolve this dispute. It is my belief that EMBED was intended by its developers as an "empty" tag that takes no closing tag, but I could be wrong. At any rate, I've never observed any difference in browser behavior from the presence or absence of the closing tag.
DON'T try to set the volume of the sound in your embedded tag (there are various proprietary attributes to attempt such control), because some poorly-implemented sound-players will permanently change the user's system settings when such a tag is encountered, and then any other sounds (such as Windows system sounds configured for when your system encounters an error, or sounds in your screen saver) will blast out at the newly-set volume, which may be startling and/or annoying to the user.

Method 2: The Object Tag

Nowadays, the OBJECT element is the standards-compliant method of embedding multimedia content. In 1997, I couldn't recommend it, because browsers either didn't support it at all or (even worse) supported it poorly, failing to properly render either the object or its fallback content. Things are better now, though there are still issues with the compatibility of objects depending on what browser you're using and what plugins you've installed for it.
Microsoft zombies prefer the variant of the OBJECT element that uses the proprietary ActiveX interface, keyed on a grotesquely cryptic "class ID":
<object classid="clsid:22D6F312-B0F6-11D0-94AB-0080C74C7E95">
<param name="FileName" value="yoursound.mp3">
</object>
This time I'm embedding an MP3 instead of a MIDI, and I'm using the Windows Media Player (that's what's called up by the "clsid:" pseudo-URI). Thus, you shouldn't expect this to do anything useful on non-Windows systems. However, even though this is proprietary Microsoft stuff, there's actually a plugin that lets it work properly in Mozilla. If you want to include fallback behavior for browsers not supporting this, put it before the </OBJECT> tag.
A more standards-based object method, identifying the media type by MIME type instead of tagging it to a specific program, goes like this:
<object type="audio/x-mpeg" data="yoursound.mp3">
</object>
But, naturally, it's completely ignored by MSIE, as far as I can see. You can, however, nest the two above pieces of code by putting one of those OBJECT elements within the other, so that, hopefully everybody's browser that supports one or the other technique will find something to do.

Types of Sound Files

There are a number of sound formats out there, with various strengths and weaknesses.

• .au - The original "standard" type of sound file on the Internet; most browsers that support sounds at all will play these files. (MIME type: audio/basic)
• .wav - The standard Windows sound format, so practically all Windows-based browsers support it. I'm not sure how widespread support is on other platforms. Windows comes with a "Sound Recorder" utility which can create WAV files from a music CD or through a microphone, so they're easy to create. You can pick a wide range of sound sampling rates and mono or stereo mode; high-sampling-rate stereo WAVs sound best (in fact, you can make them fully CD-quality, and even create a real CD from them if you have a writeable CD drive) but take up enormous amounts of disk space and transfer time. (MIME type: audio/wav or audio/x-wav. Last I checked, this type was never actually registered with the standards bodies who maintain the official MIME type list, so the "x-" version is more proper as the prefix for unregistered types, but the regular audio/wav style is more often encountered.)
• .ra - The Real Audio format was very popular on the net in the 1990s, though it has lost ground to other formats since. Both the software to play these files and the software to create them are freely downloadable from realaudio.com. Files are very compact compared to other formats, with some loss in quality due to compression. If you're using a streaming server (which costs a licensing fee) you can provide your audio files in a mode where the entire sound file needn't be loaded before it starts playing. This entails creating a .ram file that links in turn to the .ra file with the actual sound. (MIME type: audio/x-pn-realaudio.)
• .mid - MIDI files aren't direct renditions of sounds like the other formats, but rather a set of instructions to control electronic musical instruments, similar to a musical score. You need a music program to create them, and some amount of musical talent is desirable. It's the most compact way of transmitting an instrumental melody, but can't do vocals. Netscape and Internet Explorer currently come with plug-ins to handle the MIDI format. (MIME type: audio/x-midi or audio/midi; the "x" type is probably still the proper one. Not audio/mid as sometimes mistakenly configured; this latter one seems to be a Microsoftism, with Windows systems configured to launch the MS Media Player for them, but since that won't work as a Web plug-in, it causes background sounds to fail in browsers like Netscape which respect MIME types.)
• .mp3 -- MPEG-1 Audio Layer 3. This is a really "hot" format these days, because it provides nearly-CD-quality sound in a compressed format. It's not as compressed as the much-lower-quality RealAudio data, but compressed enough to make it possible to distribute entire songs through the Internet. There are lots of sites with MP3 files, some of them pirated copies of commercial CDs. This piracy problem led the record industry to attempt to ban or restrict this format, despite the ridiculousness of trying to ban a file format with lots of legitimate use just because it can sometimes be abused. (The entertainment industry has tried this tactic, generally unsuccessfully, with just about every new technology that's come along in the last 100 or more years, from the player piano to the VCR.) Some feel that the true motive of the record companies is to suppress the legitimate uses of the .mp3 format which they find threatening: the use by independent musical artists to produce, distribute, and market their music through the Internet, bypassing the entire structure of retailers, wholesalers, and record companies altogether. MPEG began as a video format (and is important to the burgeoning field of digital TV), but it's this audio offshoot of that format that's getting the big Internet interest these days. (MIME type: audio/mpeg; this is another MIME type that doesn't seem to actually be registered as a standard, so it ought properly to have an "x-" before it. Sometimes video/mpeg is used due to this format's origins as a video format, but the audio type would be more appropriate when the file just contains sound and no pictures.)
• .ogg -- The Ogg formats (there are actually several of them, for audio and video) are an attempt to make a completely nonproprietary multimedia format (MP3 is encumbered by patent protection that requires licensing by software authors that use it). Due to this proprietary nature, Wikipedia doesn't allow MP3 or most other common audio or video formats, but only uses Ogg formats. You need to download a special "codec" add-on to your sound-playing software to play this format, but these are available on a free, open-source basis. Unfortunately, Ogg formats won't play on an iPod.
• Digital Rights Management (DRM) Formats -- This isn't a single standard, but rather a concept which underlies several formats (which are incompatible with one another). They are music files downloaded legally from online stores such as Apple's iTunes or Napster 2.0, designed to be played only on authorized devices, and perhaps limiting the number of different machines they're played on. Only Apple's format works on their iPod portable music players, but that format doesn't work in any competing portable player. No files of this sort make sense to use as Web background sounds, because even if the end user has the proper player program, it wouldn't let the user play the sound because he/she hasn't purchased it and hence gained authorization to use it. These formats are the music industry's answer to unprotected and pirateable formats such as MP3, but will have trouble catching on as long as consumers can "rip" unprotected MP3 files from their CDs.

On to other senses...

OK... present Web technologies now offer developers the opportunity to assault users' senses of sight and hearing. But the true cutting-edge developers will be interested in finding ways to make use of the other three senses to escalate their annoyance of the users. No Web uses of taste or touch are in the works, as far as I know, but somebody actually worked on putting the sense of smell onto the Web. No, I'm not talking about the famous RealAroma parody site. There is, or was, an actual for-real company, DigiScents (their Web site seems to be down now), working on a peripheral with replaceable "smell cartridges" containing a number of "primary scents" which can be combined under program control to yield an enormous variety of smells. And one of the proposed uses is to allow "background smells" on Web pages. While some Web sites might come out smelling like a rose, others are likely to give new meaning to the phrase "This Web site stinks!"
Update: Though DigiScents is apparently dead, yet another company has surfaced with an attempt to put smells on the Internet: see the Trisenx product page and a BBC article describing a new device to scent-enable the Web and e-mail.