[EAS] Text To Speech issues

[Dave Turnmire]

When Text-to-speech was discussed awhile back, I had thought the only issue was how well the TTS engines pronounced certain names, etc.  But a few months ago our state has switched to CAP based alerts as its primary distribution method.  Most of our tests have attached audio, so until recently I wasn't paying much attention to the TTS issue.  Then we had some tests sent without the attached audio and....Yuck!

The problem is that apparently based upon FCC rule 11.51(d) as referenced by 3.6.3 of the ECIG CAP-to-EAS Implementation guide, the EAS decoders are essentially "reading" the script as it shows in the logs, plus any more useful information included within the CAP XML file.  My description here can't adequately illustrate how bad that works in practice and I don't believe I can attach a sample audio file to this email.   So, I'll try by providing a transcript of a recent test and you can try to imagine listening to the following in a monotonous voice with occasional mis-steps in pronunciation.  Then imagine how much you would hear before mentally or literally tuning out.

"The Civil Authorities have issued a Required Monthly Test for Bannock eye dee, Bear Lake eye dee, Bingham eye dee, Bonneville eye dee, Butte eye dee, Caribou eye dee, Clark eye dee, Custer eye dee, Franklin eye dee, Freemont eye dee, Jefferson eye dee, Lemhi eye dee, Madision eye dee, Oneida eye dee, Power eye dee, and Teton eye dee beginning at 2 20 pm and ending at 4 20 pm [followed by an unrecognizable sound that was apparently the station call sign].

[following is the actual message text within the CAP message and it came out immediately after the above]:
"This is a test of the state of Idaho emergency alert system.  In the event of an emergency this system would bring you important information.  This test was conducted from the Bannock County dispatch office in Pocatello Idaho and is now concluded."

My philosophical problem is the inclusion of all of the first part above... whose format and pronunciation is solely at the discretion of the decoder manufacturer.  The end user has no control of how all of those counties are listed or pronounced or the fact that it says "eye dee" instead of "Idaho".  The various manufacturers handle that slightly different.  For instance, one that I know of groups all of the counties for a state together and only says "eye dee" once. That, IMHO, sounds much better.  But as was pointed out to me by the first manufacturer, that may mean altering the sequence of the counties from what was originally sent and that manufacturer questions whether that is their prerogative.

In any event, the equipment vendors appear to be accommodating 11.51(d), which says in part " Analog and digital television broadcast stations shall transmit a visual message containing the Originator, Event, Location and the valid time period of an EAS message. Effective June 30, 2012, visual messages derived from CAP-formatted EAS messages shall contain the Originator, Event, Location and the valid time period of the message and shall be constructed in accordance with § 3.6 of the "ECIG Recommendations for a CAP EAS Implementation Guide ".

I should mention what will be obvious to some of you that this is somewhat of a "worst case" scenario.  For an actual alert, we would typically (not always!) have a much shorter list of counties to listen to.   And some of you don't have the large coverage areas that we do here.  Also, the wording of the Implementation Guide implies that those authors disagree with 11.51(d)... and leaves more flexibility in the event that the FCC rescinds that in the future.

If I understand the CAP-to-EAS implementation guide correctly, there is a technical solution to this... our CAP origination software can specify an "EASText" parameter, which the decoder would be obligated to use exclusively for generating the TTS (and CG for TV stations). Or... when feasible... we could attach our own audio file.  But... would either of those solutions be legal?

The message that our emergency management would put in the script (and perhaps attached audio file) is certainly going to provide "actionable" information for the public... which is going to include meaningful location info and a description of the nature of emergency and what the public should do.  They may or may not explicitly say anything about the "event time" or "event duration" since as a practical matter it is either self explanatory or perhaps of no practical use.  They certainly aren't going to put anything in there about the "call sign" of the source... who cares?  They may identify the civil authority responsible for this alert.  In any event... arguably that isn't enough to satisfy 11.51(d).  And in my opinion... what does comply with 11.51(d) is generally not in the public interest!

There is another wrinkle to address on this.  As has been mentioned in other contexts on this list... emergency management isn't regulated by the FCC!  At least not in this context.  And the broadcaster has no practical control of the content of alerts generated by emergency management.  Which leaves me to wonder if we shouldn't use the EASText parameter (or attach our own audio), obey the "spirit of the law" (as we are) in the sense of providing actionable information to the public... and basically ignore the letter of the law as not serving the public interest.  Not being an attorney, I have no way of knowing what exposure that leaves a broadcaster in.

I just wanted to bring this topic up here to see what others think and to put the issue on the table for those who may not have had to deal with it yet.  Our goal in Idaho's SECC has been to provide a means for public alerting that is as simple to use as possible for emergency management (so they will use it) and as painless as possible for broadcasters and cable companies to support as possible (so they will support it!) and provide useful information to the public in a form that they can make use of.  In my opinion, there is much to like about CAP and the ability (theoretically at least) to attach good sounding audio to a message that is delivered direct to a broadcaster is one of the great things about it.  But the current FCC rules (11.51(d) at least) seem to get in the way of those goals.

Dave