Recently I was asked by a radio executive to assess his station’s stream and suggest improvements. Listeners had been complaining about it.
Audience reaction affects ratings and revenue, so of course this situation had to be taken seriously.
One common complaint had to do with the station’s mobile app, which had a habit of crashing and timing out after a period of time. But it was an issue for the app developer, not engineering, so I have set it aside for this discussion.
But the listeners were also complaining about commercial insertion. Their timing wasn’t right. Ads started late. Or they chopped off the end of a song or other content.
The ads are triggered by metadata, so we inspected the triggers (or “cue points”) to make sure they were arriving properly. We checked them at the output of the playback system, then at the pre-encoder, at the post-encoder (at the CDN) and at the player.
The encoder used by the station allowed for metadata to be delayed. By experimenting with metadata delay settings in the station’s encoder, we were able through trial and error to correct the issue.
Besides triggering, other functions can be accomplished using metadata. This is how “Now Playing” information is transmitted to the player, as well as station and album artwork. The beauty of metadata is that it is extensible — you define what data fields are sent, and how many. Yes, as the originator, you can define what the fields are and what they can do.
I strongly recommend you read the “Metadata for Streaming Audio Handbook” published by the National Radio Systems Committee. I was involved in the project to put that handbook together. It provides a vast toolbox to help you work with any stream. Besides explaining how to utilize metadata, it provides an incredible glossary of streaming audio terms and issues. It will be handy to any engineer who works with streaming audio.
Another problem for my client was that the audio levels of content and the audio levels of inserted commercials were not consistent. This drives listeners crazy but can usually be solved with loudness normalization.
For instance, if the loudness level is set at the CDN for the inserted interstitial (e.g. –18LKFS), make sure your produced content is at the same level. I suggest you refer to the AES Standard AES77-2023: AES Recommended Practice Loudness Guidelines for Internet Audio Streaming and On-Demand Distribution.
As this standard takes effect around the industry, streams of various stations should come to a comparable level, and listeners will no longer be shocked by a sudden jump of multiple decibels when they switch sources or when an interstitial is inserted.
Please note that the AES77 standard is the equivalent of what is specified in AES TD1008, on which AES77 is based. Some stream and podcast distributors will refer to TD1008, so do not be confused.
Loudness is commonly measured according to the BS.1770 standard. It is measured in LKFS, which stands for Loudness K-weighted Full Scale. LKFS is the equivalent of LUFS, which stands for Loudness Units relative to Full Scale. This measurement is usually in decibels or dB. There are many loudness meters out there to measure loudness level.
The stream loudness was normalized to –18 LKFS. Fixing the stream took a few days and everyone was happy in the end.
The resources I’ve mentioned above will be helpful in your own streaming work. But remember, the ultimate judges are your eyes and ears — and those of the listeners.
