RadioActivity: Logging, playlisting and reporting software - Blog blog Blog - 2007 posts

(Looking for our newer blog posts? They're over here)

12.14.2007 - Satellite Radio, Royalties, and SE Reporting

For those of you that wonder what I do when I'm not coding, I read policy. Woohoo!

For example, take the Determination Of Rates And Terms PDF linked at right. It's 98 pages of thick - and sometimes sniping - commentary and decision from the Library Of Congress Copyright Royalty Board on exactly how satellite companies like XM and Sirius are going to pay their royalty payments and submit their reports of use to SoundExchange.

Sound familiar? Yeah - it should. Same battle, different battlefield.

Let me condense the whole thing here and save you some time:

I'm curious: Ignoring for a moment the obvious data-collection issues, how will XM or Sirius tally their reports of use? In Aggregate Tuning Hours? Actual Total Performances? Unless there's a magic voodoo box that can detect how many XM listeners are on each channel at any given moment, I'm not sure there's a way to calculate either one.

As predicted, many people would like to know why a 6.5-8% of gross monthly revenue is OK for satellite services, but Internet Radio is supposed to cough up something in the ballpark of a 35% royalty rate increase.

12.10.2007 - Nokia For The Win!

Just in case someone wants to buy an early Christmas present, please feel free to get us a Nokia N95 8gb. Because we're all over their new Internet Radio application.

It's free. It's open source. It can stream from any Shoutcast or Icecast-using webcaster. It's pure genius: Internet Radio on the mobile, done right.

Contrast this with some of the subscription based, locked-in, "controlled directory" Internet Radio offerings now popping up for Windows Mobile devices. Ugh. As if anybody wants to shell out $6 a month to hear Disney Radio or ESPN recaps. Please.

Nokia, you get our vote. (Someone please port this to the Blackberry!)

(And yes, we just saw this too, so we'll also settle for an Xmas PSP. But we're pretty excited to see mobile/handheld folks hopping on the Internet Radio bandwagon.)

11.19.2007 - Content Management Systems drive more station-generated content

While we've been busy lighting up new stations, we've noticed a lot of stations just starting to use Content Management Systems to run their websites.

Using a CMS is something of a no-brainer for many stations, because it eliminates the reliance on a webmaster. They have also evolved to the point where installation and maintenance doesn't require serious technical know-how.

What we have noticed is that stations running a CMS are inclined to create and publish more original content as they let their DJ's blog about the CDs and artists they play, as well as the live shows they attend.

Just a few examples: KAMP has been posting more artist interviews since they moved to Drupal. KUCR's newly redesigned WordPress website started off with Youtube and Imeem-enhanced show reviews. And SCAD's WordPress site is carrying a lot more original content since they went to WordPress, including concert picks and per-show blogs.

It's great to see every one of these stations publishing more and more content on their websites - and all of them are carrying live playlist feeds supplied by So far we're working well with Drupal and WordPress, and we're working on a Joomla module. But we have to be honest, we've come up with some pretty amazing ideas that tie original content further into station playlists. Without giving all the secrets away, we'll just say we are excited to begin work in this area.

10.18.2007 - Laying the foundation for more automation integration

I've just rolled up the newest addition to - an HTTP playlist gateway.

The gateway allows stations to bypass the web logging interface and put playlist entries directly into using specially formatted HTTP requests. It is intended as a foundation for letting station automation systems 'talk' to

The gateway itself isn't an end-to-end solution, but it is a good starting point for more complete and compliant playlist logging. SCAD has already tied their MegaSeg automation into the gateway, and tied that back to their homepage. It's a good development.

09.09.2007 - A nice milestone

Everybody, I'd like you to meet K'Swit, with WRGW at George Washington University in Washington, D.C.

Also: K'Swit is's 1000th DJ.

I like that milestone :)

7.30.2007 - Acronym Soup: I'm headed to the FMC in DC!

I'm headed to the Future of Music Policy Summit in Washington, DC, from September 17th to the 18th. If you're headed there as well and would like to meet in person, please drop me a line.

I know I'll be attending at least the following sessions: Wireless Media and Super-Portability, Disintermediation 2.0, broadband policy, and policymaking.

One of the things I like about the FMC is that they're great about putting their panel session videos online, for free, almost immediately after each event. If you haven't seen their previous talks, hit their "Past events" pages up for some informative webcasts.

If you'd like to line up some time to meet, I'll be getting into town on the evening of the 16th, and staying in the Capitol Hill Area. I'm anxious to meet a lot of the folks I've been conversing with over email, so feel free to hit me up at:

7.25.2007 - AJAX + RSS + a few frameworks == awesome

Ok, so I'm no graphic designer, but the concept's pretty tight

What you're looking at is a self-updating piece of Ajax-y code that uses a station's RSS to keep a running, live station playlist. That yellow blink happens every 10 seconds, and means it has just checked for new plays in the RSS feed. When their feed updates, so does this list.

::: fetching RSS feed :::

This one's tuned into KALX's "Last 10" feed. Any webmaster can have this integrated onto their website in about 3 minutes.

Like I said, this is just the beginning of some of the things we're working on. I can't wait for a station with actual graphic design skills to get their hands on this :)

7.23.2007 - There's good news, and there's bad news

The good news:

We just hit our 14th station signup, and once the invoices are signed and faxed back we'll be adding them all into the stations list. We'd like to say hello to all of our new stations! It's good to have you.

The bad news:

This means any new stations signing on after today will have to pay the $100 setup fee, as we stopped waiving the setup fee at ten stations. (And since we already cut 4 extra stations a break on the $100 fee, we've already overextended our offer.)

If your station has emailed me before today (Monday, July 23rd) about signing on, we'll still honor whatever quotes we sent via email. Just drop me a line and we'll talk.

7.11.2007 - Hey, look, it's all kind of integrated data analysis and reformatting!

Here's a short list of interesting things going on lately inside

  • Feed your BSI automation logs, and it will identify and fill-in missing fields, using your previous playlist entries, to prepare them for your SoundExchange Reports of Use
  • Take the output from the above, and will re-format it for inclusion in your Reports of Use
  •'s admin backend now includes expanded statistics on your station's overall genre and playtype usage
  • Many artists are showing up and making direct contact with the DJ's playing their tracks. We like seeing this happen.
  • We've just begun, as far as automation integration is concerned...

    6.11.2007 - Teaching our tools new tricks

    Thanks to WJCU, RadioActivity's free, online Aggregate Tuning Hours calculator can now parse Windows Media logfiles in order to calculate a station's Aggregate Tuning Hours.

    This means you can now use our tool to parse your Icecast, SHOUTcast, and Windows Media logfiles simply by clicking here and following some instructions. Don't forget we've also churned out a couple of articles on the subject, if you are wondering why this is important and are looking for a starting point.

    Automation is also becoming a bigger and bigger issue, and I'm working with some stations now to do some interesting things with their automation logs. One, for example, is taking BSI logfile output - output which often lacks key fields like album name or label name - and playing 'fill-in-the-blank' by doing some intelligent data mining of station records.

    We're getting pretty good at taking input A, running it through some logic, and getting new and improved output B.

    4.25.2007 - Small glimmer of hope during rough times

    With all the drawn-out CRB stupidity still playing out in court, it's hard to note any positive advancements in the webcasting realm, but I'd like to point one out here: Artists have started noticing their airplay in playlists and have been emailing the DJ's directly to say 'Thanks!'.

    If there's one good thing to come out of the next eight months, it's going to be increased artist-to-station interaction. This sort of relationship demonstrates exactly what the powers-that-be don't understand - the direct, demonstrated, non-financial benefit to artists when webcasters play their works. Raising royalty payments only muscles people out of the game, which, as many folks have pointed out, was probably the point from the beginning.

    We're already hooking in features to help encourage this artist-to-DJ contact, because it's probably one of the few things left that can save internet radio.

    4.09.2007 - David Byrne tells it like it is

    David Byrne completely nails it on the Copyright Royalty Board fiasco.

    It points to another victory for the oligarchs — the big 5 record companies and the media companies that own them. Count one more for the big guys. The reasoning that it’s for the benefit of the artists rings a little hollow as most artists heard this argument re: cracking down on file sharing, and most never see money from their record companies anyway — so the line about “we’re doing it for you” is pretty suspect.

    Originally from WIRED's David Byrne Explains How the Royalty Rate Decision Hurts Democracy

    2.26.2007 - How I spent Feb. 2007

    If it seems quiet around here lately, it's because I've been camped out with the SoundExchange Reports of Use delivery specifications. Woo-hoo! It might seem kind of dry, but it's bread-and-butter for us techies ...

    The good news is, can output properly formatted SoundExchange Reports of Use reports for our customers.

    The bad news is, even with's help, the process is still complex enough to require a little training and guidance. I have documented my experiences creating these reports in a series of articles and videos, and am running thorough the generation and submission process with stations one-by-one.

    Check out our new articles:

  • On the SoundExchange "Reports of Use Delivery Specifications"
  • Calculating 'Aggregate Tuning Hours'
  • ... and tools section:

  • Online Aggregate Tuning Hours Calculator

  • 1.25.2007 - More attempts to litigate streaming audio into the ground

    I try to avoid politics at all costs, but this one's too close to home:

    For those of you unfamiliar with the PERFORM act, please take ten minutes out of your day to read a couple of links.

    To quote the EFF:

    ... buried in the bill is a provision that would effectively require music webcasters to use DRM-laden streaming formats, rather than the MP3 streaming format used by Live365, Shoutcast, and many smaller webcasters.

    The PERFORM Act would change that, requiring webcasters to use DRM that restricts the recording of webcasts. That means no more MP3 streams if you rely on the statutory license.

    This is so stupid it causes me actual physical pain.

    I highly encourage you to review the following links and/or contact your congressperson to express your opinions on this matter.

    (Tip o' the hat to, whose recent blog post made me realize that this bill was back in 2007.)

  • Full text of the bill (PDF)
  • Washington Tries Its Best To Kill Internet Radio
  • Lawmakers bring back Perform Act from
  • PERFORM Act to restrict recording, broadcasting rights from
  • The Season of Bad Laws, Part 3: Banning MP3 Streaming from
  • Don't Let Congress Shackle Digital Music from

  • 1.08.2007 - Christmas comes a little bit late at

    Christmas just came a little later this year at, where our third server just arrived fresh (and just a tad behind it's delivery schedule) from Dell.


    This one's slated to be our secondary reports cruncher, backup database mirror, and a nonpublic development host.

    11.30.2006 - Logging playlists in-house vs. with R.A.? A quick technical discussion

    Lots of people are talking about playlist logging these days. I have fielded some more questions I would like to share.

    Some stations stations are telling me: "We have an I.T. person, we can run a webserver, we're all pretty tech-savvy - why don't you just make RadioActivity a downloadable program for us to run locally?"

    I respect where these stations are coming from. There are certainly some other free/open-source playlist-logging apps floating around, and since I started RadioActivity I've seen roughly two dozen stations that have their own internal playlist systems, with varying feature sets.

    I respect that most stations have a fiercely independent DIY way of doing things - and thus would rather solve problems in-house than farm them out to a 3rd party. I also respect that some stations inherently shy away from paying someone 'outside' to do something they think they can handle internally.

    Having said that, consider the following ...

    Most stations have high personnel turnover
    Your station may have a great I.T. person now - but what happens when they leave? And what are the odds that the next I.T. person's skill set will match the previous I.T. person's skill set?

    Enterprise-level infrastructure
    Most small-market stations are working with insanely tight budgets, and thus their computing technology leans towards consumer-class machines that lack "server-class" features.

    Take a quick look at your 'critical' station computers. What if the hard drive crashes? Is it running on a RAID array? Does it have a nightly tape backup? Redundant power? Is it even your server - or are you using a shared or campus computer resource? Do you even know who runs the machine, who to call when something breaks?

    Computational power
    One of's more popular features is its ability to compile reports based off of raw playlist data - top 10's and the like. Because this data came from the DJ's, there's a lot of 'fuzzy matching' and data cleanup that takes place. This sort of thing eats up computational power at a startling rate. Running this sort of intensive process on a consumer-grade (or shared) computer is not going to be anywhere near as fast as running it on the server stack.

    These are just a few of the reasons I have not released as a downloadable package for local use by stations. As always, I welcome your comments.

    11.27.2006 - 'Gracenote Defends Its Evolution'

    For any of you that may have missed the Wired Article 'Gracenote Defends Its Evolution', take ten minutes out of your day and read this one.

    For those of you who aren't familliar with Gracenote - take ten more minutes and read this Wikipedia article. (There are other opinions available as well ...)

    The Slashdot comments on this one are pointed, funny, and honest - others are more to the point.

    Remember, all in all we're talking about a few CD's worth of data. That people would close it up, monetize it, antagonize their contributors and hoard such a resource for their own advantage provides a pretty clear example of how not to operate.

    11.12.2006 - Answers to three commonly asked questions

    Here are three common questions that come up often:

    a) Does RadioActivity work with our existing automation system?
    b) How does RadioActivity address the changing SoundExchange recordkeeping requirements?
    c) Can my station beta test RadioActivity for a while to see if it meets our needs?

    Let me address these below:

    A) Does RadioActivity work with our existing automation system?

    Right now, RadioActivity runs purely on human input - mainly, DJ's logging their playlists directly into the RadioActivity web interface. I have been experimenting with different ways to tie RadioActivity into specific automation setups, but unfortunately there are many different automation systems out in the world.

    As a rule of thumb: if your automation setup has some sort of 'live export', it can probably tie into RadioActivity. However, some automation setups only report a subset of the data that RadioActivity collects and crunches.

    For example, a typical automation export can report artist, track, and album name - but RadioActivity also collects genre and playtype to assist with report generation. So this is one of the kinds of issues that come into play when talking about automation.

    If you have specific questions or comments about your automation setup, please feel free to contact me.

    B) How does RadioActivity address the changing SoundExchange recordkeeping requirements?

    Many of you have asked me about with respect to the proposed content and formatting changes to the SoundExchange webcasting reports.

    (For those of you saying 'The what? Huh?' - Joel Wiler's handout from the 2006 National College Media Convention is a good at-a-glance reference for what we're talking about. This is a small part of a much larger discussion happening right now, and I refer you instead to the website for more in-depth information about webcasting and recordkeeping in general.)

    The short answer to your question is this: RadioActivity can handle the formatting part of these proposed changes with little difficulty whatsoever, allowing you to submit your reports via FTP, CD, or email. This specific reporting is on track to become a basic administrator function within RadioActivity once the recordkeeping changes are finalized.

    As to the content of the reports themselves - RadioActivity currently handles about 85% of the required fields. Two fields in particular ("ISRC code" and "actual total performances") are problematic, but I have some innovative ideas for dealing with that last 15%. I cannot discuss them further until a couple of different things happen - and some different people weigh in on the specific way I seek to handle these two fields - but the upshot is this: I'm working on it. In short, RadioActivity seeks to make these reports as simple as clicking a button, so stay tuned.

    C) Can my station beta test RadioActivity for a while to see if it meets our needs?

    Of course. All you need to do is contact me so I can touch base with you, and I will be happy to set you up with an evaluation login.

    Please send any questions or comments here:

    11.11.2006 - A blatant plug for a small side project

    For those stations running the Icecast streaming media server, you may be interested in is a free, Icecast-compatible Yellow Pages (YP) server. For those of you unfamiliar with the concept - you can configure your Icecast server to 'talk' to, and your server then 'advertises' its broadcasts to the public, along with stats like current listeners, current song, etc. to help listeners find your station.

    This is one of about 3 public Icecast YP servers in existence, and I've added some extra bells and whistles like RSS and a "last 25 tracks" feature.

    Directions for listing your stations are found here.

    11.10.2006 - A blog?

    I'll admit it, I've never really been a big blogger. Lately, however, I've been fielding lots of email about from many different sources - from GM's to DJ's to other techs and application developers. The best place to share some of these ongoing discussions with all of you may be in blog form. And here we are ...

    Please send any questions or comments here: