In previous issues we’ve been looking at the NAB FASTROAD Radio Electronic Program Guide proposal (read Part 1 and Part 2). Let’s conclude our examination with some potential application issues and opportunities. (As noted prior, I am a consultant to this development effort.)
First, let’s look at some concerns that broadcasters might have in putting an EPG system into use. A primary issue involves the additional staff burden that compiling and feeding data might create. To minimize this problem, it will be helpful for radio automation/playout (and perhaps also traffic systems) to feed existing data to the EPG system via some sort of consistent or standardized interface.
Other worries include the continuous care and feeding of multiple publishing outputs to which each station would regularly want to deliver its EPG data, and any embargo of proprietary programming data that a station might want to enforce prior to release.
At your service
These matters are best handled by the creation of a service bureau for EPG management.
In this scenario, stations would send a single stream of data — via one of the selected “standard” interface formats noted above — to a single, external organization, which would in turn reformat and deliver the EPG data to all desired publishing media.
This would include sending the data back to the station — or to another appropriate station (or stations) in the market — for insertion into the HD Radio EPG datacast stream there, as well as any online portals providing radio EPG services for the web and mobile/wireless delivery.
Agreements between stations and service bureaus could also set protections and release schedules as necessary to embargo data in cases where program schedules are combined and delivered over multiple (potentially competing) stations in a given market.
The NAB FASTROAD Radio EPG proposal envisions an open marketplace by which one or more service bureaus might interoperate. Alternatively, a station group might elect to establish its own service bureau for its stations. In any case, the service bureau would alleviate a significant burden for ongoing operation and management of EPG data, allowing stations to provide only a simple, raw data feed, and let the bureau do all the heavy lifting of formatting, error-correcting and distribution to multiple publishing agents (the population of which would likely change over time as popular portals came and went).
Such a service bureau model is in operation for Radio EPG in the U.K. DAB environment, and similar processes are already implemented in the U.S. for scrubbing and tagging of RDS and HD Radio program-associated data. The EPG service bureau would be a natural outgrowth of this metadata architecture.
The market problem
You may recall that several of the EPG delivery proposals discussed last time involved the transmission of a pre-aggregated set of program schedules for some or all of the stations in a market. This would allow receivers quickly and easily to obtain the entire EPG for the market in a single datacast, as opposed to collecting it piecemeal by gathering each station’s data one at a time.
Consider the consequences of this in the real world, however. Unlike most terrestrial TV allocations, radio stations’ coverage zones are often not uniformly distributed over a given market. Various classes of both AM and FM stations provide quite different coverage, not to mention the many drop-ins, short-spaced, adjacent-market and directional variations that exist.
(click thumbnail)
The table lists a few of the uses suggested by the NAB FASTROAD Radio EPG proposal, including the relative memory requirements and display characteristics required. For the latter, “Low” = 1 or 2 line text display (e.g., handheld phone form factor); “Medium” = 3 or 4 lines of text or small graphical display (e.g., PDA or small tabletop receiver); “High” = 5 or more lines of text or large graphical display (e.g., in-dash or back-seat car video, large tabletop receiver, or home theater). Thus a single “market EPG listing” might include many stations that are not currently available at a given listener’s location in that market area. This could provide a poor user experience in which the listener sees a desired program on the EPG, but then tries to tune to it (or worse, sets a recording of a future program), but finds the channel unavailable — or at least too weak to be listenable. Conversely, there may be stations that are available to a fringe listener from a neighboring market that are not shown on the “market EPG” currently loaded in the receiver.
The mobility of radio makes this problem even worse due to its dynamic nature. Some stations on the EPG that are available at the start of a drive across town may not be available at the destination — and vice versa. Thus the EPG proposal suggests a few methods by which a receiver can attempt to dynamically filter (by geolocation or otherwise) market-level EPG data to provide as accurate as possible a listing to match current reception conditions.
Implementation costs and benefits
The proposal also attempts to minimize costs of EPG implementation for both broadcasters and receiver manufacturers. The Service Bureau model above, coupled with optimization of automated processes and the necessary interfaces, are suggested to reduce broadcasters’ burden.
For receivers, there is a potential tradeoff between cost of EPG implementation and user experience, so the proposal suggests various methods of scaling EPG display to multiple receiver display types (ranging from one or two lines of text to a full graphical/video display), and includes several schemes for latency reduction (dual tuners, always-on or scheduled-background EPG data collection, and non-volatile RAM).
All of these either incur additional costs or run up against other design constraints, however. The proposal nevertheless envisions methods of implementing at least baseline EPG service with minimal additional cost burden to an IBOC receiver or an Internet-connected device.
Several potential business models are also enabled by the EPG, including possible revenues earned by carriage of other stations’ EPG data, promotional opportunities in dynamic EPG text, or even inclusion of text or graphical ads on the EPG screen (as found on some TV EPG systems).
Use cases & trials
The NAB FASTROAD EPG proposal spells out a variety of potential uses contemplated for stations’ application of the service. A few are reproduced in the table here.
In general, these include all the features one might expect in a traditional, TV-like EPG, plus some interesting, radio-specific variants, such as “Follow the Program.”
Like RDS, it is imagined that a broadcaster could implement many of these features, whereas a given receiver may only display a few of them, and with varying combinations of features implemented on different devices. Also like RDS, the level of such selective feature implementation may expand over time.
To break through the chicken-and-egg problem, it is recommended that broadcasters lead the way by starting with a fairly rich implementation, and wait for receivers to catch up. The ability to present a relatively complete display of features immediately via a PC browser client may help speed the EPG feature-growth process in IBOC receivers or other devices, and provides immediate value to the broadcaster regardless of dedicated-device development time.
On-air trials of the service in the Boston and Providence, R.I., markets are scheduled for later this year. Many broadcasters in those markets have already indicated their interest in participating, and prototype receivers are now being developed, along with other software and interfaces required.
Look for coverage of this important demonstration in upcoming issues of Radio World.
Skip Pizzi is contributing editor of Radio World.
