The Technical Side - Page 9

So, Web developers! How does one create an interactive radio site? This is a good example of a trend that has often been mentioned in these pages, namely the evolution of Web "sites" into full-fledged online applications (see A Look at the Web Development World Ahead). At first, it might seem that the lowly Web browser is not needed at all. Certainly it would be possible to build the PRS as a self-contained application, perhaps in Java, that would simply be launched from a Web browser, then take over. But in fact, the good old Web browser is still needed for several reasons.

One of the interesting things about online radio is the ability to display text and graphics in tandem with the audio program. Liner notes, artist pictures and other goodies add to the user experience. But who are we kidding? What we really want to display are ads! Oh yes, not just banner ads, but links to e- commerce sites where visitors can buy CDs, t-shirts and all that other revenue-generating stuff. The Web page provides a way to tie all this material together, as well as, obviously, appropriate links to other features of the site.

As we’ve seen in other columns (see Web Audio 2000), media formats are getting pretty sophisticated, and it is possible to include all of the above features within a streaming media file itself (Windows Media, RealMedia or Quicktime). But most site owners will probably choose to invoke the streaming media player strictly for the audio/video program, and deliver the surrounding trappings (graphics, links, ads and the programming engine itself) through some type of HTML/XML/Java environment.

The reasons for this are twofold: it allows site owners to add value by offering their own look and feel, and it allows them to incorporate content from diverse sources. Remember that one of the features of the PRS is that it can include material from any online source in a single program. Some audio content is available only in RealAudio format, some is in Windows Media format, some is in MP3 format, etc., etc. An online radio station can mix and match formats in a way that is semi-transparent to the user, by invoking the appropriate player as needed.

It should be apparent by now that this is a job for a dynamic Web solution. Existing online radio sites use one or another of the many scripting environments. RadioMOI, described above, seems to use PHP, while other sites use Active Server Pages (ASP), Java or even Perl. Stored user data is combined with dynamic user input to select the desired media files, open the appropriate media players, and display the material within an HTML or XML page. A rudimentary version of a customizable online station is a pretty simple task for any of the above scripting languages, but anything approaching our theoretical PRS would be a far more sophisticated project.

Which brings us to SMIL (Synchronized Multimedia Integration Language). This XML-based language, in conjunction with an advanced scripting language, would seem to be ideal for creating a highly customizable online station. SMIL marries the concept of a timeline to the concept of a markup language, and it allows the seamless incorporation of any type of media file. Thus, a SMIL program could include any sort of media, pre-recorded or live, from anywhere on the Internet, and deliver it at user-specified times. For more information on SMIL, check out Streaming Media World.

At first glance, the timeline might not seem necessary. After all, a powerful scripting language should have no problem serving up audio files from a user-created playlist, simply waiting until one file is played before starting the next one. But the PRS doesn't just play audio files, it also synchronizes them with matching text and graphic content, and this text and graphic content comes from the radio station site itself. For example, let's say our radio station site has a deal with Amazon.com to sell CDs for a piece of the action. When a particular cut is playing, the user's browser needs to display a link to Amazon.com that includes the site's vendor code, so that the site will receive credit for any sales generated. SMIL can deliver any and all types of media in a synchronized way, and thus it is perfect for applications such as this, that need to combine internally- generated content with external data.

The PRS can deliver media from any site on the Internet, but if the media were always served directly from the originating site, it would probably be a pretty slow and unreliable affair. We all know that some sites are slower than others, and few are up 100% of the time. If a site happened to be down or overloaded at the moment that a media file from that site was due to be played, your perfect radio station would fall silent. To avoid this sort of situation, the PRS would temporarily transfer media files to its own servers ahead of their scheduled play times, then serve them at the appropriate moment. Seamless and (almost) problem- free delivery would be another attractive user benefit of the PRS. And another argument for using a timeline-based language such as SMIL.

Another thing to consider is that the PRS's playlists should be at least partly dynamic. That is, the user can alter the playlists, or even request particular songs, in real time. A dynamic scripting environment can process user input, and generate SMIL files on the fly.

Putting it all Together

So, in last month's column, we discussed the legal issues, while this month we outlined the technical pieces of the puzzle. The technical issues involved in actually serving the audio or video (streaming servers, etc.) were not discussed here, because they were covered in a previous article. Next month we'll look at the financial aspects. How can one make money from a media site? Is anyone now making money from such a site? How can you, dear reader, set up a site that will make you some money? Return next month to find out!

Media Sites Come and Go - Page 8
Next Wave of the Web