Scott Fybush It happens every time something goes wrong with EAS: The blame game starts up right away, all over the engineering mailing lists and beyond.
In October, when syndicated morning host Bobby Bones, or at least one of his producers, played audio of the 2011 national EAS test — to help illustrate Bones’ frustration at having his World Series viewing interrupted by an EAS test the night before — it touched off yet another perfect storm.
In some markets, the local Bones affiliate happened to be an EAS primary station; so that audio was heard by EAS receivers all over the market (including, yes, at the local AT&T U-Verse headend, which prompted an initial flush of misleading media reports calling the whole thing a “U-Verse glitch”).
Depending on how each receiver was set, the result was either nothing (if the box saw the timestamp on the alert and was programmed to ignore “stale” alerts) or a further retransmission of the message (if the box was programmed to assume that even an EAN with a stale date should still be relayed, as some have interpreted the rules to require).
Should Bones or his producer have known better than to have played that audio clip, especially on a national show? Of course — and yes, there will be extra training for a while at stations all over the country, and yes, there will almost inevitably be FCC fines against Bones’ flagship, iHeartMedia’s WSIX(FM) in Nashville, and perhaps other stations that carried the show, which is syndicated by iHeart’s Premiere Radio Networks.
UNINTENDED CONESQUENCES
Will Bones lose his show over this? No, and he shouldn’t.
Because as much as on-air talent and producers need to be constantly reminded that they can’t use EAS audio, or even anything that sounds like EAS audio on the air, the Bones incident really exposed some much deeper underlying flaws in the way the EAS system is designed — flaws that almost guarantee that we’ll have another “Bones moment” sooner rather than later.
Promotional image from the Bobby Bones website
This was, after all, hardly the first time an errant bit of EAS audio has caused problems.
We’ve had incidents in recent years in which EAS data bursts (or noises that sound like them) have been included in movie trailers and even public service announcements. With millions of hours of audio content being created every week all over the country, we’ll have more such incidents in the future, too.
IDENTIFY THE CAUSE
The root of this particular problem is in the in-band nature of EAS data transmission.
The EAS decoders at the U-Verse headends, and everywhere else downstream from the nation’s EAS LP-1 and LP-2 stations, have no way right now to know whether the data bursts they’re getting are coming from the primary station’s EAS encoder or whether they’re simply random audio being played by some morning show producer who has no way of knowing that the audio they’ve just grabbed from YouTube could shut down some poor viewer’s cable box half a continent away.
If EAS must include in-band data signaling — and for now, that’s unfortunately something that’s deeply entrenched in the system — those audio bursts of data shouldn’t be able to reach the transmitter from any source other than the station’s own EAS encoder.
FIX THE PROBLEM
Here’s my modest proposal.
Any audio coming through the program chain that can erroneously trip a decoder somewhere downstream from the transmitter would also, pretty much by definition, be able to trip a decoder upstream from the transmitter. With a little bit of extra delay in the audio chain (no big deal these days, when so little radio is truly “live”), that extra decoder could, in turn, dump that audio source out of the chain before it ever reaches the transmitter to wreak havoc out in the world.
iStockphoto/gdagys For stations that could be facing hundreds of thousands of dollars in fines for erroneous EAS transmissions, or for the syndicators who shouldn’t have any EAS noises coming down the satellite to their affiliates, the expense of a fail-safe system like this should be relatively small by comparison.
(And no, this system wouldn’t catch the sort of similar-to-EAS noises that have also triggered fines, but that’s what a good traffic department should be alert to, right?)
As the next generation of EAS is developed, isn’t it time to break completely from the entire idea of in-band audio?
That 2011 national test that Bones accidentally aired demonstrated that daisy-chaining audio from station to station doesn’t work well, even ignoring the telephone-link feedback problem that messed up the audio of the test in the first place. All those weekly and monthy bursts of barely-explained data noises probably do more to desensitize listeners to the system than to prepare them to hear actual alerts when they’re issued.
We have the capability to securely deliver audio and data directly — and in a more securely authenticated manner — to individual stations and to cable headends via networks that are at least as hardened as our broadcast system. Why are we still depending on delivering that audio and data over the same programming stream that brings us Bobby Bones in the morning?
Veteran broadcaster Scott Fybush is editor of NorthEast Radio Watch (www.fybush.com) and has written for Radio World since 1999. Opinions are his own.
Comment on this or any article. Email [email protected].
