[andyc56]

Hi John,
Apologies in advance for the lengthy post.

I wrote a software program that makes extensive use of PEQ filters for sub EQ in the modal region. In order for the user's final measurements to match software predictions after running the software and entering calculated filter parameters into the hardware, the hardware must of course do what the software calculates that it's doing. In the case of miniDSP hardware, when one imports a file of biquad coefficients, this is easily taken care of.

But there is also the case of hardware that requires the user to enter the PEQ center frequency, boost or cut value in dB, and the Q manually for each PEQ. This includes the Behringer iNuke amps and DCX2496 electronic crossover, and the miniDSP hardware when one does not use the method of biquad filter coefficient import. In the case of the Q of PEQ filters, I've run into differences in the definition of Q that have led at times to discrepancies between actual measured performance and performance predicted by the software. But since I don't own any of these hardware items, I can't measure them.

When I first wrote the software, but before it was released, I used the definition below for Q, which I'll call Qp, the "pole Q". The analog domain transfer function I originally used, shown below, is simplified to have a center frequency of 1 rad/sec to avoid clutter. So my original transfer function was:

H(s) = (s^2 + (A0/Qp)*s + 1) / (s^2 + (1/Qp)*s + 1)

Of course, the center frequency gain in dB is 20*log10(A0). My first beta tester was using a Hypex PSC2.400 sub amp. In its PDF manual, it says the following regarding the Q of its PEQ:

Dip/peak filter. For peaks, Q is defined by the poles. For dips, Q is defined by the zeros. Thus the same filter with opposite gains will cancel.

This "perfect cancellation" symmetry property of otherwise identical PEQs having opposite gains seemed a desirable one, so I did some web searches to see if this approach was common. I found this PDF document from THAT Corp, in which equations 1 and 2 show the exact same convention for Q as is used by Hypex. Based on these searches, I naively assumed this definition of Q, which I'll call "the Hypex definition", was a de facto standard of sorts.

At any rate, I changed how PEQs were implemented, to use the "zero Q" (Qz) and the "pole Q" (Qp) as follows, to match what Hypex was doing:

H(s) = (s^2 + (1/Qz)*s + 1) / (s^2 + (1/Qp)*s + 1)

The Q I use, which I'll call the "Hypex Q" or Qh, along with A0, defines Qp and Qz according to the Hypex definition discussed above as follows:

For A0 >= 1, Qp = Qh and Qz = Qh / A0

For A0 < 1, Qz = Qh and Qp = A0 * Qh

This gives the desired symmetry property and also resulted in the beta tester's final data matching the software prediction well. All was well until the user bought a miniDSP about a year later. He originally entered the filter data not by biquad import, but by manual entry into the PEQ blocks of the software. When he did this, the filter responses shown in the miniDSP UI did not match those computed using the Hypex definition of Q. I did some more searching, including HTS.

I found two articles by Robert Bristow-Johnson, one in a PDF file, and another that he calls his "cookbook". He uses yet another definition of Q, which I'll call Qb or "the Bristow-Johnson Q definition", defined by expressing the transfer function as follows:

H(s) = (s^2 + s*(Ab/Qb) + 1) / (s^2 + s/(Ab*Qb) + 1)

This definition also has the boost/cut symmetry of the Hypex definition. With a bit of algebra, the Hypex Q (Qh) can be related to the Bristow-Johnson Q (Qb) by the following formulas:

For A0 >= 1, Qb = Qh / sqrt(A0)

For A0 < 1, Qb = Qh * sqrt(A0)

Also, Ab = sqrt(A0)

In both cases, the Bristow-Johnson Q is lower than the Hypex Q for the same filter.

So it seems there are at least three definitions of Q in actual use, listed as follows:
1) Let "Q" be the pole Q (Qp) and allow asymmetry between the boost/cut versions of otherwise identical PEQs
2) Let "Q" be the Hypex Q (Qh), giving symmetry between the boost/cut versions of otherwise identical PEQs
3) Let "Q" be the Bristow-Johnson Q (Qb), giving symmetry between the boost/cut versions of otherwise identical PEQs, but a different, and lower, numerical value than Qh for the same filter

I'm pretty sure that some users have sent you measured data, and you've done some calculations on them. What I'm most interested in, if you have it, is the following hardware:
1) miniDSP when manual entry of PEQ parameters is used (not biquad coefficients)
2) Behringer iNuke
3) Behringer DCX2496

My question is, "Which Q definition does the hardware above use for manual entry of Q? Pole Q? Hypex definition? Bristow-Johnson definition? Or some other of an infinite number of other possibilities?"

Thanks in advance,
Andy C

 

[JohnM]

REW uses the RBJ cookbook equations for its generic filter setting and uses them internally for all other equaliser types, converting the equaliser's Q or bandwidth parameter to an RBJ-style Q as required. You'll find the relationships for the various equalisers REW supports in the equaliser selection help. I don't have info for the iNuke, but you can work it out by looking at the filter shapes the iNuke configuration tool produces and comparing them to one of the REW filter types.

 

[3ll3d00d]

http://www.rane.com/note167.html might be useful extra info

 

[andyc56]

REW uses the RBJ cookbook equations for its generic filter setting and uses them internally for all other equaliser types, converting the equaliser's Q or bandwidth parameter to an RBJ-style Q as required. You'll find the relationships for the various equalisers REW supports in the equaliser selection help. I don't have info for the iNuke, but you can work it out by looking at the filter shapes the iNuke configuration tool produces and comparing them to one of the REW filter types.

Thanks for that. In the documentation for the generic PEQ, I was initially puzzled to see the expression for the half-gain bandwidth as f0/Q. I've been familiar with this relationship for a bandpass filter and its -3 dB bandwidth for some time, but I'd never seen such an expression derived for a PEQ and its half-gain bandwidth anywhere (as f2 - f1 rather than RBJ's ratio in octaves). When I saw the expression, I originally thought it had to be an approximation. This was because in the RBJ PDF file for PEQs, there are slightly messy expressions for the upper and lower half-gain frequencies (squared) in equations 8 and 9. One must take the square root of the right sides of each of these two equations and subtract them to get the bandwidth. This results in a messy expression that doesn't look at all like f0/Q. So I wrote a short program to calculate the bandwidth for a number of combinations of Q and boost/cut at a 100 Hz center frequency to test this result. Lo and behold, the f0/Q expression for the half-gain bandwidth is exact! I spent some time and was finally able to derive the bandwidth expression from equations 8 and 9 after a lot of algebra.

One last question and I'll quit bugging you. In the REW DCX2496 EQ documentation, it says,

Bandwidth = sqrt(gain)*centre frequency/Q

Is it correct to assume that if the gain is less than 1, one should calculate its reciprocal and enter that in the "gain" field above, giving symmetrical responses for identical boost and cut? Otherwise, if one takes this expression purely literally, a PEQ with a 12 dB boost would have 4x the bandwidth of a PEQ with 12 dB cut and all other parameters identical.

If the responses are symmetrical for boost/cut, that expression would say they are using the same "Q" convention as Hypex, the THAT Corp white paper and MSO.

 

[JohnM]

Is it correct to assume that if the gain is less than 1, one should calculate its reciprocal and enter that in the "gain" field above, giving symmetrical responses for identical boost and cut?

Yes, or equivalently use the absolute value of the gain in dB before converting to the linear gain.

 

[andyc56]

I've added my observations about this issue to an article on my site, including the derivation of the half-gain bandwidth of a parametric EQ in terms of its Q according to the RBJ definition. I'm sure this is old hat to John, but I hadn't seen it online before, so I thought I'd add it.

 

[JohnM]

Nice job! MiniDSP use the RBJ definitions.

 

[andyc56]

REW uses the RBJ cookbook equations for its generic filter setting and uses them internally for all other equaliser types, converting the equaliser's Q or bandwidth parameter to an RBJ-style Q as required. You'll find the relationships for the various equalisers REW supports in the equaliser selection help. I don't have info for the iNuke, but you can work it out by looking at the filter shapes the iNuke configuration tool produces and comparing them to one of the REW filter types.

A user in another forum did some frequency response tests of an iNuke amp using a USB sound card and a step-down device at the iNuke output. In doing a "best fit" test between the RBJ convention for Q and the MSO/DCX2496 convention for the iNuke, it appears that the iNuke uses the RBJ Q convention.

 

[JohnM]

When I looked at the iNuke a couple of years ago with a view to supporting the .arp format the GUI had some pretty odd behaviours which led me to put it on the back burner. For example:

• The frequency intervals are a bit odd, the GUI adjustment range is fairly coarse but it does accept higher resolution if the values are entered in the .arp, but it is not clear how it decides what to accept and what to shift though; .arp file has 1 dp below 1k and 2 dp in kHz above 1k but not all values are accepted by the GUI (e.g. 1k05)
• When the GUI duplicates a 1k00 typed setting to the other channel (e.g. in stereo) it converts it to 990.9! Ditto when the file contains 1k00 values
• You cannot always get the same results by typing a figure into the GUI as you get by using the mouse to change the value (e.g. the 1k00 effect)
• The Q range is very coarse on the GUI above 1.0, but iNuke actually seems to support 0.1 steps with some missing ones

The GUI behaviour may have changed since, of course.

 

[andyc56]

When I looked at the iNuke a couple of years ago with a view to supporting the .arp format the GUI had some pretty odd behaviours which led me to put it on the back burner. For example:

• The frequency intervals are a bit odd, the GUI adjustment range is fairly coarse but it does accept higher resolution if the values are entered in the .arp, but it is not clear how it decides what to accept and what to shift though; .arp file has 1 dp below 1k and 2 dp in kHz above 1k but not all values are accepted by the GUI (e.g. 1k05)
• When the GUI duplicates a 1k00 typed setting to the other channel (e.g. in stereo) it converts it to 990.9! Ditto when the file contains 1k00 values
• You cannot always get the same results by typing a figure into the GUI as you get by using the mouse to change the value (e.g. the 1k00 effect)
• The Q range is very coarse on the GUI above 1.0, but iNuke actually seems to support 0.1 steps with some missing ones

The GUI behaviour may have changed since, of course.

Wow. I hadn't messed with the .arp files before, as I don't actually have a unit. But I just tried playing with them a bit and was able to verify some of what you said above. Stereo mode is indeed very buggy with respect to making the PEQ filters the same in channels 1 and 2. Here's an example:

BEGIN_OSC_DATA
/ampmode s STEREO
/channel/1/peq/1 sfff PEQ 999.8  -3.5 9.99
/channel/1/peq/2 sfff PEQ 1k00  +5.5 9.98
/channel/1/peq/3 sfff PEQ 1k01  +3.5 9.97
/channel/1/peq/4 sfff PEQ 1k02 -11.5 9.96
/channel/1/peq/5 sfff PEQ 1k03  +8.0 9.95
/channel/1/peq/6 sfff PEQ 1k04 +15.0 9.94
/channel/1/peq/7 sfff PEQ 1k05 +12.0 9.93
/channel/1/peq/8 sfff PEQ 1k06 -15.0 9.92
/channel/1/xover/hp sf OFF 30.0
/channel/1/xover/lp sf OFF 200.0
/channel/1/xover/gain f  +0.0
/channel/1/deq/1/comp fff  +0.0 -30.0 5.0
/channel/1/deq/1/time ff 50.0  1000
/channel/1/deq/1/filt sff BP 50.0 1.00
/channel/1/deq/2/comp fff  +0.0 -30.0 5.0
/channel/1/deq/2/time ff 50.0  1000
/channel/1/deq/2/filt sff BP 2k00 1.00
/channel/1/delay fi   0.00 0
/channel/1/limiter fff  100 100.0  50.0
/channel/2/peq/1 sfff PEQ 39.9  -3.5 9.99
/channel/2/peq/2 sfff PEQ 990.9  +5.5 8.71
/channel/2/peq/3 sfff PEQ 1k00  +3.5 4.17
/channel/2/peq/4 sfff PEQ 1k01 -11.5 0.35
/channel/2/peq/5 sfff PEQ 1k02  +8.0 3.02
/channel/2/peq/6 sfff PEQ 1k03 +15.0 3.47
/channel/2/peq/7 sfff PEQ 1k04 +12.0 0.17
/channel/2/peq/8 sfff PEQ 1k04 -15.0 3.02
/channel/2/xover/hp sf OFF 30.0
/channel/2/xover/lp sf OFF 200.0
/channel/2/xover/gain f  +0.0
/channel/2/deq/1/comp fff  +0.0 -30.0 5.0
/channel/2/deq/1/time ff 50.0  1000
/channel/2/deq/1/filt sff BP 49.7 1.00
/channel/2/deq/2/comp fff  +0.0 -30.0 5.0
/channel/2/deq/2/time ff 50.0  1000
/channel/2/deq/2/filt sff BP 2k00 1.00
/channel/2/delay fi   0.00 0
/channel/2/limiter fff  100 100.0  50.0
END_OSC_DATA

Here, the first PEQ had a center frequency of 999.8 Hz entered in the UI. It appears correctly in channel 1, but is copied to channel 2 as 39.9 Hz! Likewise, the center frequency of the second PEQ, entered as 1k00 in the UI, is copied over to channel 2 as 990.9, exactly as you said. The Q values in channel 2 are mostly wrong, though the gains seem correct. The channel 2 Q values look like the ones I entered into the UI before switching from mono to stereo mode.

Using the text entry box for Q values, it appears that there is always a resolution of 0.01, though as you say, this isn't the same as what you get using the virtual adjustment knob in the GUI.

 

[JohnM]

On the plus side you can omit everything apart from the peq stuff in the .arp file and it will be accepted, other settings just remain as they were.