TV News November 2017


Volume 4, Number 11

Got feedback or questions? Click my name below to send us an e-mail. You can also use the links at the top or bottom of the page to follow us on popular social networking sites, and the tabs will take you to our most often visited pages.

-- Scott Johnson, Editor

AES Loudness Guidelines Explained


You’ve no doubt heard about the new loudness recommendations for Over-the-Top (OTT) and online video released by AES a few weeks ago. The “Loudness Guidelines for OTT and OVD Content” by the AGOTTVS (Audio Guidelines for OTT and Video Streaming) technical group addresses new challenges in content delivery, and could be as significant to broadcasters as the CALM Act.

To make sense of it all we checked in with our own Lon Neumann, who spent part of his career instructing broadcasters on loudness compliance and the CALM Act before joining Wheatstone as a sales engineer in 2016. 

WS: How significant is this new set of guidelines?

LN: This new set of AES guidelines is very significant. Until now, there have been issues related to variations of audio loudness across some of the new modes of content delivery, such as delivery of video content to handheld devices and by services such as Netflix. There really had been no guidelines for audio loudness of content that was delivered by these means.

It’s also worth noting that the 50-member Audio Guidelines for OTT and Video Streaming (AGOTTVS) technical committee* represented a cross-section of the industry with representatives from companies such as Amazon, Apple, BBC, CBS, Dolby, Fox, Fraunhofer, Google, NBC, Netflix, PBS, Starz, Qualcomm, and Wheatstone. Gaining a consensus from a group such as this lends considerable clout to the guidelines.

WS: What are the unique challenges of OTT and streaming that this addresses?

LN: Like digital TV broadcast, the digital nature of OTT and streaming video provides a dynamic range that is far beyond what was possible in the recent past. This leads to the possibility of severe loudness variations between programs and across delivery channels, to the considerable annoyance of the viewing public. 

Unlike digital TV broadcast, there is wide variation among the various receiving devices, various delivery services, and multiple possible choices of codecs. Another difference is that OTT content is often monitored by consumers in noisy ambient conditions.

Read the rest of the story

LonNeumannWS: What are some key recommendations by the AES for OTT and streaming?

LN:  One significant recommendation is that, in North America, the average level of the Anchor Element (almost always the normally spoken dialogue—neither shouting nor whispering) is the thing that is to be measured for determining loudness. Usually that will need to be at -24 LKFS.  The exception to that would be for distribution to systems that are known to use the AAC codec (many handheld devices), and also for cases of distribution to other systems either known to not support metadata or when it can’t be certain that metadata is supported.  In those cases, -16 LKFS might be used as the target loudness.

In addition to loudness level, dynamic range is addressed. For systems that support metadata, Dynamic Range Control (DRC) profiles that decrease the high level content and increase the low level content are to be properly encoded into the metadata. This generally entails first knowing that the average loudness of normally spoken dialogue is located at the central pivot point of the DRC curve.  

WS: Why are they suggesting anchor element instead of full program mix measure in most cases?

LN: There is strong research that shows that the audience judges the loudness of programs based on the loudness of the dialogue. Well produced shows balance the loudness of sound effects as well as the loudness of the music to the loudness of the Anchor Element, the dialogue.

Another reason is that the calculations for the instantaneous correction factors for the DRC profiles rely on the assumption that the level of the dialogue will be untouched by the DRC process by being located in the pivot point at the center of the DRC curve. The only way that can properly occur is if the average loudness of the normally spoken dialogue is known—by proper measurement of the Anchor Element.

Therefore, in the case of digital TV in all of North America (including Canada and Mexico) for normal long form program content, the average loudness of the Anchor Element (almost always the normally spoken dialogue—not the shouting and not the whispering) is the basis for measuring loudness. 

Short form content, normally being primarily dialogue, is properly measured by averaging the loudness of the full program mix.

These North American guidelines build on and are in addition to what was laid out in the ATSC A/85 Recommended Practice. The Europeans use a different approach as described in the EBU R128 document and the accompanying suite of four technical documents.

WS: Thanks, Lon.

Lon is a sales engineer specializing in television sound for Wheatstone, which makes loudness meters and audio processing tools for controlling average loudness as well as peak levels. Wheatstone offers specialized stand-alone processors as well as multi-band parametric equalizers, compressors and limiters that are routable resources accessible from anywhere at any stage in its WheatNet-IP audio network.

You can download a copy of the Loudness Guidelines for OTT and OVD Content by the AGOTTVS technical group under the auspices of the AES Technical Council’s Broadcast and Online Delivery Technical Committee.   

*The 50-member Audio Guidelines for OTT and Video Streaming  (AGOTTVS) technical group operated under the auspices of the AES Technical Council’s Broadcast and Online Delivery Technical Committee.


What AES67 Does and Doesn’t Do

YinYangThe inclusion of AES67 audio transport in the new SMPTE ST 2110 standard is one more example of the rapid and widespread adoption of this standard in providing signal interoperability across all of the current leading IP based audio networking systems.

Wheatstone has been a supporter of this IP audio interoperability standard since the beginning as a member of the AES X192 task force that formulated the requirements for AES67. In fact, Wheatstone's solution for stream discovery and connection management is described in the appendix of the AES67 standard itself.

More recently, Wheatstone has been a full participant in plugfests and tradeshow demonstrations of AES67 in action. During the recent Houston InterOp plugfest sponsored by Video Services Forum (VSF) in August 2017, we successfully ingested IP audio streams into our WheatNet-IP Audio network BLADEs from a variety of different manufacturers via AES67.

The following month we met again with fellow vendors, and demonstrated AES67 compatibility as a participant in the IBC IP Showcase in Amsterdam.

We built AES67 compatibility into WheatNet-IP audio networking products because we recognize the importance of this standard as a way to transport audio from, say, a broadcast group that might have one network platform (such as a WheatNet-IP system) and a remotely located production facility that has another (such as Dante).


What AES67 does...

Almost all audio networks use a standard IP protocol called RTP (Real-Time Protocol) to load continuous audio data into a fragmented stream of IP packets. RTP provides identification in the packets about their creation time and order but, prior to AES67, it has been up to the IP audio network manufacturer to embed and extract this information and to recreate the audio. Each differs in the specific packet loading, timing and synchronization mechanisms within the protocol.

AES67 came along to provide the common synchronization, clock identification, session description and other interoperability recommendations we can all share. AES67 adapted the PTPv2 (Precision Time Protocol - IEEE 1588-2008) standard as the master clock reference, so we can transport audio between our various systems without data dropout from unmatched clocking.


What AES67 doesn't do...

While AES67 provides a common transport standard to move audio from one system to another, it does not specify discovery, stream management, and associated logic functions for controlling devices on the network.

Turning devices on and off, controlling peripheral gear from the console, signaling when a source is ready for air play, and controlling the playout system with a fader channel – these are all functions of WheatNet-IP and similar audio networks.

In the case of WheatNet-IP, for example, a single Ethernet cable carries the real-time audio stream as well as network and device control data critical to the daily operation of a studio. 

To find out more about AES67 and IP audio for broadcast download our ebook IP Audio for TV Production and Beyond.



Putting together a new studio? Updating an existing studio? 

We've put together this IP Audio for TV Production and Beyond e-book with fresh info and some of the articles that we've authored for our website, white papers, and news that dives into some of the cool stuff you can do with a modern AoIP network like Wheatstone's WheatNet-IP. And it's FREE to download!

Just click here or on the cover.


The IP model of audio transport (AoIP) provides a unique combination of features well suited for today’s emerging remote At-Home production model. Integrated routing, processing, mixing, and control spread across interconnected devices on an IP network can be used to build a venue-side matrix of audio and control that includes mic-feeds, local mixing, low latency IFB, and control-logic from local or remote inputs. The resultant audio streams can then be transmitted to a distant At-Home production facility via AES67 (AoIP) for synchronization with the accompanying video streams.

Come join Wheatstone, where we'll take you through the new era of IP remote production:

SVG Summit, New York Hilton, NYC
Dec 11-12, Tabletop 75

To arrange a meet up, contact Lon Neumann at

Your IP Question Answered


Q: How does your system handle IFB?

A: With the utility mixers built into our I/O BLADE access units! There are two 8x2 stereo mixers inside our BLADEs at every connection point in the network, and they’re used for a number of things, including setting mix-minuses for IFB. It makes for a completely decentralized IFB system requiring no additional hardware. You can also interface to an existing intercom system, no problem.




  • Soundfusion (Johannesburg, South Africa) purchased four IP-12 digital audio consoles.

  • Sambhaav Media (Ahmedabad, India) purchased four IP-12 digital audio consoles and eight Air-1 consoles through Horizon Broadcast.

  • Odisha TV (Odisha, India) purchased an IP-12 digital audio console through Horizon Broadcast.

  • KBIA-FM (Columbia, MO) purchased two L-8 control surfaces and three M4IP-USB four channel mic processor BLADEs.

  • WATV-AM (Birmingham, AL) purchased a WDM audio driver through Bohn Broadcast.

  • KAFE-FM (Bellingham, WA) purchased an IP-12 digital audio console.

  • Rogers Broadcasting (Kitchener, ON) purchased console accessories through Ron Paley Broadcast.

  • Rogers Broadcasting (Toronto, ON) purchased an I/O BLADE through Ron Paley Broadcast.

  • CHIN-AM/FM (Toronto, ON) purchased WheatNet-IP audio network Scheduler software through Ron Paley Broadcast.

  • Duke University’s WXDU-FM (Durham, NC) purchased an IP-16 digital audio console and E-1 control surface.

  • Saga Communications (Charleston, SC) purchased two L-8 control surfaces.

  • WGN-TV (Chicago, IL) purchased three I/O BLADEs for an existing WheatNet-IP audio network.

Click for the rest of Who's Buying Wheat

Wheatstone Continued:

  • WDWS-AM (Champaign, IL) purchased three EDGE network units to extend an existing WheatNet-IP audio network.

  • Atlanta Braves Network (Atlanta, GA) purchased seven TS-4 talent stations for an existing WheatNet-IP audio network.

  • CBC Radio (Edmonton, AB) purchased a split-frame E-6 control surface through Ron Paley Broadcast.

  • Five Towns College (Dix Hills, NY) purchased two I/O BLADEs and a ScreenBuilder app for an existing WheatNet-IP audio network.

  • CBC Radio (Montreal, QC) purchased a TS-22 talent station, I/O BLADE and WDM audio driver for an existing WheatNet-IP audio network through Ron Paley Broadcast.

  • CJPE-FM (Picton, ON) purchased an IP-12 digital audio console and NAVIGATOR 3 software through Ron Paley Broadcast.

  • KFJB-AM (Marshalltown, IA) purchased IP-12 and IP-16 digital audio consoles with WheatNet-IP audio network I/O BLADEs.

  • Townsquare Media (St. Cloud, MN) purchased thirteen I/O BLADEs and audio drivers for an automation upgrade project.

  • Hubbard Broadcasting (Seattle, WA) purchased a WDM audio driver for an existing WheatNet-IP audio network.

  • Leighton Broadcasting (St. Cloud, MN) purchased a ScreenBuilder app for an existing WheatNet-IP audio network.

  • Townsquare Media (Evansville, IN) purchased six OLED control panels for an existing WheatNet-IP audio network.

  • Skyview Networks (Scottsdale, AZ) purchased an I/O BLADE and WDM audio driver for an existing WheatNet-IP audio network.

  • CBS Radio (Colton, CA) purchased a ScreenBuilder app for an existing WheatNet-IP audio network.

  • Crocmedia (Melbourne, Australia) purchased an E-1 control surface.

  • Delmarva Educational (Jacksonville, FL) purchased a DMX console through SCMS.

  • Telestar Communications (Sydney, Australia) purchased six DMX consoles.

  • Entercom (Charlotte, NC) purchased thirteen I/O BLADEs and audio drivers for an automation upgrade project.

Audioarts Engineering

  • Townsquare Media (Danbury, CT) purchased an Air-4 console.

  • WXCZ-FM (Cedar Key, FL) purchased an Air-4 console.

  • WNKR-FM (Cincinnati, OH) purchased an Air-5 console.

Wheatstone Audio Processing 

  • Evanov Radio (Halifax, NS) purchased an M4IP-USB four channel mic processor through Ron Paley Broadcast.

  • Blackburn Radio (Wingham, ON) purchased an AM-55 audio processor through Ron Paley Broadcast.

  • Oakwood Broadcast (Mississauga, ON) purchased an FM-55 audio processor.

  • Townsquare Media (Reno, NV) purchased an M4IP-USB four channel mic processor BLADE.

  • Beasley Broadcast Group (Tampa, FL) purchased an AirAura X3 spectral audio processor and AirAura X1 audio processor.


  • Radio One (Dallas, TX) purchased a VoxPro 7 digital audio recorder/editor.

  • iHeartMedia (Boston, MA) purchased three VoxPro 7 digital audio recorder/editors.

  • CBS Radio (Colton, CA) purchased two VoxPro 7 digital audio recorder/editors.

  • CJJR-FM (Vancouver, BC) purchased a VoxPro 7 digital audio recorder/editor through Ron Paley Broadcast.

  • CBS (Phoenix, AZ) upgraded to four VoxPro 7 digital audio recorder/editors.


Wheatstone's Console Range

In this video series, Phil Owens talks with Scott Fybush about Wheatstone's consoles/control surfaces and what the differences between them are.


Stay up to date on the world of broadcast radio / television.
Click here to subscribe to our monthly newsletter.

Site Navigations