In order to get your message across, it is very important that you know your audience. This applies to speeches, plays, movies...and your RealAudio. If your media clips are too large, then chances are your audience will not be able to play them, or even bother to try them. At best, clips will play in a jerky fashion after a long wait, neither of which is desireable.

It is therefore crucial to target your media clips to your intended audience, and set them at a reasonable bandwith. There are a few ways of doing this, and right now we’ll take a look at them.

The simplest way, of course, is to have several single-rate files suited for different bandwidth connections. You might have one lower quality one for 56k and below users, one for ISDN, and a high-quality one for xDSL and cable users. RealProducer 8 offers eight different rates at which to encode.

If you’re using the recording wizard, you have to choose "Single-rate for Web Servers" under the file type, then select the target bandwidth. Remember that users with higher bandwidth connections can still access a lower quality file with no trouble, but the reverse simply cannot hold true! If you really cannot afford the space for many files, then the best bet is a single file encoded for 56k users.

A more elegant solution is to create a SureStream file. However, you will need to have access to a RealServer G2 to do this...once only possible if you were willing to shell out for GeoMedia, now free. =)

A SureStream file enables you to allow users of different bandwidth to access the same file. The same audio information is encoded from low quality to high quality in the same file. During playback, RealPlayer and RealServer adjust the quality to adapt to network congestion.

To encode in SureStream, choose "Multi-Rate SureStream for RealServer G2" in the recording wizard. After that, choose the different bandwidths you’d like to encode at. If you’re using the trial version, you can choose up to two bandwidths (I recommend 56K and Dual ISDN). If you have paid for the full version, you can choose up to six.

If you are not going to use a RealServer G2, then do NOT use SureStream. As I have already mentioned, it encodes in several different bandwidths, and as such the file is larger than a one single-rate file of the same audio clip and will cause problems with most connections. Think of it as several single-rate files combined.

If you use single-rate files, you’ll find that you’ll have to link each one individually and let the visitor choose the file to use. For the more adventurous ones, you can perform a little trick to remove the need for so many links.

This involves the use of a Synchronized Multimedia Integration Language, or SMIL (read "smile") file (extension .smi or .smil).

Suppose you have three RealAudio files geared toward different audiences. You’d use the following code, which is rather like HTML:

The numbers for "system-bitrate" are quite standard, some 75% of the minimum spped of the connection you are targeting. For example, the clip for users with at least 28.8 modems has a bitrate of 20000, or 20 Kbps, somewhat below three-quarters of 28.9 Kbps. The typical figures to use for standard connections are as follows:

You can write the code in a standard text editor like Notepad, and save it as a SMIL file, say song.smil. You’d then put the three RealAudio files and this SMIL file in the same directory, and simply link to song.smil...your visitor’s RealPlayer will automatically choose the right clip to access.

There are a few important points to note when using this method. First, you must list the system bandwidth options from highest to lowest. RealPlayer evaluates options in the order listed, selecting the first viable option, even if subsequent options suit it better. So if the 28.8 Kbps option is first, a RealPlayer with a dual-ISDN connection will choose that option because it is the first viable option listed.

You must also ensure that the last option satisfies the lowest bandwidth connection you want to support. If you do not list an option suitable for 28.8 Kbps modems, for example, then visitors connected through those modems will not be able to play your clip.

And there is one last method. (Thanks, Florian, for this great idea!) You provide a link direct to the RealAudio file itself, and visitors can download it to their hard drive and save it in a temporary location before playback. It might take a while to download, but sure removes any bandwidth restriction problem!

If you use more than just RealAudio in your clip and combine several clips together, you will have to manage the bandwidth yourself. That, of course, is another issue altogether. We might take a look at that sometime, but right now we’ll concentrate on the audio aspects.

Back in the first issue we saw how we could use RealProducer to put a RealAudio clip on a page and upload it. In the next two issues we’ll look at how to put files up without the help of these wizards, affording better layout and making the process more customizable.