Contributing Editor Skip Pizzi wrote an in-depth, three-part analysis on a proposed electronic program guide for U.S. radio. All three parts appear below.
Next-Gen Radio Metadata: EPG
Originally appeared in RW on April 8, 2009
When comparing media offerings today, one place in which radio falls comparatively short is how well it answers the question of “What’s on?” (or “What’s going to be on?”).
Recent developments in RBDS and IBOC PSD have added “now playing” data to radio transmissions, which is a great step forward, of course. But there could be — and some might add, must be — more.
Among the latter proponents is NAB FASTROAD, the technology advocacy program of NAB, which is funding the development of a proposed Electronic Program Guide (EPG) ecosystem for U.S. radio broadcasting.
Conceptual diagram of program data flows for a radio EPG system. The centralized ‘EPG Manager’ function that collects and distributes data can be provided by a single station in a market, by a station group’s headquarters or local flagship, or by one or more third-party service bureau(s). Courtesy Unique Interactive and NAB FASTROAD The development team assembled by NAB FASTROAD for this purpose includes two well-known U.S. radio-industry firms, BIA Advisory Services and Broadcast Signal Lab, along with Unique Interactive, a U.K.-based company that has been highly instrumental in developing the EPG system used by Eureka DAB, which is already in operation in a number of European radio markets. (Full disclosure: I am a consultant to this project.)
The two-phase development project is now in its second phase, which will culminate in an on-air/online trial of radio EPG services in the Boston and Providence, R.I., area later this year.
Meanwhile, a guidance document developed in Phase 1 of the project is available for free download at www.nabfastroad.org/NAB_FASTROAD_EPG_Final.pdf.
Providing an EPG would help put local radio at parity with other digital media services, which today inherently provide substantial metadata for their audiences.
This data enables users to make intelligent choices in personalizing their content consumption from such services. An EPG could also make the radio medium “stickier,” in that it could maintain or increase audience by telling listeners what was coming up — a kind of always-on, graphical form of forward promotion.
Further, a fully populated EPG could make terrestrial radio appear like a “coordinated service” in any given market, increasing its competitiveness with other multichannel media services, while also enhancing the visibility of its broad range of content.
The latter could be particularly helpful as a method of displaying stations’ localism, which is often lost or invisible to the typical listener. Browsing a well-stocked guide would almost certainly provide opportunity for fresh discovery of content that had long been aired regularly on a local market’s stations but that had gone unnoticed even by the most frequent radio listeners there.
And of course, any future that envisions a radio with recording capability would be difficult to contemplate without the empowerment of such functionality (e.g., time-shifting) that an EPG provides.
Harder than it looks
All that said, the provision of a viable EPG for radio isn’t an easy task.
But why, you might ask, given that it’s an already well established process in the U.S. television industry? Like other radio/TV comparisons, shouldn’t it be even easier for radio? Well, actually, no — and here’s why:
First, consider that there is no tradition of comprehensive collection of U.S. radio programming data like there has been for television.
In the TV world, several companies have being doing this for decades, initially for publication in the printed guides found in newspapers and magazines. These providers have also built a business model around the aggregation and distribution of this data.
When TiVo and others developed consumer electronics devices that needed TV program schedule data, they simply licensed the data from one of these aggregators, and presented it electronically on the TV screen rather than on paper.
Although recently a few new companies (like RadioTime) have begun a similar collection of radio program data, the process and the business model supporting it are far less mature than those of the TV industry. Moreover, the challenge is much larger given that the number of radio stations in the U.S. is more than an order of magnitude greater than the number of TV stations here.
One view of actual EPG data from a DAB receiver (PURE Evoke-3, a tabletop model) receiving signal off-air in London. Photo by Nick Banks A closer look shows that there are also more radio “markets” than TV markets, and in many markets (particularly larger ones) the coverage of the market’s geographic area by its radio stations is less uniform than that of the market’s TV stations.
In other words, from a statistical perspective, it is likely that audiences in many markets may find themselves in locations where they can receive all of the market’s TV stations, but not all of its radio stations. (This is, of course, due to the different allocation procedures used for licensing TV vs. radio stations.)
Thus any attempt to define a consistent market-based set of content schedule data for radio is elusive. This issue is further complicated by the fact that radio usage is a far more mobile phenomenon than TV viewing — at least today — meaning that the list of radio stations currently available to a mobile receiver traveling in or between market(s) is changing constantly.
Next, also unlike TV, there are no “channel aggregators” in the local radio environment (i.e., no equivalent to cable or satellite TV service providers), whereby a single source of program schedule data can be inserted into a full-market, multichannel service package. This implies that radio EPG data would have to be delivered over the air in a distributed fashion by individual stations.
Finally, the capability of a radio to display any program schedule data visually also is quite variable — from zero to rich. Here again the situation differs greatly from television, where the options for resolution and aspect ratio of a full-screen EPG display are well known and finite.
Getting the EPG data to listeners is also a challenge. The amount of data required renders the delivery possible only via the digital platforms used by radio broadcasters today, meaning IBOC and the Internet.
(The NAB FASTROAD initiative has specifically targeted the development of an HD Radio EPG, but in the course of its work, the development team has worked toward a delivery-platform-neutral core system that can be applied to any and all appropriate delivery channels or services. Thus the upcoming trials are planned to include display of EPGs on one or more prototype HD Radio receivers, as well as on PCs and mobile wireless devices.)
The speed of this metadata delivery will be a key factor in determining the quality of user experience, but this is generally proportional to the delivery-channel bandwidth dedicated to EPG datacasting. So any clever methods of conserving bandwidth and improving EPG throughput are desirable.
Other tradeoffs occur in the area of receiver design, where screen size, memory requirements and power consumption are critical cost drivers for consumer electronics devices. Keeping all of these in check while still providing solid EPG performance for the user will be another challenging design exercise.
Next time we’ll look at some of the specific ideas that have been developed to date to provide optimal balance among all the issues raised here and offer a workable EPG system for the U.S. radio industry in the near future.
The Radio EPG Proposal Explained
Originally appeared in RW on April 24, 2009
Last time we introduced the concept of an electronic program guide (EPG) for U.S. radio broadcasting, and the existing challenges to its implementation. This time we’ll explore some of the recommendations addressing those inherent difficulties included in a proposed Radio EPG system developed under the auspices of the NAB FASTROAD technology advocacy program.
The development team examined a wide range of possible schemes for compilation, delivery and display of a comprehensive radio EPG, considering the entire ecosystem in its scope. Part of the team’s credentials included deep experience from the world’s only already deployed radio EPG system (in the U.K. DAB environment), providing some rare and helpful insight. Nevertheless, differences between the DAB and IBOC broadcasting models still made the U.S. effort uniquely challenging.
As is often the case, there is no single solution identified providing optimal results for all engaged sectors, but there are some likely acceptable compromises proposed that may create a successful approach.
To improve likelihood for success in this respect, a key design goal of the proposal includes maximum flexibility across multiple methods, allowing system designers, broadcasters, equipment manufacturers and consumers to choose their respective preferences while retaining interoperability. This implies a minimization of mandatory features, and a maximum of compatible options, such that the system can be quickly established yet scale adequately toward a foreseeable future where EPG provides rich, multiplatform functionality.
Of course, with any such development, ultimate success – or even initial buy-in – can only be achieved if all necessary stakeholders see a potential benefit. Thus the proposed EPG system attempts to present a balanced set of advantages for broadcasters, receiver manufacturers and consumers alike.
The proposed system identifies four methods for delivering EPG data to receivers, any or all of which could potentially operate simultaneously in any radio market.
The most “traditional” approach acts like PAD/PSD, in that each station simply transmits its own EPG information in its own IBOC datacast, using a specified portion of the HD Radio Advanced Application Services (AAS) data transmission format identified by the iBiquity EPG specification. Since in this approach, each station serves only its own purposes, the delivery model is labeled Parochial. This single EPG datastream would include scheduling information for all material broadcast on the station, however, including any multicast services.
The advantage to this approach is that it allows an EPG-cable HD Radio receiver to quickly load the currently tuned station’s EPG data (for main and all supplemental services simultaneously), but when a different station is selected, the process of loading that station’s EPG data must be repeated by the receiver. Further, if the device display were capable of showing a full-market EPG grid (as in the typical television EPG screen), the receiver would have to do all the heavy lifting of assembling and storing the EPG data from each station, one at a time, and eventually displaying the ultimate result. This will require more memory and more MIPS at the receiver, which violates one of the cardinal rules of media-format design stating that the higher-complexity requirements should always be placed at the transmit end, thus lightening the load at the receive end.
Addressing this point, a contrasting approach arranges for all stations in the market to feed their EPG data to one or more Master Stations, which carry the complete market’s EPG in their IBOC datacasts. The other stations in the market may provide a pointer to the Master Station(s), to allow receivers to know where to look for the currently tuned station’s EPG data, if it is not already in the receiver’s memory.
This allows the receiver to load the complete market’s EPG fairly quickly, and display either the full-market grid, or the currently tuned station’s data only, as the receiver allows and the user requires. To do this rapidly and seamlessly, however, the receiver will need either a second data-only tuner (as iBiquity currently envisions in its new v1.5 reference receiver design), or it will need to employ a background operation by which the receiver downloads the EPG data from the Master Stations during times when the device’s (single) tuner is not being used to listen to a station.
A variation between the two above methods is called the Shared model, which allows a number of possible configurations in which the full market’s EPG data is carried by all participating stations in the market. For example, all participating stations in the market could carry at least some data for each of the other participating stations in the market.
This would enable the receiver to quickly capture the full market’s EPG data whenever it was tuned to any station in the market. It would also not require the receiver to permanently store large amounts of data in expensive on-board RAM, since each station would continuously transmit the full market’s EPG.
A summary of attributes for the four delivery models proposed for an HD Radio EPG system. Making this approach more practical is a distinction between “basic” EPG data – which includes program titles and times only – versus “advanced” EPG data, which includes program descriptions and perhaps other related data, links, etc. This allows a variation in which each participating station might carry only the basic EPG data for all the other stations in the market, adding the advanced data for its own programming only.
The downside of the Shared approach is that it puts a lot of redundant data on the air in any given market, and therefore could be seen as an inefficient use of broadcast bandwidth. Nevertheless, it makes for the best user experience and most inexpensive EPG-capable receiver design.
Another variant of this approach that might make sense in some cases is a “group-centric” sharing, in which a multi-station cluster in a market selects one (or more) station(s) in the group to carry EPG data for all the other stations in the group. This could be particularly advantageous for a group’s AM stations, which have the least datacast bandwidth available, and yet might have the most EPG data to deliver, given their often highly program-oriented (e.g., news/talk, sports, ethnic, religious, etc.) formats.
Finally, any system designed today must acknowledge current and future levels of media convergence. Thus the proposed EPG ecosystem also includes a Network model, by which a radio receiver device that also includes Internet access (or potentially any other/future data connectivity method) can download market EPG data via an alternative (online) source. This would potentially allow consumers to receive radio programming schedules for an entire market from a single, central source, even on devices that do not currently include radio receivers (such as PCs, 3G phones, online gaming platforms, etc.).
Such functionality could also provide earlier EPG returns to broadcasters, considering that it will take some time for EPG-capable HD Radio receivers to proliferate in the marketplace, while online devices already exist in large and fast-growing quantities. So while this would not yet give the user the ability to directly tune to a program they find on an Internet-delivered radio EPG, it would allow listeners to find out when and where a particular program was being aired in their market, and then tune to it on any traditional radio.
In the next issue we will conclude our examination of the NAB FASTROAD Radio EPG proposal, and consider a few other challenges and opportunities that the system involves, and some details on its upcoming trials expected later this year.
Envisioning U.S. Radio With an EPG
Originally appeared in RW on May 6, 2009
In previous issues we’ve been looking at the NAB FASTROAD Radio Electronic Program Guide proposal. Let’s conclude our examination with some potential application issues and opportunities.
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.
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.