PSD Implementation Overview, Version Beta 0.2
Request for Comments
This document provides an overview of issues surrounding the implementation of our recommended baseline PSD service.
The following discussion provides detail on the implementation of our recommended baseline PSD spec within the known limitations of existing technologies, and describes issues surrounding more advanced PSD applications.
2. Required Infrastructure
It is, of course, desirable to provide text services beyond 'song title' and 'artist.' 'Song title' and 'artist' are more or less arbitrary labels for the two fields, and any text can be inserted into them. The issue is how to manage and insert text into these two fields. This function is carried out by what we will refer to generically as a text scheduling unit (TSU). BE refers to their product as 'Radio Data Management Software,' while Harris calls theirs a 'Content Management Platform.'
The Text Scheduling Unit (TSU)
There are a variety of units available that fulfill this function, with entry-level units beginning at around $500. These can be either stand-alone units or software and/or hardware extensions to larger asset management and/or station automation systems.
Basic TSU functionality
The basic function of a TSU is to take text from a source and insert it at the correct time into the HD Radio stream. An entry-level unit should allow a user to input a weekly program schedule along with corresponding text for the various programs, which the unit would play back at the scheduled time. This approach has the advantage of being essentially a 'set it and forget it' solution. Text data would only need to be changed when the station's programming changes.
Advanced TSU functionality
In addition to sending out its own internally scheduled text, many TSUs are capable of inserting text drawn from external devices such as automation systems and CD players. Many TSUs can also insert text (if formatted correctly) from sources such as a station's local area network or remote locations across the web. A simple implementation would be 'song title,' 'artist,' and 'album' information from a station's automation system. A TSU also could be programmed to (for example) alternate between displaying this information and the name of the program and the host. (Remember, while only two fields can be displayed on a receiver at a time, any text can be cycled in and out of them.)
Another function, and an important one, is the ability to interface with external systems such as PRSS. Currently we are testing insertion of PSD documents formatted according to the suggested PSD program field descriptions inserted into the text field of the cart chunk block of audio files provided by PRSS. This will allow for transmission of PSD information along with audio files via PRSS or other external transports and should allow for seamless insertion of PSD into the broadcast stream.
back to top
3. Station Services
Stations have expressed a desire to provide other text such as (among others) pledge and underwriting messages. This is addressed in greater depth in the document Station Services Implementation . However, for the purposes of this preliminary overview we can point out two general methods.
The first method would be simply to program these messages individually to display at the correct time on the broadcast day. However, this is would require that they be hand-entered by engineering staff each time there was a change. While at a basic level this would probably be manageable, as PSD grows in volume and importance this would eventually lead to an unacceptable burden on engineering personnel.
A more efficient arrangement would be to create an external file that contains, for example, underwriter information. This file could be maintained by station development and modified by them as needed. The TSU would then reference this file on an as-needed basis and insert whichever underwriter announcement the development staff had specified for that time period.
back to top
4. Real-time Services
Many stations have expressed their desire to display information such as news headlines, weather updates, stock market reports, or other real-time data on their listeners' receivers. As these by definition are constantly changing, the TSU would need to access the information in real time. This is addressed in greater depth in the document Real-Time Services Implementation , but here are some brief thoughts on likely implementation issues.
Initially, for production staff, the main challenge would probably be finding text that is suitable for use in terms of both content and format. Content would have to be either free or easily licensed, and it would have to be in convenient 64-character chunks that could be displayed on an HD Radio receiver. As the installed base of receivers increases, it is not unreasonable to assume that various entities within public radio, such as NPR News, or outside public radio, such as the Associated Press or Accu-Weather, may begin to provide commercial text services specifically formatted for HD Radio.
On the engineering side there are also issues to be addressed. There would need to be some kind of standardized container for this specific type of PSD, and station TSUs would need to be able to read it. If text were to be drawn from a remote location on the internet, there would be issues of both security and reliability of connection. A likely solution to these issues would be to copy feeds to a location inside the station's LAN so no direct access to the TSU would be possible.
While there are some issues to work through with real-time PSD services, we think that there is a very reasonable expectation that such services will begin to appear in the near future. A number of commercial ventures are already working in this space, and we expect that in time this type of rich data will be expected by listeners.
5. Web Integration
Integration of web content with HD Radio text services, and vice versa, is relatively simple. Many TSUs have the ability to 'publish' their output to an XML file or other known text format that can be used by the station website for 'now playing' information. Additionally, if we assume that text is in known XML format, much of the data available to the TSU is also available to the station's website. By the same token, content on a station website could be accessed directly by the TSU for broadcast, provided it adheres to the 64-character limit or can be modified in an automated fashion for use by the TSU.
6. Conclusion
As the related technologies and marketplace continue to evolve, we expect these issues will be addressed by every station in the system. For the purposes of continuing this conversation and allowing stations to share information we have set up a PSD Wiki . We invite you to publish your experiences in implementing PSD there, as well as to read the experiences of others. We look forward to hearing from you.
