Metering

[Nika]

Several people have asked me about a white paper I recently wrote regarding metering in Protools, so I thought I would post a link to it here. The discussion is about the inadequacy and consequences of using traditional peak meters.

http://www.tllabs.com/files/Digital%...te%20paper.pdf

Cheers!
Nika.

[Park Seward]

Excellent paper. Thanks.

So even if we get no red clip light in PT, the waveform after reconstruction could be over and distorted?

[missilanious]

Then would recording in a higher sample rate yeild a more accurate peak reading while in the DAW given that a higher sample rate is going to create more points thus better resembling the waveform after it is reconstructed?

[jackruston]

Thanks Nika

This also further supports the theory that tracking too hot is responsible for a dodgy sounding mix in software. If little overloads are occurring throughout, no wonder people have complaints.

J

[Helgonet]

http://www.zero-distortion.com/downl...mat_arena2.pdf

[jackruston]

Originally posted by missilanious:
Then would recording in a higher sample rate yeild a more accurate peak reading while in the DAW given that a higher sample rate is going to create more points thus better resembling the waveform after it is reconstructed?

<font size="2" face="Verdana, Arial">Yes. If you consider that most of the energy is sub 20khz, a meter operating at 96khz will be relatively good in terms of not allowing unseen overloads. I THINK this kind of oversampling is sometimes incorporated in meter designs, but the best approach is to stick a reconstruction filter before the meter.

Jack

[Nika]

Originally posted by jackruston:
<blockquote><font size="1" face="Verdana, Arial">quote:<hr /><font size="2" face="Verdana, Arial">Originally posted by missilanious:
Then would recording in a higher sample rate yeild a more accurate peak reading while in the DAW given that a higher sample rate is going to create more points thus better resembling the waveform after it is reconstructed?

<font size="2" face="Verdana, Arial">Yes. If you consider that most of the energy is sub 20khz, a meter operating at 96khz will be relatively good in terms of not allowing unseen overloads. I THINK this kind of oversampling is sometimes incorporated in meter designs, but the best approach is to stick a reconstruction filter before the meter.

Jack <hr /></blockquote><font size="2" face="Verdana, Arial">It is important to remember that this doesn't really happen on the A/D side as much as it does on the D/A side. While it CAN happen on the A/D, I have no evidence of this actually being a problem. There are some statistical reasons why this would be more prevalent on the D/A side that are difficult for me to put into cohesive words.

When you work at a higher sampling frequency you are "creating" more content above 20KHz than the system originally recorded. This means that, for the highest frequency you are trying to represent (now 48KHz instead of 22.05KHz), you still have as many samples per waveform, and just as many opportunities to have this type of error.

Working at 96KHz does not actually solve this issue. Solving the issue requires an oversampling peak meter.

As for which meters actually do this? Only two that I know of or have ever been able to find. The TC Electronic System6000 uses a 2x oversampling reconstruction filter emulation. It was in light of the fact that the vast majority of meters did NOT do this that I approached Trillium Lane Labs about making one. The paper you read was written at their request to explain the issues surrounding their new plugin to those that would be confused about why it would be necessary. You can see the meter at:

http://www.tllabs.com

The meter on the right is the oversampled meter. The one on the left is like the one you see in Protools.

Any more questions?

Nika.

[Nika]

Originally posted by Park Seward:
Excellent paper. Thanks.

So even if we get no red clip light in PT, the waveform after reconstruction could be over and distorted?

<font size="2" face="Verdana, Arial">Precisely!! Not only that, but often is, especially if you are near FS. I ran some 3 minute pop songs through the Protools meter and a subsequent oversampling peak meter and found, in some cases, about 150 "overs" per track (left/right) that were not registered in Protools.

Nika.

[jackruston]

Originally posted by Nika:

<font size="2" face="Verdana, Arial">It is important to remember that this doesn't really happen on the A/D side as much as it does on the D/A side. While it CAN happen on the A/D, I have no evidence of this actually being a problem. There are some statistical reasons why this would be more prevalent on the D/A side that are difficult for me to put into cohesive words.[/QUOTE]

Originally posted by Nika:

<font size="2" face="Verdana, Arial">Well if we are working at -18dbfs calibration level it should not be an issue at the tracking stage. I suppose if you ran program material out to a analogue processor on an insert point you may have a problem. You imply that there are technical reasons why the AD stage would not be a problem. Can you shed any light on this Nika? (I believe you, I'm just interested!)

[/QUOTE]
When you work at a higher sampling frequency you are "creating" more content above 20KHz than the system originally recorded. This means that, for the highest frequency you are trying to represent (now 48KHz instead of 22.05KHz), you still have as many samples per waveform, and just as many opportunities to have this type of error.[/QUOTE]

Sorry mate I'm getting lost here. Surely the majority of the energy lies in the sub 20khz frequencies. Clearly the 96k system would record some hf that was not able to be recorded by the 48k system, but surely theres much less energy up there. Am I totally getting this wrong? [img]images/icons/smile.gif[/img]

Are you saying that it doesnt matter if the samples are 'closer together' because the hf waveforms are higher frequency and so can go unnoticed by the meter.

Surely the 96k option yields some improvement or no?

[/QUOTE]
Working at 96KHz does not actually solve this issue. Solving the issue requires an oversampling peak meter.

As for which meters actually do this? Only two that I know of or have ever been able to find. The TC Electronic System6000 uses a 2x oversampling reconstruction filter emulation. It was in light of the fact that the vast majority of meters did NOT do this that I approached Trillium Lane Labs about making one. The paper you read was written at their request to explain the issues surrounding their new plugin to those that would be confused about why it would be necessary. You can see the meter at:

http://www.tllabs.com

The meter on the right is the oversampled meter. The one on the left is like the one you see in Protools.

Any more questions?

Nika. [/QB][/QUOTE]
[/QUOTE]

That looks very interesting. I had understood that mastering houses have been using oversampling metering for years. Not so?

Thanks for your patience.

Jack

[Nika]

Originally posted by jackruston:
Well if we are working at -18dbfs calibration level it should not be an issue at the tracking stage. I suppose if you ran program material out to a analogue processor on an insert point you may have a problem. You imply that there are technical reasons why the AD stage would not be a problem. Can you shed any light on this Nika? (I believe you, I'm just interested!)

First, because any headroom offered at all helps prevent this from occurring, so giving 3dB of headroom DRASTICALLY reduces the opportunity for this to occur.

Second, because compressed signals are more prone to this than uncompressed signals, from work I've done on the subject so far.

Third, because of the statistical reality that on the digital side, a signal can be precisely specified to get closer to FS because it is all handled numerically. When recording analog signals it is difficult to get the signal as hot, predictably.

Fourth, because if a signal DOES clip at the A/D this way, it won't necessarily mess up the future samples.

There are a couple of other reasons as well, but this pretty well alludes to the fact that this is significantly more of an issue at the D/A than the A/D, and that it can be prevented at the A/D with just some simple headroom, which is almost a given if the red light is not to go off.

When you work at a higher sampling frequency you are "creating" more content above 20KHz than the system originally recorded. This means that, for the highest frequency you are trying to represent (now 48KHz instead of 22.05KHz), you still have as many samples per waveform, and just as many opportunities to have this type of error.

<font size="2" face="Verdana, Arial">Sorry mate I'm getting lost here. Surely the majority of the energy lies in the sub 20khz frequencies. Clearly the 96k system would record some hf that was not able to be recorded by the 48k system, but surely theres much less energy up there. Am I totally getting this wrong? [img]images/icons/smile.gif[/img]

No, this is correct, but just the fact that there is less energy up there doesn't mean that this situation doesn't still occur at the higher sample rates. What it does, however, do, is prevent much of the distortion created in this way from being in the audible range, but does not completely prevent it. The distortion still occurs, and can still be in the audible range, but it helps to reduce the likelihood of this.

On the other hand, unless you're delivering at 96KHz then the prospect of this occurring still happens when the material is converted to a base sample rate.

That looks very interesting. I had understood that mastering houses have been using oversampling metering for years. Not so?

It is possible that some mastering houses have oversampling meters, but I am finding indications that this is not widespread. Certainly users of the TC System6000 have this functionality if they use it, and I just stumbled across a hardware one from DK Audio.

But if they are really using these then why do we find so many clips in CD's when we use an oversampled meter? I have to think that most mastering facilities DON'T actually use them?


Nika.