Crest Factor Detection for a Compressor

[JohnRoberts]

So one 2252 as an RMS detector, one 2252 configured as a peak detector and another 2252 to log convert the peak detector output? I don't know what the log convert means or why it is necessary but I'll try to figure that one out myself from the app notes.

Was the implementation of the pot as simple as feeding the output of each detector into opposite ends of the track and buffering the wiper output before feeding the VCA?

The 2252 output already is in the log domain and ready to control THAT VCAs so there isn't any need to log convert it again.

====

Yes you could pretty simply pan between a fast and slow 2252 to get a range of different detector responses. I believe we discussed a way to make the cap in the 2252 continuously variable with a C multiplier circuit, on Wayne's forum.

JR

 

[abbey road d enfer]

So one 2252 as an RMS detector, one 2252 configured as a peak detector and another 2252 to log convert the peak detector output? I don't know what the log convert means or why it is necessary but I'll try to figure that one out myself from the app notes.

Was the implementation of the pot as simple as feeding the output of each detector into opposite ends of the track and buffering the wiper output before feeding the VCA?

The 2252 output already is in the log domain and ready to control THAT VCAs so there isn't any need to log convert it again.

In that case the peak detector is a standard linear detector, which needs to be log converted to drive the 2252.

====

Yes you could pretty simply pan between a fast and slow 2252 to get a range of different detector responses. I believe we discussed a way to make the cap in the 2252 continuously variable with a C multiplier circuit, on Wayne's forum.

JR

In this configuration, varying the cap modifies both attack and release times, which may not be desirable. And applying attack and release controls to the already log converted output of a fast 2252 does not yield the same results as applying them to the linear signal.

 

[JohnRoberts]

Agreed, but I don't want to make this appear overly complex to the OP. Rather than guess what they did with 3x 2252, I can only say with any conviction what (I think) they didn't  do.

Yes the 2252 has a cap and a resistor that both affect time constants, but as you know, not in a classic RxC manner. Scaling the cap will affect both attack and release, scaling the resistor not so much re: the attack (and has other undesirable interactions).

I can imagine other approaches or variations on this approach, but this seemed like the simplest that could deliver something in the ball park to get him started. I don't expect it to work perfectly out of the box... and have cautioned thus.

JR

 

[tv]

Using two 2252s with different time-constants, and comparing/substracting the long/averaged from short/peak value would in fact (to my understanding at least) compare two rms values with different integration time, imo best analogy would be "comparing peak rms to average rms values".

 

[abbey road d enfer]

Agreed, but I don't want to make this appear overly complex to the OP. Rather than guess what they did with 3x 2252, I can only say with any conviction what (I think) they didn't  do.

Yes the 2252 has a cap and a resistor that both affect time constants, but as you know, not in a classic RxC manner. Scaling the cap will affect both attack and release, scaling the resistor not so much re: the attack (and has other undesirable interactions).

Yes, that's because the resistor there is just the discharge resistor, so it affects only the release time. The charge resistor is the transistor's dynamic output resistance, which is essentially variable as a function of the output current. (I'm not saying that for you JR, that's for clarification for others).

I can imagine other approaches or variations on this approach, but this seemed like the simplest that could deliver something in the ball park to get him started. I don't expect it to work perfectly out of the box... and have cautioned thus.

JR

In view of the specific OP application, I would think that your suggestion is spot on, since the desired effect is discrimination of fast and slow loudness changes.

 

[Gold]

imo best analogy would be "comparing peak rms to average rms values".

I don't think there is much of a difference between "peak rms" and peak. Both the waveform and the meter that is measuring it have some integration time. I think it's just a matter of "how fast is fast?". Will the 2252 misbehave if the cap is too small?

 

[JohnRoberts]

I doubt you will have any problem making it faster than you need. I would expect it to be stable with even a small film cap there.

Since the final VCA gain modulation in the implementation I proposed will be directly modulated at roughly the speed of this faster detector, I would consider adding another cap. Actually increase the value of c6 already there across opamp OA2 (in application note dn00A.) from 22pf to something more effective for smoothing the VCA voltage changes.  Since that opamp is clamped in one direction by a diode you could probably get away with using a polar electrolytic there.

Once again I would experiment with cap values for best results. The cap in the fast detector can be made faster if we smooth the result after the crest factor information is extracted, so perhaps little need to slow down the slow detector much if at all. 

JR

 

 

[tv]

The cap in the fast detector can be made faster if we smooth the result after the crest factor information is extracted, so perhaps little need to slow down the slow detector much if at all.

Actually, I wanted to "propose" that the "result" (output) of the peak/rms comparing/processing be routed thru an opamp "active-diode" with additional short attack/rel time constant to further "process" the actual GR response, .... earlier in thread ....... but decided not to stir waters too much.

But now that the cat's out of the bag, ...

Both the waveform and the meter that is measuring it have some integration time. I think it's just a matter of "how fast is fast?".

Exactly, but I also think (o.k. "gut feeling") that with "best" values for detector/extraction circuit, you will have some peak overshoot after the VCA. Just a feeling, though.

 

[abbey road d enfer]

Using two 2252s with different time-constants, and comparing/substracting the long/averaged from short/peak value would in fact (to my understanding at least) compare two rms values with different integration time, imo best analogy would be "comparing peak rms to average rms values".

I think we're erring on metaphysis here; there is nothing like peak rms or average rms. There are fast and slow rms, and the output of a 2252 is not an exact rms because the integration time is not identical for upswing and downswing.

 

[abbey road d enfer]

imo best analogy would be "comparing peak rms to average rms values".

I don't think there is much of a difference between "peak rms" and peak. 

If you mean there is not much difference between a fast dbx/THAT rms and peak, I agree (although a peak detector can be made as slow as one wants to).

Both the waveform and the meter that is measuring it have some integration time.

In a dynamics processor, there is generally not much in terms of integration time after the detector. A standard dbx160 side-chain is pretty fast (it's only limited by the speed of the TL0 that drives the VCA control port. The waveform, by itself, doesn't have an integration time.

Will the 2252 misbehave if the cap is too small?

The cap is never too small; you can omit it if you want real fast, you can put 100pF or 10nF, it won't complain.

 

[abbey road d enfer]

The cap in the fast detector can be made faster if we smooth the result after the crest factor information is extracted, so perhaps little need to slow down the slow detector much if at all.

Actually, I wanted to "propose" that the "result" (output) of the peak/rms comparing/processing be routed thru an opamp "active-diode" with additional short attack/rel time constant to further "process" the actual GR response,

Actually, I think you should experiment with different values, because you want the slowest detector capable of following the "macrodynamics", which are not the same from one tune to another, same for the fast detector, although I agree an alternative would be to add these attack/release controls. But I doubt you find a single value for the slow detector that matches all types of programme.

Both the waveform and the meter that is measuring it have some integration time. I think it's just a matter of "how fast is fast?".

Exactly, but I also think (o.k. "gut feeling") that with "best" values for detector/extraction circuit, you will have some peak overshoot after the VCA. Just a feeling, though.

I don't see anything that would substantiate that...

 

[tv]

Using two 2252s with different time-constants, and comparing/substracting the long/averaged from short/peak value would in fact (to my understanding at least) compare two rms values with different integration time, imo best analogy would be "comparing peak rms to average rms values".

I think we're erring on metaphysis here; there is nothing like peak rms or average rms. There are fast and slow rms, and the output of a 2252 is not an exact rms because the integration time is not identical for upswing and downswing.

Well ok this is a matter of choosing the "right" words - but here the old Voxengo SPAN meter used this exact wording ("peak RMS" - PRMS) which is different to the absolute peak value (now replaced by "crest" readout), and in essence this is IMO the closest analogy to what is supposedly happening in dual 2252 scenario ... so all the time constants and other processing will in essence show similar behaviour - IMO at least.

 

[abbey road d enfer]

Well, it's unfortunate that a renown manufacturer uses misleading terminology. But I must admit of being guilty of using peak to describe a dual time-constant averaging filter. Peak is the absolute instantaneous max value. The change from Peak to Crest is not a judicious one either, but I agree there is a lack of correct word in audio terminology.
The problem is that when a discussion comes to the nitty-gritty, all the definitions must be publicized and agrred upon.

 

[tv]

http://www.youtube.com/watch?v=DZkjoXyexKk

 

[JohnRoberts]

It can be hard to keep a thread focused on only one topic and I'm as guilty as most of veering off on tangents.

The THAT 2252 is a precision rectifier and log convertor. As Abbey points out the RMS conversion does not follow the classic RMS math completely (SQRT of integral of X^2). After the signal is rectified and squared, the integration stage (and square root of integrated result) are not exactly text book literal. The missing square root operation is academic since in the log domain that is just a scale term (SQRT of Log x = (Log x)/ 2), or one could argue the square root is performed by the VCA gain control scaling. The integration is close but again not exactly to the definition of an ideal integrator. These short cuts can and do introduce tiny deviations from true RMS, but are not significant IMO.

I have already written more than care to about what RMS is and isn't IMO in the context of metering and signal processing (on another forum). The short version is the THAT(dbx) flavor of detection is very successful because it sounds good with a nice attack/release characteristics for dynamic manipulations. I am not convinced that RMS is the secret sauce, it just works well, and it gives the marketing boyz something to flog.

Lets not get ahead of ourselves here... I'd like to hear some feedback about how the simple approach works, before we lobby to change it. I have spent a lot of time designing simultaneous peak/VU metering, and one lesson I could pull from that technology is that the optimal combination of time constants for crest factor detection on a meter which is faster attack for the peak and "identical" slow release time constants for both peak and average, is not optimal for "crest factor" signal processing.

For meters we want the crest factor spread to develop immediately, and then have the spread persist on the display, long after the crest factor event has passed, as both meter displays decay at the same rate (keeping the spread) until the next loud event. For a crest factor signal processor, driven by the measured peak to ave difference, the artificially longer visual display persistence would over detect and over CF compress the signal, since the crest factor condition would appear to be present longer than it really is.  A slower release on the peak than average detector would make this error even worse, so logically we want a faster release on the peak than the average detector.

How much faster still stands to be determined by listening. So for now lets KISS, the two 2252s with different size caps could be close to what we want, and relatively simple to execute.

JR 

PS: This could just be another number crunching mode in my microprocessor controlled dynamics processor (that I will probably never build).

 

[ruairioflaherty]

It can be hard to keep a thread focused on only one topic and I'm as guilty as most of veering off on tangents.

I for one come here every day for the tangents, If I wanted hard facts I'd read for Horrowitz & Hill!

PS: This could just be another number crunching mode in my microprocessor controlled dynamics processor (that I will probably never build).

Apparently George Massenburg is working on an analogue compressor with digital sidechain (at 384kHz for low latency).  I imagine that much of the needed computation for more complex (and subtle) dynamic manipulation is rather easier to do in digital that in analogue. 

Cheers,
Ruairi

 

[JohnRoberts]

oops... tangent alert...

The real power of a digital side chain is you can use a completely nonlinear decision tree for processing..  If this and this is true do that,, or if this and that, then do this other thing. We are no longer stuck with classic analog constraints on decision making complexity. A fast micro can make thousands of decisions in the course of a single musical event. The only thing that is better is adding some time delay (like the RANE noise gate), so we are no longer constrained to only reacting to transients 'after' they have happened.

Of course operating completely in the digital domain, in non-real time, provides us unlimited look ahead capability.   


JR

 

[strangeandbouncy]

Hi,


 fascinating stuff! It's interesting to hear of that digital sidechain. It makes perfect sense, I guess, at least in terms of processing data . When you say "Low Latency", even at 384kHz, in mastering, especially disc-cutting, any latency must surely be a serious problem, no? I am sure that broadcast applications must be very critical in terms of "instantaneous" limiting. In the analog domain, latency is not a problem, I surmise( with high slew-rates anyway(?))


   I am really enjoying this particular thread! - thanks guys!



     perhaps something concrete and really USEFULL will come of this.


ps apart from the RNC, does anyone know of any other (analogue signal-path) compressors with digital controled sidechain?

 

[strangeandbouncy]

JR,



  bring on those Tangents! they are waiting in the wings, just dying to make an appearance . . . .  .




    ANdyP

 

[abbey road d enfer]

Hi,


 fascinating stuff! It's interesting to hear of that digital sidechain. It makes perfect sense, I guess, at least in terms of processing data . When you say "Low Latency", even at 384kHz, in mastering, especially disc-cutting, any latency must surely be a serious problem, no? I am sure that broadcast applications must be very critical in terms of "instantaneous" limiting. In the analog domain, latency is not a problem, I surmise( with high slew-rates anyway(?))

Latency is a problem in real-time applications only. Mastering is not a real-time application, neither is mixing. Broadcast very often is not real-time, since may broadcasters have a permanent 7 seconds delay-line called profanity delay. Recording and concert sound are real-time applications for which it is impossible to delay the main path in order to leave enough time for the side-chain to do whatever it has to do.