.                                               

Is finding a replacement for your current broadcast monitoring and compliance solution on your to-do list? According to a recent survey we conducted, 73% of respondents are looking to do so by the end of 2020. Of those looking to replace their current broadcast monitoring and compliance solution by the end of 2020, 75% are specifically looking for a Volicon replacement (meaning, they’re using Volicon today). 

During your research, there are several questions you should ask yourself about features. (For tailored questions you should ask based on your organization type, read how three broadcast industry professionals—one at a cable company, the second at a local TV station group, and the third at an MVPD—would evaluate their next broadcast monitoring and compliance solution). 

1) Do I need loudness monitoring?    

    The loudness graph in SnapStream Monitoring & Compliance. 

In the United States, the CALM Act regulates the audio of TV commercials in relation to the TV program they’re accompanying. Having automated tools for finding loudness problems and being alerted whenever there’s an issue is immensely helpful. 

2) Do I need audio metering? 

    The  Multiviewer in SnapStream Monitoring & Compliance—with audio meters turned on. 

You might need to monitor audio levels without listening to the audio. If so, make sure your new solution lets you quickly determine audio levels for multiple feeds at a glance.  

3) Do I need closed captioning monitoring? 

    Clip export with burn-in of closed captioning in SnapStream Monitoring & Compliance. 

The FCC dictates that TV stations, cable and satellite providers, and program producers are responsible for closed captioning compliance. If your organization is found to be out of compliance, the fines can add up—the FCC considers each episode of a program with defective captions to be a separate violation. It’s vital to have a tool that can help you verify that your closed captions ran as they should have. 

4) Do I need to analyze ratings? 

     The ratings display graph in SnapStream Monitoring & Compliance. 

If you get ratings data from Nielsen or other providers, you can import that data to help you visualize it and analyze ratings performance for your content. For example, you can compare how different channels perform over specific times and dates to gain additional insights, such as whether you might have gotten low ratings on one channel because the majority of your viewers were watching another channel during that time period. 

5) Do I need ratings audio watermark monitoring? 

    An alert from SnapStream Monitoring & Compliance about a missing audio watermark. 

Audio watermarking is an important part of having accurate ratings data. If your organization uses ratings audio watermarks (such as Nielsen audio watermarks), it’s important to have a tool that can alert you if those watermarks are missing.

6) Do I need SCTE-35 message monitoring? 

SCTE-35 message monitoring in SnapStream Monitoring & Compliance. 

If you work at an MVPD, you’ll want to be notified if there aren’t any commercial messages in the stream. If it gets to the point where a broadcaster sees an ad not run, the broadcaster will contact you saying they didn’t get an avail message for that ad. Then, you’ll need to be able to easily jump to the date and time in question to look for the splice_insert for that particular avail.

7) Do I need as-run log integration? 

     As-run logs in SnapStream Monitoring & Compliance. 

If you need to prove to advertisers that their ads ran, it’s important to have a tool that lets you easily find specific ads in the as-run logs, create clips, and directly email advertisers those clips. 

With SnapStream Monitoring & Compliance, you can easily migrate your as-run and Nielsen ratings import configurations from Volicon. SnapStream Monitoring & Compliance is the official Volicon transition partner and  has solutions for loudness monitoring, audio metering, closed captioning monitoring, ratings monitoring, audio watermark monitoring, SCTE-35 monitoring, and as-run log integration.. 

This is the first blog post in our series, "Behind the SnapStream Monitoring & Compliance Feature." 

"With SnapStream, instead of broadcast engineers having to manually look for the loudness problems, the problems will come and find them." — SnapStream developer Paul Place 

                .                                            The loudness graph in SnapStream Monitoring & Compliance.                                          

Key Takeaways

1) When they were building the loudness feature in SnapStream Monitoring & Compliance, developers Paul Place and Tim Parker had extensive conversations with Volicon users. 

2) During those conversations, they learned the major pain points Volicon users had with the product—such as having to manually look at the loudness graph daily.

3) In turn, they built a solution with an emphasis on exception based monitoring. 

When they were building the loudness feature in SnapStream Monitoring & Compliance, developers Paul Place and Tim Parker spoke to multiple prospective customers. They dug into what in Volicon worked for them, and what didn’t—so they could make loudness monitoring in our own product comprehensive and user-friendly. 

They recently discussed their journey developing the loudness feature. 

SnapStream developers Paul Place (left) and Tim Parker (right).       

SnapStream: What research went into building SnapStream Monitoring & Compliance’s loudness monitoring features? 

Tim Parker: We started with Volicon. We took a look at was in the Volicon UI, and that gave us a bunch of hints on where we needed to start our research. 

When you open up the Volicon UI, you see things like ITU-R BS.1770 mentioned, or ATSC mentioned. Once you start looking at one of those documents, you realize there's a chain of documents that fit together. For the United States, it starts with the CALM Act, which then points to ATSC A/85 RP, which then points to the ITU-R BS. 1770 reference. 

We spent time doing extensive research on loudness specifications and how loudness is computed. We did it this way because we didn't just want to follow what others had done without knowing how and why it worked. We wanted a deep knowledge of what loudness really is so we knew that the product we planned to build would work the way our customers expect.

You can easily look for loudness peaks in SnapStream Monitoring & Compliance's loudness graph. 

What insights did you gain from the conversations you had with Volicon customers? 

Paul Place: We focused a lot on how they were using Volicon. The Volicon UI is kind of confusing because there's a number of things they present that aren't in the standard. Were customers using short interval computations, for example? What are they, why do customers care? Volicon also has long interval integrated value computations. What are they, why do customers care? 

Interacting with customers and understanding their workflows helped us understand these features and pinpoint what was actually useful for them. 

For example, we put the short interval values into our product because it made sense to us—they allow the customer to do things like select the end of a program segment and figure out what the integrated loudness is for just that commercial. 

In other words, one of the biggest use cases for our customers is: is something too loud? The offender is usually a commercial. 

What happened with Volicon is that they sort of accrued features over time—some of them more useful than others. There's a lot there that we couldn't find anybody using.

Parker: It's an interesting ecosystem because there's basically two layers at play here. There's the layer of automation that ensures the loudness is normalized before it goes to the customer's set top box. 

And then we come in at the end of the chain, after it's been broadcast to the viewer. We're verifying that yes, this loudness is normalized. So when a viewer complains that something is loud, a broadcast engineer wants to analyze what went out to that viewer and see where it was loud. 

That helps the broadcast engineer identify what part of that chain—before it went out to the viewer—is not working properly. Broadcast engineers have devices and software that make sure that loudness is normalized, but sometimes they get out of spec or they stop functioning properly. We're the last step in making sure that everything is working properly for them.

Clip export with burn-in of loudness data in SnapStream Monitoring & Compliance.

What were some major pain points Volicon users had that you both addressed? 

Place: We started to see a pattern of these broadcast engineers being reactive. Volicon didn't really offer a good means of identifying program segments that were out of compliance. One broadcast engineer we spoke to would just scan and look at the peaks and valleys on the loudness graph. When he saw a peak, he would zoom in to see if there was a problem. 

He had to go through this very manual process daily. Every single morning, he got in and he had a checklist of things to do. One of them was to look at the loudness graph for any problems. 

We knew we could do better than that in SnapStream Monitoring & Compliance. We’re giving broadcast engineers automated tools for finding the loudness problems and alerting them. With SnapStream, instead of broadcast engineers having to manually look for the loudness problems, the problems will come and find them. 

Volicon had an alerting system, but it was difficult enough to use that nobody we talked to used it, at least for loudness monitoring and compliance. Volicon users said they got a lot of alerts that they had to sift through to find the things they cared about. That made it not useful. 

Loudness report in SnapStream Monitoring & Compliance. 

SnapStream Monitoring & Compliance has a loudness graph and clip export with the option to burn-in loudness data. It also generates loudness reports. Could you give some more details on each? 

Parker: I've seen screenshots of other loudness tools and they generally do just the report feature, or you get a spreadsheet with numbers essentially. 

I think the way we present the loudness graph in the UI makes it easy for users to interact with and scrub the data—versus having a spreadsheet, which is limited in what it presents. 

Place: I think the visual indicators are very useful. For example, looking for peaks on the loudness graph. Say you have a day’s worth of data. You can easily see if a part of your feed fell above the maximum loudness target, and then be able to drill down and learn more. 

We’ve put a lot of engineering effort into making the loudness graph usable and responsive. You can zoom in and zoom out, for example. 

Parker: The clip export with the option to burn-in loudness data gives broadcast engineers evidence they can send to someone—for instance, to a colleague, saying “Hey, you need to fix this. Here’s the data.” 

And the goal of the loudness reports is to help users close to loop, so to speak. It’s a way for them to present proof to the FCC or another external stakeholder. 

With SnapStream Monitoring & Compliance, you can monitor your feeds for regulatory compliance and advertising proof of performance. Our solution includes loudness monitoring, closed captioning verification, audio watermark detection, and more. SnapStream also offers tools for searching TV; sharing TV clips to Twitter, Facebook, and more; and sharing clips of live events to social media in real-time. 

                                                                                                                                                                                                                       Pixsooz/Shutterstock

While watching TV, have you ever heard the volume increase when your show jumped to a commercial break?

The volume increase could have been the result of systems that hadn’t normalized the content based on the loudness.

Citing industry officials, the Los Angeles Times reported that due to the switch to digital TV in the United States in 2009, “the higher fidelity sound made the commercials seem even louder.” In 2006, the ITU-R had created a loudness algorithm (referred to as BS.1770-#, which nowadays has five variants) to help make sure commercials were not blaringly louder than the programs they were accompanying.

That algorithm makes “Loudness Units relative to Full Scale” (LUFS), also known as “Loudness, K-weighted, relative to Full Scale” (LKFS). LKFS is technically an amplitude level, but it’s not just the measure of an electrical signal. It’s an attempt to measure how humans perceive the loudness of broadcast audio.

This graph represents the filter applied to the raw audio input so it can be adjusted to compensate for how humans perceive the loudness of different frequencies. K-weighting is part of the equation used to determine the LKFS value. It has two parts— the first is weighting different frequencies based on how loud they’re perceived. The second is modeled after the “acoustic effect” of the human head.

Here’s an analogy to help you understand LKFS: audio level is to LKFS what temperature is to wind chill temperature (or heat index). Humans don’t perceive low frequencies as sounding as loud as they actually are, but they perceive high pitched sounds to be louder than they actually are. That’s why high pitched sounds have a higher K-weighting.  

The loudness algorithm the ITU-R created was not implemented in the United States until a few years later. In 2010, Congress passed the CALM Act. The law came into effect on December 13, 2012. It stipulates that in relation to the TV programs they are accompanying, all commercials must have their average loudness adjusted to be within a fairly narrow range of a fixed target. The law only applies to television programming—it does not apply to radio or internet programming. 

For compliance, the law points broadcasters, cable operators, satellite TV providers, and other multichannel video programming distributors to the ATSC A/85 RP.

A/85 RP stipulates the use of ITU-R BS.1770-1 in the United States. It also recommends the adoption of a fixed target loudness of -24 LKFS. Annex I.7 of the ATSC A/85 RP states that there should be a fixed target loudness of -24 LKFS, + or - 2 dB.

A/85 RP also notes requirements other than loudness, one example being dialnorm. Dialnorm means “dialogue normalization.” Dialnorm specifies the average dialogue level for audio in absolute terms. Say you’re going from your main program to a commercial. The main program features soft-spoken people, whereas the commercial features loud people. On playback, the consumer receiver would automatically modulate the low dialogue up, and the loud dialogue down.

A visual representation of how dialnorm works with a consumer cable box.

Luckily, as Dave Moulton wrote in TV Technology, if you’re using dialnorm, “you don’t need to worry very much about LKFS, because properly implemented dialnorm will pretty much take care of it for you.”

It’s important to stay on the right side of the CALM Act. If viewers complain to the FCC about your organization’s loudness level, and the FCC notices a pattern of complaints, it will start an inquiry or investigation for your organization. If there is an investigation, you’ll have to spend time proving that your equipment, and how you’ve maintained it, is in line with the law. If you don’t show actual or ongoing compliance in response to the inquiry or investigation, you may have to pay a fine.

Having a record of exactly what your programming sounded like when it aired will save you hassle and frustration. You will quickly be able to gather evidence and respond to viewer complaints.

Loudness compliance is easy with Moco: Compliance Monitoring by SnapStream. We provide TV stations, networks, and other broadcasters solutions for logging and monitoring loudness.