By SCOTT FYBUSH
*
In some markets, the local Bones affiliate happened to be an EAS primary station, and so that audio was heard by EAS receivers all over the market (including, yes, at the local U-Verse headend). 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, because you never know if the station upstream in the chain has the time set correctly on its encoder.)
As you’d expect by now, the fingers of blame are being pointed all over the place, especially on engineering mailing lists. 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 almost inevitably be FCC fines against Bones’ flagship WSIX in Nashville and perhaps other stations that carried the show. (In NERW-land right now, Bones is heard on iHeart’s WBWL in Boston; fortunately for them, their small signal doesn’t play a big role in the region’s EAS daisy-chain, so we’ve heard no reports of the errant alert being disseminated widely.)
Will Bones lose his show over this? No, and he shouldn’t. While a FEMA alert to the engineering community on Friday afternoon urged, among other bullet points, to “socialize the implications of including EAS tones in the broadcast (§11.45 “Prohibition of false or deceptive EAS transmissions”) among the content providers and program directors,” we’d argue that there are deeper underlying flaws in the way the EAS system is designed – and until those are addressed and fixed, incidents like this one will keep happening.
A bit of background for those of you on the programming or management side: as the successor to the old Emergency Broadcasting System, EAS was designed, at least in part, as an in-band system. Under each state’s EAS plan, every station is assigned at least two other stations to monitor, and an EAS receiver is constantly listening to the incoming audio from those stations. Anything that’s transmitted as program audio on those stations can potentially trigger EAS receivers at stations downstream – and at cable systems that monitor for EAS activations, too.
That’s what happened here: a piece of audio that was never meant to do anything other than illustrate the host’s rant (Bones was unhappy that a different EAS activation had interrupted him while watching a World Series game the previous night) ended up triggering a daisy chain of stations and cable systems down the line, entirely by accident, simply because the audio included a data burst that carried the “EAN” code from almost three years earlier.
Yes, by all means there should be better education in the programming community that you simply do not play EAS audio over the air, ever. It’s a lesson Bones and his staff are learning now, and we’d bet the word is getting out pretty widely throughout iHeart and other big broadcast groups, too.
But this is 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 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. Doesn’t it make sense to lock the system down at the other end, too? If EAS must include in-band data signaling, those audio bursts of data shouldn’t be able to reach the transmitter from any source other than the station’s own EAS encoder. Somewhere out there, a clever EAS equipment provider out to be able to design a box that can stop the audio of EAS data bursts from getting down the audio chain to the transmitter and causing this sort of chaos…right?
And as the next generation of EAS is developed, it’s probably 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. We have the capability to securely deliver audio and data directly 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?
Read this week’s entire NorthEast Radio Watch column here!
THANK YOU TO ALL OUR CUSTOMERS!
The 2024 Tower Site Calendar is very, very nearly sold out.
We are so happy that we have so many supporters after nearly a quarter century of doing this. We especially appreciate the nice comments we receive from our longtime buyers.
We will not be reprinting this year’s calendar, so if you want one, order it now. We still have some previous years available if you need to fill in any gaps.
In the meantime, we still have some great broadcasting books. Check out the store!