Solutions for True Peak / Intersample Peak limiting that really work?
#121
8th April 2012
Old 8th April 2012
  #121
Gear Head
 

Paul Frindle and Paradox Uncr8ted:

In TV broadcast we've never been too bothered about inter-sample peaks because the specs we worked to usually resulted in peaks no higher than -10dBFS. The new North American (ATSC A/85) and European (EBU-R128) specifications both specify new peak levels, expressed in true peak, as calculated by compliant meters.

Although of passing interest, we're not really bothered by the fine detail of what happens in the SRC or the reconstruction filters in DACs but our reputations and jobs depend on us being able to measure and confine our mixes to the loudness and true peak levels as measured by meters compliant with the appropriate specification. It maybe, after going into the fine programming detail of these meters that some bright spark notices they don't actually calculate true peak precisely. But to us, that's largely irrelevant, our job is to get through quality control, as determined by some intern running software with the same metering algorithms as we're using. Hence this thread, to discuss limiters which will brickwall limit to the true peak specifications of our meters.

BTW, if you're interested, the tech docs can be found here:
EBU-R128 (website).
ATSC A/85 (pdf)
Both of these are based on the ITU-R-BS1770 specification.

G
#122
8th April 2012
Old 8th April 2012
  #122
Banned
 

Quote:
Originally Posted by GregorioM View Post
Paul Frindle and Paradox Uncr8ted:

In TV broadcast we've never been too bothered about inter-sample peaks because the specs we worked to usually resulted in peaks no higher than -10dBFS. The new North American (ATSC A/85) and European (EBU-R128) specifications both specify new peak levels, expressed in true peak, as calculated by compliant meters.

Although of passing interest, we're not really bothered by the fine detail of what happens in the SRC or the reconstruction filters in DACs but our reputations and jobs depend on us being able to measure and confine our mixes to the loudness and true peak levels as measured by meters compliant with the appropriate specification. It maybe, after going into the fine programming detail of these meters that some bright spark notices they don't actually calculate true peak precisely. But to us, that's largely irrelevant, our job is to get through quality control, as determined by some intern running software with the same metering algorithms as we're using. Hence this thread, to discuss limiters which will brickwall limit to the true peak specifications of our meters.

BTW, if you're interested, the tech docs can be found here:
EBU-R128 (website).
ATSC A/85 (pdf)

G
Sounds like you`re not really interested in the problem. Anyway if you need to deal with an obbjob and his meter, hire a decent programmer and have him incorporate the specifics of the meter you are talking about, and have him modify the limiter.

edit: Since GPL is kinda new to many audioenthusiasts, also remember that you need to contribute back the code.
#123
8th April 2012
Old 8th April 2012
  #123
Lives for gear
 
Henchman's Avatar
Quote:
Originally Posted by huub View Post
I agree, I mix live television, the most uncontrolled of environments, and I don't feel the need for a true peak limiter.. I never reach close to -3dBFs, and just for safety I brickwall at -4 or so..
I totally agree.
#124
8th April 2012
Old 8th April 2012
  #124
Lives for gear
 

Quote:
Originally Posted by GregorioM View Post
Paul Frindle and Paradox Uncr8ted:

In TV broadcast we've never been too bothered about inter-sample peaks because the specs we worked to usually resulted in peaks no higher than -10dBFS. The new North American (ATSC A/85) and European (EBU-R128) specifications both specify new peak levels, expressed in true peak, as calculated by compliant meters.

Although of passing interest, we're not really bothered by the fine detail of what happens in the SRC or the reconstruction filters in DACs but our reputations and jobs depend on us being able to measure and confine our mixes to the loudness and true peak levels as measured by meters compliant with the appropriate specification. It maybe, after going into the fine programming detail of these meters that some bright spark notices they don't actually calculate true peak precisely. But to us, that's largely irrelevant, our job is to get through quality control, as determined by some intern running software with the same metering algorithms as we're using. Hence this thread, to discuss limiters which will brickwall limit to the true peak specifications of our meters.

BTW, if you're interested, the tech docs can be found here:
EBU-R128 (website).
ATSC A/85 (pdf)
Both of these are based on the ITU-R-BS1770 specification.

G
Yes - I'm aware of this stuff - and it sure is needed because currently the user experience of sound conformity in broadcast is all over the place - even on the BBC! Not only do we have wildly varying levels between studio and OB reports and programme to programme inequality, we suffer over-loud music interventions in documentaries and drama. Even in the BBC 10 o'clock news, the level is around 2-3dB higher when it switches over to local news half way through!! These days I spend most of the TV watching time with the remote in one hand varying the volume.

This is what the ITU stuff is designed to ameliorate. The 'loudness' is computed by taking the RMS of a pre-filtered (LF roll-off) version of the incoming signal - and this conforms quite well to what we experience. It's little less good at music programme that may have undergone heaven knows what stuff to make it louder in the loudness wars, but it's still much much better than peak!! :-)

The meter itself gets this and shows the running peak 'loudness' levels over 3 timescales, using a gate to determine intentional silence, so that it can automatically discard an incomplete time block that contains silence and would therefore read low..

This model will not show you intersample peaks as such, but as you say, if programme remains at sample value peaks less than -6dBFS intersampling peaks are highly unlikely to occur - and maybe irrelevant to the intention of the ITU specs.

However we must still watch it? The reason we made our intersample peak meter/corrector is that my previous design in the Ox Limiter was not good enough to satisfy acceptance for some people producing broadcast material - on the very basis of intersample peaks themselves. The reason for this is that the OX limiter compromises slightly on freq content handling, reducing very slightly at 20KHz. This was OK 5 years ago, but current musical material is now so limited, squashed and maximised that it can breach the original design by a fraction of a dB.. So ths mattered to some people involved in broadcast at least? Remember, it is still possible to produce peaks above 0dB with programme at -10dB RMS - and even if peak limited to -1dBFS intersample errors can occur which are illegal samples that may not be decoded correctly by DACs, SRCs, data reduction coders and so on! The ITU meter will not show you this stuff :-( We cannot ignore this stuff and simply blame DACs, in any case they are only a fraction of the story in today's signal chains - as you will no doubt realise.

Making a gain limiter (not a clipper) that conforms exactly to the ITU recommendations and controls loudness within specs is definitely doable, it is by no means a complex process - and adding the intersample stuff is easy to do. However, it would require a large degree of look-ahead latency (at least 400mS due to the max measurement block time in the specs) which would put the dialogue out of sync by nearly 0.5 seconds in real time..

Another thing worth considering is that the ITU refers to metering indication, not the programme itself! So if you applied the same constraints on the audio as specified in the visual meter read out, it would likely (definitely) be completely unacceptable in reality..!

So for anyone designing the compressor you are suggesting this is a very large hurdle to cross and will need to somehow work out the most robust design to keep it significantly below the meter specs (so you never get an over), whilst maintaining an acceptable programme quality. Not easy IMVHO :-( In short it will be a large compromise and each manu will likely have a different set of compromises.

BTW - I should add that we can make you one, if it's a financially viable plug-in product..
#125
8th April 2012
Old 8th April 2012
  #125
Lives for gear
 
ggegan's Avatar
 

I really don't see how anyone anyone can discount the necessity of a true peak limiter. These days the spec we often work to for TV and cable projects is True Peak, not internal digital peak, and a conventional limiter is a blunt weapon to use to hit the spec.

Using a conventional limiter plugin, the intersample peak is often as much as 3dB above the threshold set on the conventional limiter, which only deals with the DAW's internal digital peak, not the interpolated analog peak output of the DA converter. In order to guarantee a true peak no higher than -3dBFS using a conventional limiter, the threshold may have to be set at about -6dBFS to deal with loud dynamic sounds. That extra 3dB of limiting is often audible. With a true peak or intersample peak limiter, you set the threshold at -3dBFS so there is less limiting and it is less audible, making the mix sounds better.

I think Elixir is a great plugin, except for the fact that it is only available as RTAS. When you put it on an aux or master track on a DSP system with the hardware buffer set to at least 1024 samples, which I find is what it requires to work properly, the amount of latency it causes is pretty extreme. I think I measured it at one and a third frames, which one can easily discern and is enough to screw up the timing of real time fader moves. That means you have to use long delay compensation to correct sync which eats up a lot of processing power and won't address the fader timing issue. The alternative when working with an external recorder is to add a delay that brings the latency to exactly 2 frames and then offset the timecode on the source machine. Elixir works great on Native systems, I think the latency is only about 500 samples or so.

I don't understand why Avid hasn't released its own true peak limiter DSP plugin. It is becoming almost as much of a requirement for doing broadcast post work as EQ and Compressor plugins, therefore I think one should be bundled with every HD system.
#126
8th April 2012
Old 8th April 2012
  #126
Lives for gear
 

Quote:
Originally Posted by ggegan View Post
I think Elixir is a great plugin, except for the fact that it is only available as RTAS. When you put it on an aux or master track on a DSP system with the hardware buffer set to at least 1024 samples, which I find is what it requires to work properly, the amount of latency it causes is pretty extreme. I think I measured it at one and a third frames, which one can easily see. That means you have to use long delay compensation to correct sync and that eats up a lot of processing power.

I don't understand why Avid hasn't released its own true peak limiter DSP plugin. It is becoming almost as much of a requirement for doing broadcast post work as EQ and Compressor plugins, therefore I think one should be bundled with every HD system.
I agree +1
#127
8th April 2012
Old 8th April 2012
  #127
Lives for gear
 

Quote:
Originally Posted by ggegan View Post
I really don't see how anyone anyone can discount the necessity of a true peak limiter. These days the spec we often work to for TV and cable projects is True Peak, not internal digital peak, and a conventional limiter is a blunt weapon to use to hit the spec.

Using a conventional limiter plugin, the intersample peak is often as much as 3dB above the threshold set on the conventional limiter, which only deals with the DAW's internal digital peak, not the interpolated analog peak output of the DA converter. In order to guarantee a true peak no higher than -3dBFS using a conventional limiter, the threshold may have to be set at about -6dBFS to deal with loud dynamic sounds. That extra 3dB of limiting is often audible. With a true peak or intersample peak limiter, you set the threshold at -3dBFS so there is less limiting and it is less audible, making the mix sounds better.
Yes you are right. But it does get a bit more complex with the current music production trends where mixes are accepted or rejected on only 0.5dB RMS differences on some poxy meter or another - really!

The very last thing people can tolerate is a 3dB reduction in peak level for stuff that does not cause intersample peaking :-(

The original OXF-R3 channel compressor I made did indeed work on real reconstructed signal, but the reconstruction was taken out before the release of the product, for 'music production trend' reasons.. Get my drift?

As I have said before so often, the ideal would be that your workstation mixers have real signal response all over the application, but of course this is costly in processing, so no one is going to advocate that either..

Of course the vast majority of the problem is the addiction to full modulation and an absence of general understanding. But for the moment, in order to stay in business at all one has to find ways of limiting/correcting only the intersample parts, leaving the rest intact..
#128
8th April 2012
Old 8th April 2012
  #128
Quote:
Originally Posted by huub View Post
I agree, I mix live television, the most uncontrolled of environments, and I don't feel the need for a true peak limiter.. I never reach close to -3dBFs, and just for safety I brickwall at -4 or so..
Some deliveries are -6dBFS TruePeak. All depends on what your mixing. Avid should have an AAX DSP TruePeak Limiter since few of the 3rd party developers appear motivated to develop DSP versions. At least at this time. We need practical Pro Tools solutions soon.
#129
8th April 2012
Old 8th April 2012
  #129
Lives for gear
 
ggegan's Avatar
 

Forgot to mention that if you have Elixir on 5.1 stem auxes, it uses up 12 voices per stem. That adds up to a lot of voices to give up in addition to the hit in processing power required by the plugin and the long delay compensation.

This thread should be over on the DUC so we can hound Avid into supplying a DSP plugin solution.
#130
8th April 2012
Old 8th April 2012
  #130
Gear Head
 
makesijoseph's Avatar
 

We just started learning about intersample peaks at school and the reconstruction process especially coming down to 44.1kHz 16bit CD's you hear the "spikes" for lack of a better word. lecturer says input levels in the digital world are too high.
#131
8th April 2012
Old 8th April 2012
  #131
Lives for gear
 

Quote:
Originally Posted by piratepost View Post
Some deliveries are -6dBFS TruePeak. All depends on what your mixing. Avid should have an AAX DSP TruePeak Limiter since few of the 3rd party developers appear motivated to develop DSP versions. At least at this time. We need practical Pro Tools solutions soon.
Like I said earlier, I have one here we made, working on PT native. I use it all the time, we just haven't got around to selling it yet because we are so bogged down with the 64 bit DSM product. It's a simple plug-in with an input and output meter, the latter showing intersample peak levels - and a single button to dynamically correct on the fly. It will also limit brute sample values too and it sure doesn't use 500 samples of delay!! :-)
#132
8th April 2012
Old 8th April 2012
  #132
Lives for gear
 
ggegan's Avatar
 

Quote:
Originally Posted by Paul Frindle View Post
Like I said earlier, I have one here we made, working on PT native. I use it all the time, we just haven't got around to selling it yet because we are so bogged down with the 64 bit DSM product. It's a simple plug-in with an input and output meter, the latter showing intersample peak levels - and a single button to dynamically correct on the fly. It will also limit brute sample values too and it sure doesn't use 500 samples of delay!! :-)
So make a DSP version of it, already!
#133
8th April 2012
Old 8th April 2012
  #133
Lives for gear
 
UnderTow's Avatar
 

I just did a mix today for a reality show. (EBU-R128 specs). I have an L2 on the output set to -2 dB FS. I have the metering on at all times and do a semi clean run of the whole show when mixing in the music which gives me a good indication of how far off spec I am so I can adjust the overall level before re-recording the final mix (+ whatever other deliverables are needed).

The TC Electronics LM2 showed a TruePeak of -0.7 dB TP. So that means that there was 1.3 dB of overshoot on the L2. The mix was less than a dB over spec (-21.2 LUFS) so not exactly loud. So yes, you can easily have issues with out of spec inter sample peaks even with the new EBU-128 norm. In this case I just pulled down the L2 output by 2 dB before recording the mix so no big deal.

On possible explanation of why people don't see anything close to -1 dB TP is that many people put limiters earlier on in the chain. I've seen templates and mixes with limiters on the dialogue set to -10 or lower. Of course an inter-sample peak of 9 dB or more isn't going to happen but I personally don't really like the sound of sync/dialogue sound hitting the limiter continuously. (But maybe that isn't what the people in this thread are doing).

Alistair
#134
8th April 2012
Old 8th April 2012
  #134
Lives for gear
 
pethenis's Avatar
 

I think part of that is the crazy deliveryspecs/time/budget matrix sometimes. Full dynamics for the 5.1, but the LtRt cannot be louder than -10 dBFS? And you don't want to pay for a seperate run for the folddown? A limiter on the dialogue at -7 it is...


Quote:
Originally Posted by UnderTow View Post
I just did a mix today for a reality show. (EBU-R128 specs). I have an L2 on the output set to -2 dB FS. I have the metering on at all times and do a semi clean run of the whole show when mixing in the music which gives me a good indication of how far off spec I am so I can adjust the overall level before re-recording the final mix (+ whatever other deliverables are needed).

The TC Electronics LM2 showed a TruePeak of -0.7 dB TP. So that means that there was 1.3 dB of overshoot on the L2. The mix was less than a dB over spec (-21.2 LUFS) so not exactly loud. So yes, you can easily have issues with out of spec inter sample peaks even with the new EBU-128 norm. In this case I just pulled down the L2 output by 2 dB before recording the mix so no big deal.

On possible explanation of why people don't see anything close to -1 dB TP is that many people put limiters earlier on in the chain. I've seen templates and mixes with limiters on the dialogue set to -10 or lower. Of course an inter-sample peak of 9 dB or more isn't going to happen but I personally don't really like the sound of sync/dialogue sound hitting the limiter continuously. (But maybe that isn't what the people in this thread are doing).

Alistair
#135
8th April 2012
Old 8th April 2012
  #135
Lives for gear
 

Quote:
Originally Posted by ggegan View Post
So make a DSP version of it, already!
I must have missed somethng and not understood?

It is obviously DSP already, it's running in PT.

What do you mean by 'DSP' ?
#136
9th April 2012
Old 9th April 2012
  #136
Gear Head
 

Quote:
Originally Posted by Paul Frindle View Post
I must have missed somethng and not understood?

It is obviously DSP already, it's running in PT.

What do you mean by 'DSP' ?
The new version of PT, PT10 HD, has renamed things a little. TDM plugins are now called DSP plugins and RTAS plugins are now called Native plugins. What Gary is saying is that Elixir is a Native plugin, which means going into and out of the TDM mixer costs 12 voices for each instantiation on a 5.1 stem. So with dialogue, effects and music, you've already used 36 of the max 192 voices available on a TDM system before you even start adding any audio tracks, other routing or plugins! A TDM version (DSP) would drastically cut the number of voices required.

It could be a problem for developers. Maybe there isn't yet a big enough user base to warrant the development of an AAX DSP plugin and maybe developers wouldn't want to invest development time in a soon to be discontinued plugin format like TDM?

If you have the time, would you mind explaining why a TP limiter plugin compliant with the ITU specs would require at least 400ms of look ahead time?

Thanks, G
#137
9th April 2012
Old 9th April 2012
  #137
Lives for gear
 

Quote:
Originally Posted by GregorioM View Post
The new version of PT, PT10 HD, has renamed things a little. TDM plugins are now called DSP plugins and RTAS plugins are now called Native plugins. What Gary is saying is that Elixir is a Native plugin, which means going into and out of the TDM mixer costs 12 voices for each instantiation on a 5.1 stem. So with dialogue, effects and music, you've already used 36 of the max 192 voices available on a TDM system before you even start adding any audio tracks, other routing or plugins! A TDM version (DSP) would drastically cut the number of voices required.

It could be a problem for developers. Maybe there isn't yet a big enough user base to warrant the development of an AAX DSP plugin and maybe developers wouldn't want to invest development time in a soon to be discontinued plugin format like TDM?

If you have the time, would you mind explaining why a TP limiter plugin compliant with the ITU specs would require at least 400ms of look ahead time?

Thanks, G
Renamed digital signal processing as hardware expansion card?! Oh geez, the amount of confusion we have to endure for marketing - there should be a law against it :-( For the rest of us DSP will remain digital signal processing wherever it is carried out :-)

Anyway, you are right that there is no particular incentive to make hardware expansion plug-ins.The majority of these are so eclipsed by the power of the host processor that they are increasingly being used only as security 'dongles' with the lion's share of the processing going on in the host anyway.

I also get your constant fight with limited TDM slots - yes it's a potential bottle neck and a pain, especially with 5.1.

The reason for the 400mS is that the longest time window block for the meter in question is 400mS, before it's decided whether the block is to be used or ignored if a low level gating event indicated it contained some 'silence' as defined by the RTU specs. Also the RMS detectore will need an integration time, which will also rack up the lookahead delay required.

On the surface of it, if the compressor was to do the exact same thing as the meter it would have to honour all this stuff too. But as I said later, applying this kind of stuff to a running gain control in real time would be useless and sound like hell anyway, it is not a recipe for smooth audio control. So something more forgiving (not like the meter) but still able to keep the measurements happy would need to be developed. I don't see this as insuperable at all, it's just that the compressor may need to operate some of the time below the maximum that would just keep the meter out of non-conformance.. This would matter losts to the music people because of loss of potential loudness, but for video, broadcast and the like it would not be so grave as currently you guys are not waging a loudness war (thank goodness), you are perhaps the only remaining bastions of sensible and high quality sound :-)
#138
9th April 2012
Old 9th April 2012
  #138
Gear Head
 

Thanks for your reply.

Quote:
Originally Posted by Paul Frindle View Post
Renamed digital signal processing as hardware expansion card?! Oh geez, the amount of confusion we have to endure for marketing - there should be a law against it :-( For the rest of us DSP will remain digital signal processing wherever it is carried out :-)
I agree, although there is a logic to it. ProTools 10 is a transition to the eagerly awaited PT11 (64bit ProTools) and AVID has created the new AAX plugin format (which is 64bit ready). So currently there are two types of plugins which use the dedicated DSP chips on the ProTools cards, TDM for the older HD cards and AAX DSP for the new HDX cards. So really the "DSP" label is an abbreviation for "Dedicated DSP".

Quote:
Originally Posted by Paul Frindle View Post
Anyway, you are right that there is no particular incentive to make hardware expansion plug-ins.The majority of these are so eclipsed by the power of the host processor that they are increasingly being used only as security 'dongles' with the lion's share of the processing going on in the host anyway.
For me, one of the advantages of dedicated DSP (TDM plugins) is the considerable improvement in latency. Plus of course, I can mix and match my use of Native and dedicated DSP for processing, weighing available voices and processing resources against latency. At the end of our often convoluted routing schemes is where the latency is most pronounced and therefore where there is the greatest need for a dedicated DSP limiter (in addition to the voices problem). From what I understand, there is a much easier migration between AAX Native and AAX DSP than there was between RTAS and TDM, in a deliberate attempt by AVID to make AAX DSP development cheaper. Although this doesn't really help me as I'm running TDM systems!

Quote:
Originally Posted by Paul Frindle View Post
On the surface of it, if the compressor was to do the exact same thing as the meter it would have to honour all this stuff too.
Speaking for myself, I would not need the limiter "to do the exact same thing as the meter". We just need to be able to see and control the instantaneous TP levels. Therefore the RMS and gating block detectors could be ignored and thus the delay greatly reduced, correct? My only concern would be that the limiter operates to limit the TP in such a way that the TP reading in my ITU (A85/R128) meter was not exceeded. Would this be possible without having to follow the entire ITU metering scheme?

G
#139
9th April 2012
Old 9th April 2012
  #139
Banned
 

I don`t think the problem is doing that. BTW the LA is optimized in my limiter and has variable optimization in the release. If you want to do wild LA, it is possible. LA is usually something you use for denoising the envelope though. But there will be a delay with RMS calculation also.

The problem is ofcourse getting it to be EXACTLY like the meter, you have to deal with.
How does it perform it`s exact DSP, how many times oversampling, what filters for RMS calculation? etc etc, else you will still get overs, and have to guess the level.
#140
9th April 2012
Old 9th April 2012
  #140
Gear Head
 

AFAIK, the MatLab code for the ITU metering is essentially public domain, I remember reading something to that effect in one of the R128 tech docs, along with the published code. The new A85 and R128 specs are designed, as I understand it, to eliminate the potential problem of failing QC requirements because of meter discrepancies. So I can use any R128 or A85 compliant meter, irrespective of what meters the broadcaster is using. So all the different ITU compliant meters must be based on the same code.

Wouldn't it be possible to just extract the code relevant to the TP reading and derive new code based on it? Or is my programming ignorance leading me to false assumptions?
#141
9th April 2012
Old 9th April 2012
  #141
Banned
 

Quote:
Originally Posted by GregorioM View Post
AFAIK, the MatLab code for the ITU metering is essentially public domain, I remember reading something to that effect in one of the R128 tech docs, along with the published code.

Wouldn't it be possible to just extract the code relevant to the TP reading or derive new code from it? Or is my programming ignorance leading me to false assumptions?
If that is the exact algorithm being used, it should be a piece of cake.

Edit, well for the algorithm anyway. You still have to deal with d/a conversion.
#142
9th April 2012
Old 9th April 2012
  #142
Banned
 

The problem is ofcourse also the d/a converter. Even if you emulate the meter in the limiter, what goes out will be modified by most (I think) modern d/a converters. And the meter at the other end, will still detect overs.

To understand why, you need to think of how a one-bit converter works. The one-bit converter deals with a stream of bits, and the average of, equals the audiostream. However without a lowpass, it`s just high-frequency garbage, in the megahertz range.

So this stream is lowpassed to average it into the audiostream. Often FIR filters with overshoots(ringing) are used here. Therefore -1, +1 in the original stream, and thus what is limited, is not -1, +1 on the output.

The simple fix on our side would be to get a multibit converter, that does not do any such filtering. Gaussian filtering (without overshoot) would be ok.
Maybe there exists one-bit devices that do this too? I don`t now.

The obscure fix, would be to emulate the D/A converter, which again requires the exact DSP of the converter, which probably is very closed source.

So it seems atleast that you need to get a no-overshoot d/a converter, and implement the metering code, into the limiter.

And then it is up to the a/d done before the meter..
#143
9th April 2012
Old 9th April 2012
  #143
Lives for gear
 

Ah ok I finally get it; you guys are talking specifically about ProTools AAXDSP - I'm sorry to be such a dunce!.

Yes we are fully aware of that, we are making an AAX version of our DSM plug-in right now :-) We may make an AAXDSP if porting is not too painful with the new PT H/W. The old TDM H/W was not really viable.

It's certainly possible to make what you are suggesting, if you can put up with the compressor operating a dB or so below the meter indication - and peak sample value limiting + intersample peak compression/repair can be included without problem. You need the conventional peak value limiting to overcome the LF roll-off on the RTU spec.

Compressor absolute conformity (RTU max possible level attained) will depend on how much latency you can put up with. Maybe two versions could be made.

Metering of both peak levels and RTU spec types can also be included easily.

This sounds like a doable and fun project :-)

Quote:
Originally Posted by GregorioM View Post
Thanks for your reply.



I agree, although there is a logic to it. ProTools 10 is a transition to the eagerly awaited PT11 (64bit ProTools) and AVID has created the new AAX plugin format (which is 64bit ready). So currently there are two types of plugins which use the dedicated DSP chips on the ProTools cards, TDM for the older HD cards and AAX DSP for the new HDX cards. So really the "DSP" label is an abbreviation for "Dedicated DSP".



For me, one of the advantages of dedicated DSP (TDM plugins) is the considerable improvement in latency. Plus of course, I can mix and match my use of Native and dedicated DSP for processing, weighing available voices and processing resources against latency. At the end of our often convoluted routing schemes is where the latency is most pronounced and therefore where there is the greatest need for a dedicated DSP limiter (in addition to the voices problem). From what I understand, there is a much easier migration between AAX Native and AAX DSP than there was between RTAS and TDM, in a deliberate attempt by AVID to make AAX DSP development cheaper. Although this doesn't really help me as I'm running TDM systems!



Speaking for myself, I would not need the limiter "to do the exact same thing as the meter". We just need to be able to see and control the instantaneous TP levels. Therefore the RMS and gating block detectors could be ignored and thus the delay greatly reduced, correct? My only concern would be that the limiter operates to limit the TP in such a way that the TP reading in my ITU (A85/R128) meter was not exceeded. Would this be possible without having to follow the entire ITU metering scheme?

G
#144
9th April 2012
Old 9th April 2012
  #144
Gear Head
 

Quote:
Originally Posted by Paradox Uncr8ted View Post
The problem is of course also the d/a converter.
Not in this case. I think the confusion is in the use of the term "True Peak". I appreciate that True Peak is also defined by the SRC and anti-imaging filters in DA converters. So identical material with exactly the same peak dBFS level could give a variety of different True Peak readings depending on which DAC it's passed through.

However, to create a set of common broadcast standards the ITU has included a peak measurement expressed in True Peak. I'm not sure why they have used True Peak rather than dBFS. Maybe to reduce potential problems with downstream analogue broadcast equipment or simply to help eliminate the potential for clipping in consumer playback equipment.

Also, I don't know whether the ITU has modelled their True Peak measurement on an actual DAC or if it's just some sort of arbitrary average, probably the latter. The result is a standardised method of TP measurement. Although of course this measurement may or may not match the actual True Peak of any individual DAC (or SRC or filter). In other words, we've got the ITU dBTP and we've got True Peak and they could be two different things!

What we're talking about and what we need is a limiter which operates on the ITU dBTP, which makes things much easier for the developer because we're not talking about a moving target. At the moment, we only really have the Elixir plugin which is specifically designed for the ITU dBTP but it has practical useage problems, CPU hog, long delay (latency) and in the case of ProTools, excessive voice usage. In theory there maybe other existing plugin limiters which can do the job but there's no easy way of knowing if a particular limiter has implemented look ahead and oversampling in a way which will eliminate the possibility of exceeding the A85 and R128 dBTP specifications. So in this thread we are communicating with each other to see if anyone (through trial and error) has found an existing limiter to do the job.

So far it looks like we are stuck with either the resource hungry Elixir or of using our existing limiters and having to go backwards and forwards, finding dBFS settings which will prevent us exceeding -2dBTP (A85) or -1dBTP (R128). A time consuming exercise, in a sector of the audio industry which probably has the most severe time constraints! Seem like there's a gap in the market for some enterprising developer!
#145
9th April 2012
Old 9th April 2012
  #145
Banned
 

Quote:
Originally Posted by GregorioM View Post
Not in this case. I think the confusion is in the use of the term "True Peak". I appreciate that True Peak is defined by the SRC and anti-imaging filters in DA converters. So identical material with exactly the same peak dBFS level could give a variety of different True Peak readings depending on which DAC it's passed through.

However, to create a set of common broadcast standards the ITU has included a peak measurement expressed in True Peak. I'm not sure why they have used True Peak rather than dBFS. Maybe to reduce potential problems with downstream analogue broadcast equipment or simply to help eliminate the potential for clipping in consumer playback equipment.

Also, I don't know whether the ITU has modelled their True Peak measurement on an actual DAC or if it's just some sort of arbitrary average, probably the latter. The result is a standardised method of TP measurement. Although of course this measurement may or may not match the actual True Peak of any individual DAC (or SRC or filter). In other words, we've got the ITU dBTP and we've got True Peak and they could be two different things!

What we're talking about and what we need is a limiter which operates on the ITU dBTP, which makes things much easier for the developer because we're not talking about a moving target. At the moment, we only really have the Elixir plugin which is specifically designed for the ITU dBTP but it has practical useage problems, CPU hog, long delay (latency) and in the case of ProTools, excessive voice usage. In theory there maybe other existing plugin limiters which can do the job but there's no easy way of knowing if a particular limiter has implemented look ahead and oversampling in a way which will eliminate the possibility of exceeding the A85 and R128 dBTP specifications. So in this thread we are communicating with each other to see if anyone (through trial and error) has found an existing limiter to do the job.

So far it looks like we are stuck with either the resource hungry Elixir or of using our existing limiters and having to go backwards and forwards, finding dBFS settings which will prevent us exceeding -2dBTP (A85) or -1dBTP (R128). A time consuming exercise, in a sector of the audio industry which probably has the most severe time constraints! Seem like there's a gap in the market for some enterprising developer!
I can ofcourse understand the annoyance of guessing the level. And it would vary with material, depending on their compression and EQ.
I know that, I have worked with brickwall filters. The only sane way to deal with such a meter that you discuss, seems to be if it is completely digital, that you deliver material to it digitally, and bypass unessecary d/a conversion.
And then you can implement the standard algo. And it should theoretically work well.

The brickwall-filter problem is not only a problem in post production, some consumer CD-players, even distort audibly, if the signal is too hot. (because of the overshoot in the filters). And again, that can be fixed with gaussian filters. (I have walked into hifi-stores and heard such CD-players, so it is not an obscure problem.)

Peace.
#146
9th April 2012
Old 9th April 2012
  #146
Gear Head
 

Quote:
Originally Posted by Paul Frindle View Post
... we are making an AAX version of our DSM plug-in right now :-) We may make an AAXDSP if porting is not too painful with the new PT H/W. The old TDM H/W was not really viable.
AFAIK, one of the main features of the AAX architecture is the ease of portability between the Native and DSP versions. If you haven't already seen it this thread on the DUC maybe of some interest.

I have to say though this won't be of much help to many of us. The economic climate (or in my case I've just launched an alternative audio post service) means that many of us can't yet afford/justify the cost of upgrading to PT HDX, which means we'll be stuck with either a voice consuming RTAS/AAXNative limiter or a trial and error setting with a TDM dBFS limiter. :(

Quote:
Originally Posted by Paul Frindle View Post
It's certainly possible to make what you are suggesting, if you can put up with the compressor operating a dB or so below the meter indication - and peak sample value limiting + intersample peak compression/repair can be included without problem. You need the conventional peak value limiting to overcome the LF roll-off on the RTU spec.
As far as using this as a buss limiter is concerned, it's only really the intersample peaks we're concerned about or to be more precise, the output limited to the true peak as defined by the ITU specs (generally -1dBTP for A85 and -2dBTP for R128). So having dBFS peak meters as well is not of any real importance, IMHO.

Quote:
Originally Posted by Paul Frindle View Post
Compressor absolute conformity (RTU max possible level attained) will depend on how much latency you can put up with. Maybe two versions could be made.
As far as the threshold "makeup gain" is concerned, it's going to have to be user trial and error because generally we're working to "integrated loudness", which is averaged over the duration of the TV programme. The only other alternative I can see is Latency = plugin processor time + the duration of the programme (!!) or an automatic setting of the makeup gain to R128 or A85 specs in non-realtime, such as an Audiosuite or standalone version.

G
#147
13th April 2012
Old 13th April 2012
  #147
Gear maniac
 

This is one of the most interesting threads I've read in some time, and I'm glad to have stumbled on it.

Coincidentally, I've been emailing back and forth with Paul about this exact issue. I haven't come up with a good solution, only that doing a combination of dither/Ozone 5 limiter at the end of the chain (not dithering/encoding further down the line) seems to solve the problem for me. -- this is a bummer though, because I end up having to add yet another limiter to a mastering chain that is in a delicate balance of losing dynamics (very loudly mastered dance music)


Then again, I'm only going straight to MP3 for most of these projects, and not having to deliver piles of WAV files in post production studios like the rest of you. MP3 compression can add somewhere around 0.3db max of encoding artifacts/intersample peaks, the intersample peaks caused with full-bandwidth file compression is much more...

Am subscribed to this thread!
#148
13th April 2012
Old 13th April 2012
  #148
Lives for gear
 
huub's Avatar
What kind of signals stay within R128 spec and peak close to -2 dBFS?
Explosion type sfx?

I'm genuinely curious, not trying to be an ass...

In live broadcast mixing I never encounter such signals as far as I know..
#149
13th April 2012
Old 13th April 2012
  #149
Lives for gear
 
ggegan's Avatar
 

Quote:
Originally Posted by huub View Post
What kind of signals stay within R128 spec and peak close to -2 dBFS?
Explosion type sfx?

I'm genuinely curious, not trying to be an ass...

In live broadcast mixing I never encounter such signals as far as I know..
It's the long term average level that must remain at -23, short duration sound FX often peak quite a bit higher. A gun shot, an explosion, slamming a book down on a desk, a car crash, even slamming a door can all clip at 0dBFS if there is no limiter on the bus. In order to get a gunshot or explosion to feel big, I find I generally have to push the level feeding the limiter until it is kicking down several dB, and it doesn't sound excessively loud, it sounds appropriate. In those situations I set the threshold of a non-true peak limiter to -6 dBFS in order to keep the true peak under -3dBFS as measured by the DMM.
#150
13th April 2012
Old 13th April 2012
  #150
Gear maniac
Yes. Just today I had to pull the limiter to -7.4 to keep a rifle loading fx under -3dbTP. Spikey foley and fx such as hammering are the worst culprits. Of which I have loads in this series. Even dialogue which is shouted in a loud scene can easily go to -3.
Thread Tools
Search this Thread
Search this Thread:

Advanced Search
Forum Jump
 
Register FAQ Search Today's Posts Mark Forums Read

SEO by vBSEO ©2011, Crawlability, Inc.