I’m in the middle of a monumental project, which requires transferring audio and video content from the original media to a NAS. About 75 percent of the content is analog but the remaining portion is already digitized in some form. Getting files to the NAS is merely a matter of copying them directly to the server, but some of the digital content lives on media that is not file-based so must be ingested digitally into my workstation for cleanup and file creation. During this process I’ve periodically encountered content with digital levels over zero, making the file unusable, forcing a different method of ingest.
While frustrating, this phenomenon is not entirely surprising for the following reasons: the recording devices use lossy compression, the content was originally recorded as hot as possible without going into the red, and the audio meters were sample peak meters that are prone to miss peaks that occur between the samples. As it happens, these very reasons were among those that drove the call for “True Peak” meters.
ANSWERING A NEED
Examples of True Peak meters By now, every television audio engineer should be familiar with LKFS-based loudness meters and should be using them for loudness management, but the True Peak part of the meter seems to get left out of the discussion quite often. When I finally grasped what True Peak meters actually do I couldn’t figure out why everyone didn’t immediately start using them for recording and mixing. We finally have a meter that will tell us when we’re actually approaching 0 dB FS to keep us from clipping digital and people just shrug it off. Anyone who works on gear with built-in digital metering has experienced meters with really poor resolution along with that nagging feeling in the back of their brain questioning whether they can really trust them. Even the built-in meters on high-end digital audio workstations sometimes leave me wondering exactly what scale the meter is based on and whether it can be trusted. True Peak meters seem to finally answer the need for rock solid meters we can rely on.
An effort to find out more about the origins and ideas behind True Peak meters turned up several papers of interest: ITU-R BS 1770-3, AES R-7-2006 and AES Convention Paper 9041, which give us some of the background, the reasoning and points to consider as we use these tools in our day to day business.
In 2006, the AES and ITU recommended the creation of oversampling True Peak meters to resolve issues inherent in sample peak meters: to help engineers avoid digital audio clipping and to give more accurate, reliable readings. The specific problems cited as reasons for the new meter were inconsistent peak readings, unexpected overloads, under-reads and beating of metered tones.
‘NOT ENTIRELY ACCURATE’
True Peak meters in use in Pro Tools In the intervening nine years, a slew of manufacturers have answered the call and brought the meters to market. These meters are specifically designed to read peaks that occur between samples by interpolating additional measurement points, essentially upsampling the signal. An oversampling rate of four times was determined to be sufficient for the meter to properly read all peaks, so True Peak meters sample at 192 kHz (with a base sample rate of 48 kHz). All of this should mean that we finally have a digital peak meter we can trust since they pick up the peaks that sample peak meters miss. While that is true, it turns out that the value the meter displays may not be entirely accurate.
Signal flow in a True Peak meter is generally as follows: the signal is attenuated 12.04 dB, four times oversampling is applied, a low pass filter is applied, an absolute value is determined. While this seems to be a relatively simple process it turns out that oversampling may increase peaks by up to 3 dB, and filters in the chain could contribute phase shifts and overshoot, all of which can skew the accuracy of the meter. If the content being metered was created with a lossy codec, then additional overshoots or odd meter behavior may also be experienced. In other words, the complexity of the True Peak meter makes its displayed value less accurate than simpler peak meters.
Ian Dash, author of AES Convention Paper 9041, explains the situation rather starkly when he states “All True Peak meters will therefore have some error in their readings, unlike most other forms of digital level meter.” Fortunately the meters are not too far off. As long as readings are made at the oversampled rate, True Peak meters are no more than .5 to 1 dB inaccurate, but it makes a rock-solid case for setting True Peak limits to −2 or −3 dB TP rather than at 0. At this time there does not appear to be any standardized test of True Peak meter accuracy but Dash does list a couple of options in his paper.
At the end of the day a minor inaccuracy in the display of True Peak meters should mean very little to those of us using them. My recent experiences point out the sound logic behind their creation, especially when working with archival and lossy content. The meters are likely to become more accurate as technology, filter design and processing power improves but the fact is that they already give us a better idea of the actual peak values of our content. However, it is apparent that enough headroom should be left to make up for the minor inaccuracy inherent in the device and perhaps it’s worth considering lowering True Peak limits from −2 dB TP to −3 dB TP as a precaution against overloading the signal in the broadcast path. True Peak meters are one of my favorite audio tools of recent years so a 1 dB inaccuracy isn’t going to stop me from using them and it shouldn’t stop anyone else either. Let’s leave a little extra headroom and get back to work. I’ve got a lot more media to transfer.
Jay Yeary is a broadcast engineer specializing in audio. He is an AES Fellow and is a member of both SBE and SMPTE. He can be contacted via TV Technology.
Future US's leading brands bring the most important, up-to-date information right to your inbox
Thank you for signing up to TV Tech. You will receive a verification email shortly.
There was a problem. Please refresh the page and try again.