create a core CMS/API to model live host information

Initial codeset request posted to oDesk

In an effort to create a base set of code, I have posted a job request to oDesk at http://bit.ly/a9w4Rt.  What I hope to achieve with this request is a starting point from which to build the project.  Unless I am convinced to do otherwise, I would like to build this project in Python using the the Twisted Framework.  This would also leave a lot of the "pretty" of the code to the end user by providing code inserts for the functionality.  This will also allow the core application run seperate from a broadcaster's public website.

If the posting succeeds, I hope to have a base application which will present a host entry page as I have outlined here.  This would be a great start as well as being just enough to dump the old code at WSUM and finally move the playlist database to a new server.  Please pass the message along to any developers you know who may be interested in working on the code.

Radio and Social Media

Mark Ramsey just wrote an article about the failures of radio stations in using social media.  He makes great points about social media NOT being a marketing outlet, but instead being a channel to the listeners. 

"Social media is not a promotional vehicle per se for your station."

This is a great point and an accurate assessment of social media.  Social media is not a place for advertising as much as it is a place for interraction.  This means that engaging in social media means one needs to listen and engage.  What social media is is relevant in real time.  This is how the social media world differs from simply putting information on a website.  Social media is relevant NOW.

At any given moment, a station or a stream is fronted by the host which puts the host in the best position to be engaging with the social media along with the responses.  This is not dissimilar to taking phone calls in the studio and playing requests.  As a program host, it is great to get a call from a listener and know one is being heard.  It is a perfect fit to apply social media tools to this concept, and not make the social media become a "push only" vechicle for advertising.

Social media can be a great asset and companion to the live stream, but often the tools needed to bring together the information are out of reach to smaller broadcasters and streamers.  The goal of this project is to bring the host, the stream, the content, and the listener together in one place so that the information about the program can be shared while it is still relevant.  The host can take requests by phone, but it would only enhance the performance to be able to take that request as well from the station website, facebook page and twitter account, as well as from the host's personal accounts without having to jump around multiple webpages. 

Aggregation and deployment of pertinant information in the real time can be a daunting task.  This is what makes the social networking relevant.  However, it is difficult to resource this information.  This project will start with aggregating the current play for the purpose of passing that information as fast as possible to both station-branded social media as well as the host's personal social accounts.  If the dissemination of this information can be semi-automated, it will serve to make social media an asset to the broadcaster with a minimal amount of investment.

Design Considerations and Narrowing Focus

WSUM Host Entry Page

This website is a collection of ideas which have been documented as they have occurred.  Now there is a great pile of ideas, i's time to narrow focus and get the project off the ground.

What is Needed?

This project seeks to model and obtain the host's information and make it available to all who need to view it.

As a student organization, WSUM is completely run by the students of the University of Wisconsin.  Myself and the General Manager are the only two permanent full-time staff.  The student's perennial goal seems to focus around scheduling as many human-operated hours behind the mic as possible.  This brings a lot of diversity into the studio and makes for a lot of great programming.  The problem is once the broadcasted show is done, all the information researched for that program virually disappears into the ether.  Additionally, every show remains as a stand-alone entity from every other show as well as the audience that did not listen to the broadcast.

The first task is to obtain the show topics and playlists from the hosts in real time.  Once that information is obtained, it needs to be presented for all sructures which require that information. 

How do we get this information?

The information that is pertinent to the host in the moment can be modeled.  It is likely to be either a song being played or a topic being discussed.  At WSUM, we have been using a simple web form for over a decade to capture the current play information, but the code is not robust enough to do much more than store the info in a database and show the current play on the website.  The thought has always been that getting the hosts to use such a tool woud be the hardest step, however, in practice at WSUM, it has been shown that the hosts want this information to be shared.  Thus, usage has been very close to 100% by hosts because they want their research out there!  Once the information model is created and used by the host, the prospect of getting this information to websites, social networks, RDS encoders, mobile apps and whatever else comes down the line becomes possible.

What do we use to do this?

Every idea which has manifested on this site has been concieved in the context of using the web browser as the interface for the host.  In the simplest context, the data to be contributed by the host gets modeled and then a controller (presented by a web server)  takes care of that information.  A great example of this process is Wordpress.  A public codeset is installed on a user's web server and connected to a database.  From that point forward, all of the information generated goes into the database, and the codeset can be tweaked or moduled to present the data back to the world in whatever manner of choice.  This is an example of a Content Managment System and a model for this project.

What do you think?  Please add your comments below and/or sign up for the newsletter to stay informed about the project.

Formulating a Plan

StreaMeta.org reflects ideas about building a content managment system for broadcasters and web streamers.  The StreaMeta concept is built upon the idea of providing the hosts of a broadcast with an interface which allows them to engage with the information being provided about the stream.  For streamers, this could be as simple as the track/title or topic information that is appearing in the listining client's media player.  For all content providers, the StreaMeta project hopes to provide this aggregated information to the provider's website, social netowork sites, and for broadcasters, even HD radios and RDS encoders.

Host entry is just the start, but like any solid project, there must be a starting point.  If you feel your organization could benefit from such a software, or you feel you have ideas to contribute to make such a project work for you, please consider signing up for our e-mail newsletter from this site so that we may keep you in the loop.  E-mails to subscribers will be short, to the point and will only occur when there is something important to present.  Every e-mail will include an unsubscribe link.

Our next step will be to formulate a presentation on the concept of centralized metadata aggregation in a content managment system in the hopes of being able to present at the CBI Fall 2010 National Student Media Convention.  If the session is granted, this will be a great chance to connect with other non-commercial broadcasters.  If there is a possible market for this software, this will be a good place to gain momentum or let it rest.  If you are a CBI member and going to the convention this fall, please use the contact form and get in touch.  Any support of the project or willingness to participate in a round-table at the convention would be most welcome.

 

 

What could StreaMeta do?

As I review the content posted thus far to this site, I find that there are a lot of ideas for potential functions of a boradcasting-oriented content managment system beyond the basic playlist entry functionality of the software.  The source concept of this project is to provide a tool to hosts of a broadcast to track and disseminate information about what is being broadcast.  The greatest asset of a community broadcast is the diversity of content being discovered and presented by the multitude of hosts who support a community broadcast.  The goal of StreaMeta is to aggregate the information about this content in a cohesive manner and then present it to the multitude of consuming technologies used by the same folks looking for new and fresh content. 

What follows is an aggregated list of all of the potential pieces of information that have been expressed for potential inclusion in the project, both on the input and output sites of the code:

Input

  • Programs
    • type
    • title
    • description
    • topics
    • schedule
    • show logs (blogs)
  • Program hosts
    • contact forms
    • social links
    • mood
    • pre-show tools and prep
  • Playlist entries
    • Track
    • Artist
    • Album
    • Label
    • Genre
    • Request
    • Local Artist
    • New Artist
  • Automated entry
  • Streaming servers
    • links
    • listener counts
  • Archives
  • Live interraction
    • Requests
    • Chats
    • Playlist Requests
    • Tagging

Output

  • Host-specific information
    • local weather
    • internal communications
    • current or hot copy
  • Schedules
    • site embeds
    • open schedules
    • historic shows
    • slot requests
    • "on-deck" programs and topics
    • similar genred programs
  • Current play and history
    • Website
    • Stream players
    • Podcasts
    • RDS Encoders
    • Social networks
    • SMS messages
    • Mobile apps
    • Service submissions
  • Stream links
    • load balancing
    • embeded players
    • listener graphs
  • Charting
     

Modules

  • Music Library
    • physical catalog
    • digital content
  • News spots/copy
  • Playback decks
  • off-line generated playlists
  • Search Engine Optimization
  • Trends
  • User media catalogs (removable drives)
  • Issue reporting and tracking

Some of this may seem to be abmitious, but if interraction via the ubiqutous web browser is considered, the options now being presented by HTML5 make many of these features much more realistic.  Please feel free to contribute any ideas or suggestions in the comments below.

Streameta Proposal

Broadcasters and Internet streamers who perform live programs do not currently have a means to cohesively pass playlist data along with the stream.  Automated playback systems can often do this, but switching to a live performance where source material can be any number of formats such as vinyl or CD, this metadata is not immediately available to output channels where listeners can see what is playing.

Streameta.org is dedicated to the discussion and development of an open source software solution to allow for real-time human entry of metadata associated with the live performance. The objective of Streameta will be to get this information from the host and push the data to various channels whch carry that information to the end user.  These paths can include webstream metadata channels, website "current play," RDS encoders for FM, HD radio, mobile apps, or even social networks like Twitter.

 The Streameta project aims to include form entry for handling basic music play info such as album, artist, and track, but also adding additional capability for host name, show title, topic, and co-host or guest fields.  Capturing this data in real-time allows content creators and broadcasters to maximize the channels of output available to the broadcast streams. Streameta aims to deliver the information about the live performance everywhere it needs to be.

Radio has been around since the 19th century.  In the 21st century, radio has new tools that are enhancing the broadcast.  Internet streaming opens up channels of dissemination of the program beyond the transmitter region.  The broadcast has now become data.  As the broadcast becomes digitized, it carries the potential to also present metadata, or data about the data.  Digital audio files will often contain "tags" which is machine readable information about the audio contained within the file.  This information becomes helpful in searching for a particular piece of audio amongst a repository of many pieces and increases the usability of the data.

In the broadcast, the metadata is used to provide information about broadcast to the end listener or viewer.  Radio stations will often show the currently playing song on their website and on RDS enabled radios, a feature quite common on modern radios.  Web streams will carry this information to the end software playing the stream to demark what it is that is currently playing.  It is the metadata that in many cases has replaced the voice break between songs to announce the current play.

When a radio station uses a computer player to contain and play content to the broadcast, often this metadata connection is made automatically by broadcast-specific playback software which uses the tag information direct from the file and pass that information to the end user.  For an automated system or a broadcast which only uses computer playback, this works fine.  If a broadcaster chooses to use traditional means of playback with sources which may not be digital or have metadata, the information to the end user will often remain empty or contain improper information.

The Streameta project aims to intermediate between metadata sources and destination channels allowing the host to maintain these channels of information.  When a live host is actively engaged with the program, they will be able to maintain an active playlist of their performance which will not only drive the metadata channels, but also allow for archiving of the information as well.  This metadata can then be adjusted to not only present a music play, but also be used as an additional channel for broadcast information which may or may not be music related.  The host will be able to present their own name, names of guests or co-hosts for talk programs, subject matter, program titles, ads, or any piece of information that may assist in capturing the attention of a casual passer-by or latecomer to the program.

Once the pertinent information is brought into the Sterameta system, it will be possible to present this information to any number of channels where it will find pertinence and attract more audience.  Streameta aims to bring the technical metadata channels used by radio together with more common channels of dissemination like social networks.  By keeping all of these channels sourced from one common location, branding of the performance or broadcast will be much easier and cohesive.

The information can also be saved and maintained to allow for charting and searching of playlist and topic history.  When a broadcast is presented with multiple hosts, charting history will allow other hosts to see what is hot on the airwaves and even assist in reducing repetition and topic redundancy.

One of the most common tools available to a software developer is the web browser.  An effective means to use a web browser as a information aggregation tool is by means of Content Management Systems or CMS.  Successful CMS systems like Wordpress and Drupal provide an effective means of aggregating information and presenting that info to a larger audience.  The Content Managment serves as an intermediary between humane information and computer code.  CMS software is also an effective means to create modular software.  This allows for customizing a common structure to suit the needs of each particular broadcaster.  The CMS model will also allow for easier modification should the broadcaster require a unique usage.

Content Management Systems are packages of code that typically operate with freely available software platforms.  The code-set will typically require both web server software and a database application.  Many current CMS applications develop their code in a manner which allows modularity for languages and server types.

Working in an open source context will provide easier access to the aggregated metadata.  Ideas about how to use a metadata channel can be as varied as the broadcasts themselves.  By bringing access to all of the various channels together in one place, the open source model will allow the broadcaster to modify the system to suit their needs and even present those solutions to the greater community.  With the scope of Streameta aiming to allow output to any number of channels, an open source approach will allow for sharing of unique solutions for particular pieces of hardware and software used to push the information to the end user.

By developing Streameta as a CMS web application, low level access to output channels will be brought to a high level of access by using commonly available tools. It is possible that Streameta can also be developed in a manner which will allow it to also be used as a module to already existing CMS systems and websites.  This would allow for seamless integration into existing websites and web platforms which already contain some of the pertinent data such as program schedules and user info.

Development of Streameta will be initially targeted towards student radio stations, low-power radio stations, webcasters, and any broadcast sources where budgets are constrained.  Low power, student, and community broadcasters often have a huge reservoir of volunteer talent to produce a large portion of the broadcast with live presence, but often lack the funding to purchase software which is often used to populate the data to modern output channels.  It is often in these environments where great innovation is found and shared amongst peers.

Commercial radio stations inveest in software and media libraries that suit their particular genre of programming.  Their coverage of the broadcast market is widespread enough to enable a market for automation software.  Their needs often include commercial playback and trafficking as well as affidavits for their airtime purchased by advertisers.  These software products are typically proprietary, expensive, and lack any component to allow real-time entry of metadata into their output channels.

Streameta does not aim to replace these types of software, but to instead accept the metadata from the automation software and merge it with the human entry metadata and to serve as a switch between automated and human programming.

The base of the Streameta project will consist of an input form, a data storage method, and an output type.  This model can serve as the foundation to all other desired objectives with Streameta.  A rough model for a potential input form can be seen here.  An initial implementation of the software will allow immediate deployment by interested broadcasters to start the process of introducing talent to the concept of real-time entry.  The intial release of the software should aggregate this data, store it in a database, and provide embedable code to present the aggregated information via a webpage or widget.

This data-set contains enough information to provide the needed information from the host for a current topic and/or play, but also the necessary triggers to initiate a stop-set mid-program, a trigger to switch to a new program, and a method to allow a switch to an automated input stream from an automation system.  This initial data-set will be enough to establish the habits needed with the program hosts to eventually be able to use this information for all of the suggested data channels.

The Streameta project in its simplest form will fill a much needed void in human-driven broadcasts.  While many broadcasters have eliminated human presence behind the mics of their broadcasts, the Internet has provided an increased access to new media.  When broadcasters are able to work with their communities to seek out volunteer talent for on-air broadcast hours, these broadcasters are seeing an increased dedication to their broadcasts that is not seen with automated playback.  The ability to take a request from a listener and discuss "in the moment" topics can have a significant impact on the success of a broadcast.  Streameta seeks to keep pace with this concept by allowing the end consumer access to information about what they are hearing in an on-demand model.

Matt Rockwell is the Chief Engineer and Technical Director for WSUM 91.7FM Student Radio at the University of Wisconsin.  His five-year journey to the creation of the Streameta project is documented here.

Please feel free to add any comments below or to use the contact form to send an e-mail to Matt.

The Software

In order to keep and organize all of this information about the live stream, a software needs to be designed and coded.  This could take this project in an infinite number of directions so the software needs definition.

The one successful aspect of the current system in place at WSUM is participation.  I believe this is due to the simplicity of the interface that is presented to the hosts.  In order to get the information that is currently tracked, a simple PHP/MySQL webform was designed and deployed on an internal server at WSUM over a decade ago.  This very simple interface has seen almost 400,000 submissions from the hosts at WSUM and continues to be used by almost every host who plays music at the station.

The solution to the live stream metadata problem should stay in the web browser.  The success and ease of use of Content Managment Systems suggests this as a good place to start the design of this project.  Applying the fundamental structure of Object Oriented Programming to this design leaves the codeset as the method.  What remains is what data goes in and what data is produced from the input and the method.

The successful aspect of the WSUM entry system has also been in using the form real-time.  This keeps the information as fresh and relevant as possible by timestamping the play at time of entry.  I have already mocked a modified representation of the successful input page in use at WSUM here. A successful input system should use a minimal amount of fields to be successful.  The modifications from what is currently in use includes a topic/mood field in order to garner relevant information from non-music shows as well as serving as a filler for stop sets.  In this vein, a "clear play" option should also be included to introduce a stop-set to the method.  An "end show" option would also serve to solve the cronic problem of allowing the method to know when a human is done and either a new human or a robot will be taking control of the live stream.

Focusing on the most commonly used input point of the system, we come up with the following dataset to start defining the process:

  • hostname
    • program title
      • topic/mood
      • co-hosts
    • current play
      • artist
        • local artist
      • album
        • compilation
      • track title
        • request
      • label
        • compilation
      • genre
    • timeshift entry
    • clear play
  • end show

This model provides the basic dataset that can be used by the method to produce any or all of the following:

  • program schedule
  • host list
  • transfer to automation dataset
  • output channels
    • stream metadata
    • website playlist
    • applets and widgets
    • Radio Data Systems (FM data broadcasts)
    • HD Radio
  • podcast playlists
  • playlist archives
  • charting

RadioTime API

RadioTime.com has just announced an Application Programming Interface or API to allow us end broadcasters update our information at RadioTime without having to pass through a human. Details of the API are at http://inside.radiotime.com/developers/api/air.

RadioTime.com is a website which aggregates many of our aural broadcasts into a common repository and re-deploys that information in a web standard's manner for free. For WSUM, it's the most common entry point to our webstreams after direct links and iTunes Radio. Many web radio services use the aggregated feeds to re-deploy our information to their users.

I personally own a Logitech Squeezebox which is one such device that can pull live content from the web or media from my home server. In my house, this box runs more than the TV. Other products that use RadioTime's free service are at http://inside.radiotime.com/.

Matt Rockwell is the technical director and chief operator of WSUM 91.7FM, The University of Wisconsin's student run FM radio station.

Twitter Follow

Follow MattRockwell on Twitter

Syndicate content