some plans

Content Management for the Ear

A simple audio-capable webblog may be the perfect way to build a full-length, radio-style programs, instantly distributable to listeners worldwide. Sound good to you?

Audio Management System on a CMS

Your own radio show?

Audio programs are put together from pieces -- known in the industry as segments -- that follow one after another:
  • station id
  • program intro
  • field reporting
  • interviews and conversations
  • news
  • public service announcements
  • commercials
  • music tracks
  • promotions
  • found sound
  • program outro and credits
An audioblog may be the perfect vehicle to build a simple "radio-style" audio program, by collecting all of your segments in a logical order. From there, one can apply content-management techniques in the audiospace (as opposed to the screenspace): sort the segments based on metadata and render them with the appropriate intro and outro (aka header and footer) as a contiguous program.

Additionally, in much the same way that textual data is merged into templates by the CMS, the audio-capable server will perform light signal processing on your segments, such as normalizing the volume and applying quick fades at the beginning and end for smoother transitions. Indeed, the server must be capable of producing the audio equivalent of image thumbnails: 15-30 second snippets to whet the listener's appetite.

Step By Step

Berylium will treat each folder as a potential audio program, pulling featured content from subfolders in exactly the same way it does for text/html documents. Program segments will be assembled in the order that they are rendered in folder view (which means that the intro and outro should always be virtual listings at the top and bottom of the folder for consistency).
  1. Writer uploads program intro and outro -- setup/preferences
  2. Writer uploads/imports audio segments -- daily audioblogging
  3. First visitor requests latest program
  4. Server collects un-archived audio segments in the same order as the display in the folder
  5. Server places intro and outro
  6. All segments are then output to the visitor as a single mp3 or ogg file
  7. Next visitor requests program; server sends file from cache.
As of this writing, content that is generated from folder listings (RSS files, for example) is not cached-- a mechanism will be needed for this so that old programs may be archived within the Berylium framework. Come to think of it, it would be an excellent idea for RSS as well, so that you could see exactly what was in your newsfeed three years ago.

Audio Files vs. Playlists

Why not just create a playlist that includes the original audio segments in the proper order?

From a processing standpoint, this would be much lighter; and in fact, it's what a vanilla Berylium site should do if it doesn't have the e99o media-handling extensions. But there are numerous drawbacks to playlists:
  • increased server load -- a larger number of requests
  • inability to redistribute or mirror the program (think BitTorrent)
  • listener must be online in order to listen
  • crossfades impossible
  • playlists imply connection pauses between tracks
You've seen all of this before. Playlists seem like a good idea on the surface, but they are really designed for local use where there is no connection and buffering delay, or situations in which rights management is the primary consideration.

A Note About Rights Management

Berylium takes the philosophy that if you make content publicly available on the internet, you expect that it will be cached by the internet and client computers. Rights management is primarily a social challenge, not an engineering challenge. Berylium will always attempt to include appropriate copyright and licensing metadata in the files that it serves, so that recipients (human and computer) are given every opportunity to do the right thing when it comes to redistributing those files.

By Chris Snyder on July 30, 2003 at 10:29pm

jump to top