Most receivers support upper- and lowercase letters. Use capitalization sparingly.
Credit: Photos by Alan Jurison
In a previous article in this series about RDS, I wrote that vendors and broadcasters should support RT+, a data stream you can add to your encoding that identifies the text in your RadioText. Receiver manufacturers then would have more incentive to include it in future models.
A theme of our articles is that we all should do more to ensure that the RDS information we display is clear and concise. Many of the topics below can be applied to all metadata delivery platforms, such as streaming audio on the Internet, as well as HD Radio Program Service Data (PSD), formerly known as Program Associated Data (PAD).
ALBUM TITLE DATA
Stations with RDS, HD Radio or Internet streaming that support song title and artist should supply the album title information (if applicable) as well. Our competitors — satellite radio, Internet pure-plays and even once-feared digital cable radio — have been doing this for years. Even many of our websites and streaming initiatives show album data. Some of the latest receiver designs display the album title in a prominent position on the screen.
However, most stations in the United States do not transmit album title data. These radios display black space where the album title data should appear.
Many stations seek to be a central part of listeners’ lives through music discovery or by airing familiar favorites; so we should provide listeners with as much information as possible about the songs we are playing. You’d be surprised how many people are interested in that information.
Supporting album title data on RDS is relatively easy. There are various approaches, but for most stations, the easiest is to populate album data in the music library of the on-air playback automation system. If you maintain your own music library, this might require long hours by your PD and the programming staff, but it is well worth the investment in time.
If your automation system vendor does not have a field for album title data, push the company to include it, or use another unused field in the database if available. Additionally, some automation system vendors make it difficult to export this data from their systems to your RDS encoder. Push them to resolve this too. The only way we are going to combat these problems is to make sure the vendors who supply the industry’s products are responsive to our needs.
If you are implementing RT+ on your station, don’t forget to include tags for album title once you start displaying it.
FORMATTING & CAPS
In the early days of RDS, it was the general practice to capitalize everything, because some radios did not support lowercase characters. I have never actually seen such a radio. This recommendation is no longer applicable. Most receivers support both upper- or lowercase characters. Even in those with displays that show everything in all caps, the capitalization is handled by the unit.
Some receivers have limited displays, so it is best to keep your RDS text concise and avoid unnecessary phrases such as ‘Now Playing.’ TODAY, I LOOK AT STATIONS WITH ALL CAPITAL LETTERS IN THEIR RDS DATA AND I FEEL LIKE THEY ARE YELLING AT ME. I think it looks bad, and your listeners probably agree.
That is not to say that I totally disapprove of capitalizing. Use it sparingly. You might want to emphasize words or show excitement such as “Call NOW and WIN!”) Your opinion may vary.
SONG FIELD LENGTHS
Another annoyance is the prevalence of music libraries with truncated, incomplete or inaccurate title/artist/album data. Your PDs and their staffs need to groom the music libraries to make sure the data is accurate. Your station’s credibility is on the line.
Also, some automation system vendors still have legacy designs with short data fields for title/artist/album. If this is applicable in your case, make sure you let your automation system vendor know that this needs to be improved.
I was pleased to see that some newer releases of a major automation system now allow up to 60 characters or more in each of these fields. This is a great improvement from past designs and I recommend that all automation system vendors improve the amount of characters allowed in these fields. I have seen them in the 24–36 range; often these will cause truncation.
Shorter lengths were generally acceptable when only the on-air DJ saw the data, but this information is now used and exported to the eyes of your listeners on external sources like RDS, HD PAD, Internet streaming, website Now Playing and other endeavors. It is important we make it look as good and as accurate as possible.
Wish to learn more about the data in these fields? The National Radio Systems Committee issued guidance in the report “NRSC-R300: Program Associated Data (PAD) Field Length Study,” in November 2011. Read a summary of this at radioworld.com/links.
‘NOW PLAYING … BY … ON’
Some stations add the phrase “Now Playing,” then insert the title of the song, then “by” followed by the artist name, then “on” and the station name. I discourage this practice; so does the NRSC-R300 document, and so do many others.
First, “Now Playing” is redundant. The listener is smart enough to determine that the station is displaying information about a song; and your station should not display that information when the song is not playing.
The use of “by” is unnecessary and can lead to grammatical errors. Say, for example, you have a song where the artist is a band name such as “The Beatles.” Many programmers omit “The” for reasons of alphabetizing and organization; but if your station is using “by,” the resulting display will read “Now Playing Revolution by Beatles on Station.”
Further, in both the Program Service (PS) and RadioText (RT) fields, we are working with a limited number of characters. In the RT field, we have 64 characters. By adding “Now Playing by on,” we are wasting 22 characters or over a third of the space for each song. That is valuable real estate better used for the song’s album title name.
Also, remember that there are many types of receivers on the marketplace, and some of them have limited screen space. The receiver in Fig. 2 is an example. Most of the screen is showing “Now Playing” instead of information regarding the station or song. The receiver displays the first 22 characters well, and then periodically scrolls the rest of the information in the RT. Some designs show even fewer.
Using an example from NRSC-R300, consider a dot-matrix display of 20 characters wide. This display can handle 73 percent of Artist fields in the sample database. However, if “Now Playing” is prefixed to the transmitted text, the display can handle only 14 percent of Artist fields before scrolling.
Likewise, in the PS field, since we are working with only eight characters at a time, this adds more characters between the station name and song data. NRSC-R300 addresses this in detail and demonstrates through statistics how scarce the 64-characters we have to work with in RDS can be.
My recommendation is to remove these unnecessary phrases from your RDS systems. Your opinions may vary.
DATA, SONG TIMING
Stations that are running delays, whether for HD Radio and/or for profanity, should make adjustments in their RDS display delays. Some hardware and software products on the market have this ability. Research this and spend some time “fine-tuning” it in front of radio receivers.
If you ignore the delay adjustment, it is possible that a song’s data could show up before the song is on the air! If your station starts to play another song, the new song’s data can be displayed for a period of time while the old song is still playing, which is also an issue.
GET THE MOST OUT OF RDS
This is one of a series of occasional articles to help you get the most out of RDS. Read them all at: radioworld.com/RDS.
For stations running in real-time with no delay, this alignment process does not apply; the data is sent to the RDS encoder at the same time the song is changed. Note, as discussed earlier (see “RDS: Optimize RadioText Send Rate,” radioworld.com/RDS), there are transmission delays associated with the delivery of RadioText, and those can be adjusted by changing the RT send rate or group sequence of your encoder.
If you employ a delay of at least four or five seconds on the analog FM signal, and if you use the suggested optimized RT send rates, you can couple the new RT tightly to when the song immediately starts airing.
Next time we’ll discuss additional common RDS problems and remedies.
Alan Jurison is a senior operations engineer for Clear Channel Media + Entertainment’s Engineering and Systems Integration Group. He holds several SBE certifications including CSRE, CBNE, AMD, and DRB. His opinions are not necessarily those of Clear Channel or Radio World.
