[<== Previous] | [Up] | [Next ==>]
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
- 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
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">
At the time, the
BGSOUND tag worked only in Internet Explorer,
EMBED tag worked only in Netscape. The
is within a
NOEMBED block so it's ignored by browsers that support
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"
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
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
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
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":
<param name="FileName" value="yoursound.mp3">
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
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">
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
- .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.
[<== Previous] | [Up] | [Next ==>]
This page was first created 01 Sep 1997, and was last modified 11 Dec 2006.
Copyright © 1997-2011 by Daniel R. Tobias. All rights reserved.