Dreaming of Streaming

This article is not meant to be a direct how-to of streaming online, as there are too many formats and bandwidth considerations to cover it all, this is more of a 'consider this when doing it' type of article providing you with the knowledge of how streaming works and some experiences I have had while producing and publishing some of the many streaming media files I have worked with.

OK, you recorded your first hit song, what is the next step? If you are like many independent musicians you want to put it up on your website for streaming over the internet. Streaming is an interesting animal, it is the process of playing while downloading. RealPlayer is probably the most widely known method of streaming multimedia. When a file is set to stream, the hyperlink that is clicked actually links to a text file, this text file then directs to the actual multimedia file. The PC then opens the program that is associated with that media type and starts to download it, when the download hits the SMIL point (pronounced 'smile') it begins to play the song back while it continues to download the rest of the file.

In theory, a great idea, however, depending on your internet connection speed, can make for a nasty experience. On slower connections the file does not download as fast as it plays back so the playback stops, waits a little while it downloads some more, then plays a bit more, stops, waits again, etc. For this reason, streaming has been slow to catch on. Now in the DSL and cable modem world we live in it is more useful and a better experience for the user.

When encoding for streaming, regardless of the format you choose, you need to consider all audiences. In my experience with streaming, I have done both audio and video streaming, and I can say audio is easier, but still not perfect. A basic rule of thumb is to actual encode two versions of each file, one for slow folks and one for fast folks. The major problem with this is that many of us are limited as to how much space our website is allowed to take up on the hosts server. If this is the case you are best encoding one file for medium-fast folks and just writing a little disclaimer saying that if you are on a 56k this may not be pretty.

When encoding, most streaming media encoders give you a series of choices as to bandwidth, desired quality, etc. What these do is encode the media file targeting those criteria, if you choose to encode for 56k it would push the SMIL point further back in the file than if you choose 256k DSL bandwidth, that is because on a DSL line it can start the playback sooner because it can continue downloading the file faster, where as on a 56k you want to download more of the file before beginning playback so you don't get to the end of what is downloaded before more is downloaded...does that make sense?!?! And the quality preference is just the quality it tries to retain while encoding, the lower the quality is required to be, it will drop bit-size and sometimes stereo field might be diminished or eliminated.

In today's internet world, where high speed is all the rage (though I STILL can't talk my wife into it, and the internet is my career!) it is really getting less and less worth the time and server space to even make a file for us 56ker's, you may want to just target the high-speed market. Truth told, any 56k stream will not be that great even at the best possible 56k hookup, so most don't even try it anyway.