How do file-based and real-time loudness processors fit into an overall facility audio system? Each has its place. If a facility is primarily file-based, then file-based processors can be integrated into the overall front-end workflow to conform content to house loudness and true peak targets. Real-time processors, on the other hand, are most appropriately used at the end of a signal chain just before transmission to catch and correct any errant loudness errors.

FILE-BASED PROCESSING
For ingest, file-based loudness processing is generally set up as part of an overall video and audio workflow that can include transcoding, quality control and more audio-specific processes such as channel verification and assignment, Dolby E decoding and encoding and metadata verification, besides loudness and true peak processing.

Workflow is generally set up via software interfaces instead of knobs and buttons on a front panel. The processors are integrated into the file-based environment via IP infrastructure.

Linear Acoustic AERO.2000 audio/loudness manager Software-only loudness meters are available as plug-ins for digital audio nonlinear editing systems for the craft editor to use during the edit session. However, there is a school of thought that advocates using a file-based loudness processor on a piece after it has been edited.

“Glancing every 17 seconds [at a loudness meter] is antithetical to getting work done and stultifies the creative juices,” said Oliver Masciarotte, director of customer experience at Minnetonka Audio Software Inc., maker of AudioTools. “Let audio mixers mix and stop worrying about loudness. Mix and make it sound good. Then give it to something to take care of loudness and not screw up the mix. Do this after the mix is locked.”

While post-edit loudness processing could be done in the edit suite, it does tie up that resource, which is why taking it out of the NLE environment will probably make more sense for most facilities. The edited piece can be copied to a “finished jobs” folder on the network, which would put it in a queue for automated “back-office” processing.

Simon Pegg, senior software pipeline architect for RadiantGrid, said he’s heard concerns from audio mixers about the introduction of loudness metering into the edit suites, fearing that it would take away from their creative process. Pegg’s response was that loudness processing actually gives audio mixers the freedom to do their job properly.

Jünger Audio’s T*AP TV audio processor

“We’re not taking away your skills,” Pegg said, referring to audio mixers. “Rather we’re liberating you to use your skills. Let the loudness process be automated. You use your ears to create, and we do the technical stuff, so you play well with everyone else.”

REAL-TIME PROCESSING
Compared to file-based processing, real-time loudness processing is best used at the end of the audio chain before final transmission. In this application, a real-time processor acts as a final gatekeeper to make sure no potential loudness violation sneaks by.

“Typically you want a real-time processor to do nothing for most of the time,” Pegg said. “But if something goes disastrously wrong, clearly going to a violation, then you want it to take effect.”

If every piece of content is checked and made to conform to the correct loudness level up front, then real-time processing at the end of the signal chain can be light and audio quality will be minimally affected.

“Scale everything first [with a file-based processor], then the real-time processor can be set to do less,” said Tim Carroll, Telos Alliance CTO and Linear Acoustic founder. “Otherwise the real-time processor has to be set for the worst offending audio and then apply it to all programs.”

Linear Acoustic has the AERO series of processors for television, as well as software versions for scaling and optional processing and upmixing for file-based content. Also, licensed versions of its processing can be found in products from Wohler/RadiantGrid, Axon, Cobalt Digital, Miranda, Ross, Snell and others, Carroll said.

One of the limitations of a real-time processor is adapting the processing to different types of audio content. As Pegg said, “loudness correction has to be applied sensibly, or it can squash the signal entirely. You can get a good loudness number, but the sound [quality] will be poor.”

While real-time loudness processors typically have less flexibility than file-based processors, they don’t necessarily have to be stuck with a worst-case setting. These types of processors come with factory-defined presets that cover many scenarios, and usually allow custom presets to be saved. Much of this can be done with front-panel controls. Just remember that, unless in bypass, a real-time processor is always doing something.

It’s probably best not to set and forget with a real-time processor, or take the setting that comes out of the box, but to consider the types of programs that may have to be dealt with. A live musical event will probably need a wider dynamic range than a prerecorded situation comedy, for example.

Automation can be a solution. A playlist can be set to trigger different presets for different types of content. Peter Pörs, managing director, Jünger Audio GmbH, suggested sending a trigger to a real-time processor when content is switched to interstitials and then back again. “This clears the measurement memory from the previous program and starts the measurement all over again,” he said.

Jünger Audio calls its loudness solution Level Magic II, and can be found in such products as T*AP Edition eight-channel TV audio processor and D*AP4 LM Edition four-channel digital audio processor.

A real-time processor can also be put in bypass if a piece of content is known to have the correct loudness, but take care. Carroll said that even if a program is scaled correctly with a file-based processor, it could still have a wider dynamic range than the viewer’s system can comfortably handle. Since this could then engender viewers’ complaints, some real-time processing may actually be needed.

Another caution regarding automation is that if it somehow gets out of sync or was programmed incorrectly from the start, the wrong preset could end up being triggered— processing when not needed and vice versa.

If a real-time processor must be set with only one configuration, then try picking a setting somewhere in the middle between hard limiting and really wide dynamic range.

“If it’s too far in one direction, then Hollywood will complain; but if you go the other way, the consumer will complain,” Carroll said.

While a typical form factor for a real-time processor is a 1RU chassis, there are products available in a modular format, especially for facilities that generate multiple channels. Examples are Cobalt Digital’s Compass and Fusion range of modular products that have an option for the inclusion of Linear Acoustic AEROMAX 5.1 and/ or 2.0 channel loudness processing for at least 17 Cobalt openGear cards. Jünger Audio’s C8000 modular line includes the C8086+ eight-channel Level Magic II processor card for 5.1 or 2.0 mixed mode or four 2.0 channels.

Any processing will leave its effect on the audio signal, real time generally more so than file-based. So be aware if any of these undesirable audio effects are heard—distortion, pumping, reduced dynamic range, collapsed soundstage, image shifts from front to back and left to right, spectral skewing and reduced intelligibility.

With a collapsed sound field, “you lose the sense of depth and panning,” Masciarotte said. “The center channel may be lost or get buried. The sound may shift from front to back for no apparent reason.”

Remember, intelligibility can be compromised any time that gain or power spectrum is changed.

Used wisely, loudness processors can keep a facility compliant with the latest loudness rules and regulations and still produce good quality audio.

Mary C. Gruszka is a systems design engineer, project manager, consultant and writer based in the New York metro area. She can be reached via TV Technology.

File-based loudness processing, as one might expect, operates on audio files, either standalone, or extracted from an audio/video file such as MXF. The strength of a file-based processor is that it can gain foreknowledge about an entire audio file (or segment)—start to finish—before doing any processing. Because of this, file-based processing could potentially be less intrusive than its real-time counterparts.

Typically, file-based processing happens in multiple passes. First, the audio signal is analyzed, then—based on preset rules—the processor determines what type of functions or operations is needed and then applies them. Depending on the adjustments needed, further analysis and processing steps may occur in an iterative fashion, to arrive at the final result. While this may sound time-consuming, typical processing times are faster than real time. What kinds of measurements and processing are typical of file-based loudness processors?

DEFINED LOUDNESS TARGET
The first is fairly obvious—loudness. Adjusting the audio signal to reach a defined loudness target is fairly straightforward for file-based loudness processors. Unlike a real-time processor, which effectively rides gain throughout, a file-based processor inserts either attenuation or gain. if it’s needed, to reach the target loudness. This is done after performing a loudness measurement on the file, per ITU recommendation ITUR BS.1770-3, “Algorithms to measure audio programme loudness and true-peak audio level.”

Fig. 1: Example of a file-based workflow that includes loudness measurements and adjustments, and true peak limiting for the AudioTools family of products (Courtesy of Minnetonka Audio Software, Inc.)

This single gain shift (scaling factor) doesn’t change the dynamic range. “It’s like adjusting the gain control on a fader and leaving it alone for all of the content,” said Bob Nicholas, director of international business development for Cobalt Digital in Urbana, Ill.

In addition to loudness, ITU-R BS.1770-3 describes how to measure another parameter, true peak level. Both file-based and real-time processors can provide this measurement. According to ITU-R BS.1770-3, “true-peak level is the maximum (positive or negative) value of the signal waveform in the continuous time domain; this value may be higher than the largest sample value in the 48 kHz time-sampled domain.”

If only the sampled peak value were used, problems such as inconsistent peak readings, unexpected overloads, and under-reading and beating of metered tones could occur. Again from ITU-R BS.1770-3: “The problem occurs because the actual peak values of a sampled signal usually occur between the samples rather than precisely at a sampling instant, and as such are not correctly registered by the peak-sample meter… [The] use of a true-peak indicating algorithm will allow accurate indication of the headroom between the peak level of a digital audio signal and the clipping level.”

DYNAMIC RANGE CONTROL
File-based processors can be used for other related functions as well. One example is dynamic range control (as with the AERO. file option for RadiantGrid or the Wohler loudness appliance solution). Another is measuring and controlling maximum short-term loudness, maximum momentary loudness, loudness range, and dialog level (as with Minnetonka’s AudioTools family, which includes AudioTools Server, AudioTools FOCUS and AudioTools Loudness Control for Harmonic ProMedia Carbon, for another example.)

Simply scaling an audio file, even though it meets a loudness target, may not be enough to stop viewer complaints, if dynamic range remains wider than their systems can handle, as Tim Carroll, Telos Alliance chief technology officer and Linear Acoustic founder, pointed out. That’s the reason for adding dynamic range control to loudness processors. For a theatrical release movie, for example, dynamic range may need to be narrowed to make it a better fit for TV, while a sitcom may not need much, if any, dynamic range adjustment.

File-based processors are capable of making a variety of measurements to determine how to adjust the final output to reach a predefined target. This can often be an iterative process, as one adjustment may affect another parameter. Fortunately iterative processes are well-suited to software-based products. If the target isn’t reached after a certain number of attempts, the processor can send out a notification for human intervention.

File-based loudness processing is typically just one part of an overall file-based ingest or quality control workflow that can include audio up or down-mixing, Dolby E decoding and encoding, metadata adjustment, channel assignment detection and conforming, watermarking, pitch and time control, sample rate conversion, channel management (muting, copying, reconfiguring, replacing), and third-party functions and integration, according to Oliver Masciarotte, director of customer experience at Minnetonka Audio Software.

Fig. 2: Example of a more complex file-based workflow that includes multiple languages, program correlation and channel order verification, downmixing, loudness measurement, processing and peak limiting for the AudioTools family of products (Courtesy of Minnetonka Audio Software, Inc.)

As an example, the AudioTools family can integrate with Telestream Vantage and Harmonic ProMedia Carbon. File-based processing is also amenable to complex automation, according to Masciarotte.

The audio functions can occur alongside any video file-based functions such as transcoding, aspect ratio, standards conversion or quality control.

BRANCHING AND ITERATIVE WORKFLOW
Branching and iteration are keys to efficient and flexible workflows in file-based processors. Let’s look at a couple of workflow block diagrams for AudioTools to see how this works.

Referring to Fig. 1, start at the left side of the block diagram, where the audio essence is extracted from an MXF file. The audio is then checked for the presence of Dolby E. If Dolby E is detected, then the channels are first decoded to PCM before being sent to the measurement and loudness normalization stages. According to Masciarotte, loudness measurement and control, for the most part, needs to happen with PCM (pulse-code modulated) digital audio signals.

While not shown in Fig. 1, the workflow could be set up with another branch to check if the loudness meets the required target. If “yes,” the signal would continue on to the next stage, but if not, the audio channels would be subjected to further loudness level adjustments and measurements.

After the loudness adjustment sections, the workflow checks to see if the signal needs to be converted to Dolby E. Depending on the answer, different true peak limiting is applied. If encoding is required, it happens after the true peak limiter, and the signal gets re-wrapped into the MXF file.

Fig. 2 shows a more complex workflow that includes multiple languages, program correlation, channel order verification, and downmixing, in addition to loudness measurement and processing and true peak limiting.

With software-based systems, workflows such as these are defined according to each customer’s specific requirements. According to Masciarotte, these types of file-based systems can be modular to some extent, scaleable, and easily interoperable across WANs, MANs, LANs and SANs. The file to be processed can be local or remote depending on the system.

Some IT knowledge is typically needed to set these up and to ensure a good user experience.

Mary C. Gruszka is a systems design engineer, project manager, consultant and writer based in the New York metro area. She can be reached via TV Technology.