TheEC: On-Demand Newscast Audio

Aug 5, 2017

If you follow RIPR on Twitter...and if you don't I highly recommend it; even if you're not really a Twitter fan, we post all sorts of cool stuff on there....then doubtless you've noticed that not long ago we created a system that automatically tweets links to the audio of our local newscasts.  

This has proven surprisingly popular; we've found about 3 of every 4 folks really like it, which is incredibly positive feedback for a radio station.  (it's quite difficult to find something universally "liked" in broadcasting, often we have to settle for making just 10% of the public happy with any one initiative)

I should pause to point out that you can also find the three most recent newscast audio links right on our home page:

Since we do a lot of local newscasts (15 every weekday, and 7 over Saturday and Sunday) this means quite a few tweets.  So I've been experimenting with trying to figure out a way to automatically tweet content at specific times to help "break up" the flow of newscast tweets.  This has proven more difficult than you might imagine.

To begin, I made a decision early on that everything in this process has to run unattended.  That is, it doesn't require a human to actually do anything.  I wanted to make sure our reporters are spending their time, well, reporting and not messing around with behind-the-scenes systems.  

With that in mind, here's a rundown of how the flow works...

First, we record the local newscast.  I have a spare Windows 7 computer in master control, with a tap off our mix board's "program" feed.  This gives us nice, clean audio.  On this computer, I use Dimension4 to keep the clock tightly synchronized to our NPR clock and then I use Total Recorder Professional Edition (cost: $36) to record audio at very specific times throughout the day; these times are when the local newscast is airing.   It's not quite perfect; sometimes we upcut/downcut the newscaster's voice a bit (the clocks are perfect, but humans are messy) but usually it's pretty close.

When Total Recorder finishes making a recording, it automatically saves an MP3 of the newscast with a unique filename created by certain "rules".  That filename (usually with a specific time/date in the name) makes it possible to then manage the files throughout the remainder of the process.  

In addition to a specific filename, Total Recorder also saves these files in a couple of different specific folders on the local RIPR computer network.  One folder, for example, is our staff can quickly and easily hear airchecks of themselves.  I have a server program called SubSonic (cost: free) that is a little clunky (because of music piracy concerns, it's surprisingly difficult to find software that means it easy to share MP3's across a network!) but makes it so they can quickly find an aircheck and play it from their computer at their desk.

Another location, more pertinent to this discussion, is a folder where a program called GoodSync (cost: $30) notes the new file and automatically FTP's the file to a web server hosted by PowWeb (cost: $12/mo).   While not as robust as our web hosting for through NPR Digital Services, it offers a few specific features I needed: like running custom PHP scripts.  Specifically, I wanted DirCaster (cost: free!) which takes files in any web server's folder and makes an RSS feed out of them.  

RSS or "Really Simple Syndication" may sound familiar to you: it's the architecture that podcasting is based on.  While our local newscasts can be downloaded and listened to through a podcast aggregator iTunes...we don't expect most people would do that.  They just want to click a link and listen when the whim strikes them.

DirCaster's RSS feed of our newscast audio is run through PodTrac (cost: free!) so we can get some statistics on things.  From there, I have an applet set up with the web service If This Then That (cost: free!) that automatically sends a tweet with a link to the audio every time it detects a new file in the RSS feed.  And running a Twitter account is, of course, free.

So far this entire system cost us:

  • One old leftover Windows 7 PC.
  • $66 in one-time software costs.
  • Less than $150/year for web hosting.  

That, my friends, is a steal!  :)

So far, so good, right?

But what about adding a few tweets to break up the neverending flow of newscast tweets?

That's proven trickier.  The exact tools to do this don't really exist, so I've been trying to hack together a couple different services and kludge it all together to see if it works well enough to be used full-time.

Screencap of RIPR's Buffer automatic tweeting queue
Credit Aaron Read RIPR

First, we have (and have had for a while now for an unrelated project) a special RSS feed of all our locally-created news stories on the website.  NPR Digital Services created it for us.  In theory I can use Buffer to aggregate these stories from the RSS feed, turn them into tweets, and tweet them out automatically at specific times each weekday.  

The problem is that Buffer isn't entirely designed to do that.  It's really meant to be used in a "live assist" mode, where a person aggregates content from lots of different sources (potentially multiple RSS feeds) and then manually picks which stories to be sent out within certain time windows.  And not just to Twitter, either; Buffer works with Facebook, LinkedIn, etc - all sorts of social media platforms.

In theory, I can use If This Then That (IFTTT) to push items from an RSS feed into Buffer's automatic schedule.  But our RSS feed isn't recognized as "valid" by IFTTT's internal architecture; it's kind of picky, IMHO.

Instead I've been using Feedly to interpret the RSS feed for me.  Much like Buffer, this is something Feedly can do but it's not really the main thing it's meant to do.  So it's a little weird at times.  Once interpreted by Feedly, I use Zapier to "zap" (create an action) where every time something new in the RSS feed is detected by Feedly, Zapier adds the story to Buffer's automatic posting schedule.  Zapier is an incredibly flexible service but it's almost oversimplified; it's not easy to tell if you've really set things up to work the way you want them to work...the only way to really know if it's set up correctly is, to, well, just let it go and see what the results are over the next few days.

One stumbling block I've noticed is that while RIPR produces and posts new web stories quite often during the weekday, it does very few on the weekend.  This can get problematic if the "Buffer" within Buffer runs out before new stories start getting posted again on Monday morning.  It's been a lot of trial-and-error to figure out where the magic number of automatically-tweeted stories per day is: four per day?  Five?  Seven?  Like I said, trial and error.

Worse, Zapier and Buffer have free services but they are far, far more limited than the pay versions.  In both cases, there's a paid version that's not too $10 or $20/month...and I could live with that if I knew the paid version would do what I need it to do.  But they also have paid versions that are $100/mo or even $5000/yr.   (!!!!)   Yeah, that's a bit much.  Again, these are really flexible and powerful services, but it's overkill.  I don't need all those services and I certainly can't afford to pay $100/month just to automatically send a few tweets.  This is one thing where I've been quite annoyed with Buffer & Zapier is that they don't make it clear, at all, what functionality you do or don't get at the various paid service levels.

For what it's worth, my free trials of Zapier and Buffer are, as of this writing (Aug 5, 2017), about to expire.  We'll see if the services continue to work as desired once we're on the basic, free editions.  If they do, that's great!  If not, we'll try the lower-cost options and see how that goes.