Having a high-quality, reliable stream is becoming ever more important as radio listeners become more tech-savvy and technologies such as DTS AutoStage bring streaming to the automobile, helping to extend the range of your radio station.
Here are a few tips to ensure your stream is the best it can be.
Make your stream readily available.
Every week, I try to put myself in a listener’s shoes and take a few minutes to look around and see what other stations are doing, looking for good ideas and identifying things that just don’t make sense.
Right off the top, one of the things I look for is a station’s streaming links, and hopefully they are front and center on the website. I say “hopefully” because you’d be amazed at how some stations hide the link to listen on a back page, make you complete a form to get to the “listen live” button or say “find us on TuneIn.” Well, I’m sorry to say, those things make the station a real “Tune Out” in my book.
HTML5 web players that you can integrate into your website, supporting AAC streams (or *gasp* MP3) are readily available. The #1 reason your listeners visit your website is to hear your station. Make it easy for them, so they might hang around and see what else you’ve been spending countless hours building for them.
Don’t forget a mobile app too, which can put your brand at someone’s regular fingertips, and even let them talk back to you.
Process your audio for TSL, not AQH
I got the radio bug at a young age and have fond memories of annoying the local top 40 radio DJs. The ’80s and ’90s FM stacked processors of my high school years (Texar Prisms, CRL Matrix processors and heavily modified Optimods) are still fun to play with, but they belong in the tinkering room, not “leveling the stream.”
Stream codecs hate clipped audio (especially that audio coming out of the back of an old FM processor), and audio should be processed for long listening sessions (we aren’t fighting a noise floor and have good dynamic range). Your final encoded audio should be closely level-matched with the commercials inserted in your stream. I don’t like my ears bleeding when the super-loud “Sunday Sunday Sunday!” ad comes on, and your listeners won’t either. Use an audio processor built for streaming, or better yet, get a solution that does processing and encoding together in one (we use the Wheatstone StreamBlade at Cox Media Group).
Metadata matters: Check your spelling.
Thanks to that pesky smartphone, your listeners expect to see the title and artist of the song they’re listening to. This data should be coming out of your automation system, but is it correct?
We’re all guilty of typos and trade shorthand, but you don’t want your listeners questioning whether you learned how to spell, and they may not understand why the outcue or agency name in your automation system is showing up on their phone.
Your automation system or the PAD processing system you’re using for your RDS/HD Radio (you are showing title and artist on your OTA signal, right?) likely has a stream encoder-friendly output that can help fix some of these issues.
Make sure the commercials run on time: Metadata timing.
While we’re talking about metadata being correct, check that it’s being delivered in sync with the audio. Is your talk-station’s audio running through a profanity delay? If so, has the metadata been delayed by the same amount of time/buffer that the profanity delay holds?
Your over-the-air clients expect their commercials to run as approved, not upcut/downcut or airing in the middle of your host’s closing sentence, and you should be treating your stream with the same care.
Make sure the metadata is in sync with the audio that’s coming through the speakers, down to the millisecond, so you have seamless transitions between inserted commercials and your program audio. These adjustments can be made in your metadata processing system, and my favorite streaming encoder has that feature too. Sloppy transitions are annoying to the listener and don’t make you sound like the great broadcaster you are.
[Check Out More of Radio World’s Tech Tips]
Is your stream “on the air”?
Are you monitoring your stream to ensure it’s not broadcasting silence, or checking to ensure the encoder is transmitting? Did your streaming service drop the connection, or are they having a problem?
You should be the first to know this, not finding out about it from your listeners who have already gotten frustrated enough to write you an email or send you a message on X.
There are some great hardware options out there that will monitor your stream, send email alerts and allow you to monitor your metadata too. If money is tight, an internet player like a Barix Exstreamer can be wired to a silence sensor, which will at least tell you “The stream is up and there’s audio.” If you’re a little craftier, a Raspberry Pi and some freely available software packages can replicate the same solution for even less.
To MP3 or not to MP3 …
Despite being very long in the tooth, the venerable MP3 format continues to hang around in legacy devices and as a fallback in many smart speakers.
Looking at my own stations, many of our listeners are connecting with devices that can hear our AAC streams, and the AAC stream offers an audibly better listening experience than its MP3. That said, there are still a fair number of listeners connecting to our MP3 streams, enough that I’m not quite ready to toss that option out the window.
Present both options, if you’re not using an embedded web player, and your app ought to support both (start with an AAC connection first, and failover to MP3 if something goes wrong).
Choose a CDN carefully, and make sure you have backups
All this wonderful work you’re doing to make your stream the best it can be is ultimately at the mercy of your CDN partner to get it to your listener in a reliable way.
How are you getting your encoded audio to the CDN? Are there backup servers in case one datacenter goes down? Do you have a backup encoder in case your primary goes on vacation?
Legacy streaming encoders often use basic HTTP connections to get the encoded audio up to the server/CDN. These connections have little redundancy, and simple internet “blips” in the connection between your encoder and the CDN are magnified to all your listeners.
Consider upgrading to at least an RTMP (Real-Time Messaging Protocol) connection, which was built for streaming audio and video, and offers better reliability and buffering for the busy and imperfect internet. Similarly, check with your CDN to see if they have redundant servers in a geographically disparate datacenter, and if you’re able to send a live stream to both datacenters.
This simple backup measure will help ensure if one datacenter goes down (and they do from time to time), you’re not out of commission for hours on end waiting on someone else to fix things. Similarly, if you can afford it, have a backup encoder in your technical plant, ready to go when you need it. Just like your backup transmitter for your OTA signal, you don’t want to be down because a hard drive quit spinning, or a power supply gave up.
