Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now


Take a Page From the PSD Cookbook

Think of it as tiny scrolling billboards for your station: fields of text that appear in a window on your listener’s HD Radio receiver.

Think of it as tiny scrolling billboards for your station: fields of text that appear in a window on your listener’s HD Radio receiver. The industry term for this text stream is Program Service Data or PSD. At a minimum, a PSD stream can describe what’s currently playing on the air — a basic consumer expectation in the digital media world.

(click thumbnail)Fig. 1But PSD can be much more. Essentially a new text-only format, it can be used to support a variety of other priorities: underwriting/advertising, membership (for public stations), promotion, branding, public service information and more. Think stock quotes, sports scores, weather, traffic or Amber Alerts.

Want to see for yourself what PSD can do? Check out the Virtual PSD Demonstration at to see a range of local PSD applications, in this case for public radio. You’ll see how they correspond — or, perhaps more important, don’t have to correspond — to what’s currently playing on-air.

PSD truly represents a new dimension of local service. The PSD Consortium, led by Public Radio International and funded by CPB, was created to help facilitate the efficient and effective launch of PSD across the public radio system.

This article provides a quick guide to PSD issues at the station level, applicable to both commercial and public stations, and to the work the Consortium is doing to help public radio stations address them.

The centerpiece of our work is our PSD Cookbook, based on 18 months of research, testing and conversation-managing. You can find it online at; you’ll see many references to specific Cookbook chapters throughout this article.

How PSD works

(click thumbnail)Fig. 2: Overview of how PSD is, or soon will be, generated.Like your on-air inventory, your station’s PSD inventory will need to be approached strategically from both a workload perspective and a clear programming philosophy.

Because PSD strategies potentially affect the work of every department, it’s important not only for engineering and ops staff but also for station management, programming, development/sales and Web staff to be up-to-speed on PSD basics.

Let’s start with a simplified overview of how PSD is, or soon will be, generated; see Fig. 2.

Just like audio programming, PSD will be generated from a variety of sources:

  • National program producers will provide program- and segment-level descriptive text to accompany their audio programs
  • PSD for your local programs will need to be created by station staff, just as similar descriptive text is currently created for your Web site
  • PSD text that is not directly related to programs may come from the outside (a Web site, for instance) or from internal sources (e.g., your marketing department)

At the heart of PSD implementation is a piece of equipment that we refer to as a Text Scheduling Unit, or TSU.

Think of it as an automation system for data, instead of audio. This device receives PSD text from your audio automation system or from other sources. The TSU stores that text and schedules it to be broadcast at the appropriate time in synch with your audio broadcast.

According to your schedule, the correct PSD is then transmitted to the PSD Importer, where it is joined with other data such as PSD for second or third audio channels. This “bundle” is transmitted to the Exporter, where it is matched up with the audio stream(s) and sent on for broadcast.

(click thumbnail)Fig. 3: At the heart of PSD implementation is a piece of equipment that we refer to as a Text Scheduling Unit.On the consumer end, the HD radio receiver separates the digital broadcast into the audio stream and the text stream. PSD text appears in a window on the receiver along with Station Information Service (SIS) text. At present, PSD text is limited to two fields of 64 characters each; it can be updated as frequently as you’d like. SIS text is static, and is typically used to display call letters and frequency. You can see both the SIS and PSD fields on the graphic at the top of this article.

What are the issues?

So what does it take to implement PSD?

The issues sort themselves into four main areas: the necessary technology, programming code, expense and staff time.

Technology Interface: This is, of course, the area that is changing the most rapidly; it’s tough even for the Consortium members to stay on top of changes that are sometimes occurring daily.

But as of this writing, two pieces of equipment are necessary at the station level to make full PSD implementation possible and manageable: an automation system and the TSU (which may simply be a component of your current automation system or may be a stand-alone solution such as Broadcast Electronics’ The Radio Experience or Unique Interactive’s ManDLS).

As with most technology, the hardware and software needed to get this work done are likely to become more efficient, user-friendly and inexpensive as the technology evolves. You can read a more detailed discussion of technological issues in the chapters “PSD Implementation Overview” and “Station Services Implementation” of our PSD Cookbook.

Programming Code: A critical component of public radio’s PSD food chain will be the widespread adoption of a consistent but flexible text format that producers and stations can use to create PSD, and that automation systems and TSUs can read.

PRI has taken the lead within the PSD Consortium in proposing a specific “grammar” for fields in XML (a common programming language) to cover a wide range of potential station uses, not only program title, segment, song, artist, etc. but also underwriting/advertising spots, forward promos, pledge messaging (for public stations), and more.

We’re currently in enthusiastic conversation with automation system manufacturers, who assure us that their systems can currently (or will shortly be able to) interpret our recommended XML specification.

Others in the PSD Consortium are playing key roles in supporting this recommended coding system. Public Interactive has created a prototype extension to its PI Composer tool to deliver program-level PSD for station schedules, as well as song-level PSD for PRI’s classical music service Classical 24, in the XML format. PRX has successfully prototyped a modification to its producer interface to generate PSD in our proposed XML spec for all of their programming offerings.

Tools Developed through the PSD Standards Project:PRI-PSD Suggested Program Fields
Standardized, open-license, XML-based text fields for data associated with public radio programming. The basis for most of the other tools below.

The PSD Cookbook
Recommended implementation practices for PSD in public radio.

Virtual PSD Demonstration
Flash animations demonstrating more than 60 unique PSD events along with corresponding audio.

The PSD Wiki
A fully interactive Wiki for stations to share PSD implementation tips and tricks.

PSD Financial Template
A downloadable MS Excel spreadsheet for estimating PSD implementation costs.

PSD XML Widget
Downloadable tool converting local PSD promos, underwriting and PSA messages into PRI-PSD.

XML Schema and Document-Type Definition Tools
Automated tools to “vet” XML PSD messages for compliance with PRI-PSD.

C24 and PI Composer Tools
Tools from Public Interactive allowing Web-based delivery of station-specific PSD with hour-by-hour, segment-by-segment and song-level detail.

Metadata Mapping Tool
Correspondence of fields among PRI-PSD, PBCore and ID3; designed to foster interoperability among various PSD schema and other external applications.

PRX Tools
Prototype delivery of content to stations that includes PRI-compliant PSD as companion data to audio files.

Topline Legal Overview for PSD
Overview of potential legal issues for PSD (copyright, data source licensing, database protection , FCC issues, etc.).

PRSS/Content Depot Tools
Shortly after the full launch of the new Content Depot, the Public Radio Satellite System will offer tools to collect and deliver PSD data (i.e. cartchunk-based PSD).

Broadcast Electronics “The Radio Experience” Producer Tools
Forms-based producer tools for creation and station delivery of PRI-PSD for PRI’s The World and other national programs.See the sidebar for more tools developed by this project.

You can view our entire proposed XML specification (along with our recommended practices) on this Web site. See the “Suggested PSD Field Descriptions” chapter of the PSD Cookbook for program, segment and song-level fields, and the “Station Services Implementation” chapter for fields not related to programs. If you are not likely to be involved yourself in the coding of text fields (though see Workload, below, because you might be surprised on this one), we hope you’ll encourage the appropriate colleagues at your station to take a look at this XML specification and let us know their thoughts and concerns.

Direct Cost: This is one of the biggest questions, especially for station managers: What is PSD going to cost us?

Let’s cut to the chase: An “entry-level” stand-alone TSU costs about $500. An automation system costs anywhere from a few thousand dollars to tens of thousands, depending on the features you require. Additional software required to support TSU functionality can be added to many existing automation systems. At this time, such add-on software modules cost from $500 to $2,000.

Obviously, high-end equipment and software for very advanced applications cost more, but that’s within your control.

Workload: Ah, the other big issue. The good news is that the workload for PSD is largely scaleable, based on the PSD applications you choose to implement. The bad news, if you choose to look at it that way, is that the most sophisticated uses of PSD clearly are going to be time-consuming and may require the involvement of departments beyond engineering and ops in the coding and scheduling of text.

For the most basic level of PSD — say, program/segment information for national shows and program title information for local programs — very little time is needed. We’re hopeful that with an XML language in place, top-line PSD information for the national shows will be ready to “plug and play” shortly. After investing in a TSU, station staff will simply enter in their program schedules and the appropriate descriptive text once, since program schedules are static (though obviously if programs in the line-up change, the TSU will need to be updated).

Segment-level information for national shows will obviously be the next hurdle for program producers, but the workload described above should not change radically for stations as this level of PSD information comes online.

Greater detail in local PSD content, however, is a different story.

Song/artist-level information for local programming, for instance, may take a significant ongoing investment in staff time since not all media sources provide compatible descriptive data (older CDs, for instance); a fair amount of PSD content would need to be hand-entered. The introduction of PSD for forward-promotion or fundraising/advertising-related purposes adds yet more levels of detail and complexity for staff.

We predict that other departments at the station beyond engineering and ops will need to dedicate staff time to learn the XML spec and the TSU scheduling process, in order to take over the “care and feeding” of the PSD inventory that relates to their department.

But we’re here to help public radio stations with that, too. Since writing XML by hand is time-consuming, the Consortium is working on a user-friendly, Web-based tool (in beta version) for converting your desired PSD text into our recommended XML format automatically, making cross-departmental involvement with PSD a far more practical option. Please see our PSD Cookbook chapter “Station Services Implementation” for more detail on the potential impact of XML coding on station workflow.

You’ll need to devote a certain amount of cross-departmental staff time, just as you do with your on-air inventory, to determining the appropriate proportions of PSD “avails” for each station priority (such as forward promos or underwriting/advertising credits). You’ll also need to determine the appropriate volume of PSD messaging overall that you believe remains consistent with your station’s values. After all, PSD is programming content, just like the content that goes on your air and on your Web site.

Are we ready to launch?

As a system, public radio is close. Some stations are “hand-hewing” their own systems for PSD, but that shouldn’t be necessary for too much longer.

As the final product of our CPB-funded project, our PSD Cookbook of recommended operating practices is designed to make it possible for any station to launch basic PSD within six to 12 months. We hope our XML specification is well on its way to becoming the industry standard (voluntary, of course).

But are you ready to launch PSD? That is, of course, your call. The more ambitious your PSD goals, the more complicated the implementation becomes. But we hope that you’ll make it a priority to begin providing at least a baseline of text information as soon as possible. Getting started is inexpensive, relatively easy and very important. You can always get more sophisticated over time.

Please read through and comment on our PSD Cookbook documents, and — most critical of all — start the conversation at your station about PSD and your listeners. The biggest PSD mistake you can make, we believe, is leaving a blank screen on your listener’s radio.

The PSD Standards Project is a CPB-funded initiative to develop and define a consensus vision for first-generation PSD services on public radio stations, and to investigate, develop and promote a set of best practices and voluntary standards for the system. Research and testing is conducted by the PRI PSD Consortium: Public Radio International, Public Interactive, Public Radio Exchange, NCAM/PBCore, WGBH/Boston, KUVO/Denver and Chicago Public Radio. Visit the project site at

E-mail the author at [email protected]. RW welcomes other viewpoints at [email protected].