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).
- Writer uploads program intro and outro -- setup/preferences
- Writer uploads/imports audio segments -- daily audioblogging
- First visitor requests latest program
- Server collects un-archived audio segments in the same order as
the display in the folder
- Server places intro and outro
- All segments are then output to the visitor as a single mp3 or
ogg file
- 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.