Computed

1.6 kHz peaking eq

Boosts or cuts a band around f0 and leaves both ends of the spectrum at unity. Solved at 8 sample rates, with the poles, the real −3 dB point and the word length it stops working at.

Open the interactive designer →All peaking eq frequencies

Magnitude response at 48 kHz

Every vertex is 20·log₁₀|H(e^jω)| evaluated on the unit circle — not a sketch of the filter's shape. The faint traces behind it are the same corner at every Q in the sweep below.

Gain at f0 (1.6 kHz)

+6.00 dB

exact at every sample rate — the bilinear transform maps this value, not just the frequency

Pole radius at 48 kHz

0.9289240

conjugate pair at ±11.24°, 0.0711 from the circle

−3 dB point

989.4 Hz

0.618× f0 at Q = 1.0000

16-bit fixed point

holds

largest pole 0.9289322 in Q1.14

Coefficients, at every sample rate

The cookbook computes w₀ = 2πf₀/F_s, so the same filter is a different set of numbers at every rate. Rates whose Nyquist limit is at or below 1.6 kHz are absent because the filter does not exist there — equivalently, the f₀/Nyquist column never reaches 100%. That is why this table is 8 rows and a 20 Hz page is 8.

Sample rate	b0	b1	b2	a1	a2	Pole r	f₀/Nyquist
8 kHz	1.250667	-0.462376	0.245613	-0.462376	0.496280	0.704471	40.0%
16 kHz	1.171411	-1.339366	0.484136	-1.339366	0.655547	0.809658	20.0%
22.1 kHz	1.134198	-1.553583	0.596129	-1.553583	0.730327	0.854592	14.5%
32 kHz	1.098131	-1.714567	0.704671	-1.714567	0.802803	0.895993	10.0%
44.1 kHz	1.073719	-1.803951	0.778141	-1.803951	0.851860	0.922963	7.3%
48 kHz	1.068225	-1.822191	0.794674	-1.822191	0.862900	0.928924	6.7%
96 kHz	1.035511	-1.918075	0.893129	-1.918075	0.928640	0.963660	3.3%
192 kHz	1.018102	-1.960932	0.945520	-1.960932	0.963623	0.981643	1.7%

const float b0 = 1.06822538f, b1 = -1.82219088f, b2 = 0.79467433f;
const float a1 = -1.82219088f, a2 = 0.86289971f;   // a0 == 1

What word length this filter survives

The fixed-point rows round all five coefficients to one shared scale, which is what a q15/q31 biquad section does with its post-shift.Pole radius is solved from the quadratic, not taken as √|a₂| — once rounding pushes the poles onto the real axis those two disagree, and the convenient one reports a comfortable margin on a filter that has already left the unit circle. Error is the worst deviation from float64 across frequencies where the response is within 40 dB of its own peak; below that it is measuring the −200 dB floor.

Word format	Q format	Largest pole	√\|a₂\| says	Stable	Worst error in band
float64	—	0.9289240	0.9289240	yes	reference
float32	—	0.9289240	0.9289240	yes	0.0000 dB
32-bit fixed	Q1.30	0.9289239	0.9289239	yes	0.0000 dB
24-bit fixed	Q1.22	0.9289240	0.9289240	yes	0.0000 dB
16-bit fixed	Q1.14	0.9289322	0.9289322	yes	0.0013 dB

What Q does at 1.6 kHz

f₀ does not move with Q — the −3 dB point does. They are the same frequency only at Q = 1/√2, which is why a Butterworth corner is the one people quote and why every other Q surprises somebody.

Q	At f₀	Peak	−3 dB	Pole r	Group delay at f₀
0.5	+6.00 dB	+6.00 dB @ 1.61 kHz	3806 Hz	0.862201	0.071 ms
0.7071	+6.00 dB	+6.00 dB @ 1.61 kHz	3067 Hz	0.900813	0.100 ms
1	+6.00 dB	+6.00 dB @ 1.61 kHz	2578 Hz	0.928924	0.141 ms
2	+6.00 dB	+6.00 dB @ 1.61 kHz	2047 Hz	0.963855	0.282 ms
4	+6.00 dB	+5.99 dB @ 1.61 kHz	1812 Hz	0.981767	0.565 ms
10	+6.00 dB	+5.93 dB @ 1.61 kHz	1684 Hz	0.992667	1.411 ms

What gain does at 1.6 kHz

A peaking filter puts its full gain at f₀ and returns to unity at both ends of the spectrum.

Gain	At f₀	b0	a1	a2	Pole r
-12 dB	−12.00 dB	0.871364	-1.620229	0.656426	0.810201
-6 dB	−6.00 dB	0.936132	-1.705811	0.743920	0.862508
-3 dB	−3.00 dB	0.967884	-1.741171	0.780069	0.883215
+3 dB	+3.00 dB	1.033181	-1.798945	0.839135	0.916043
+6 dB	+6.00 dB	1.068225	-1.822191	0.862900	0.928924
+12 dB	+12.00 dB	1.147626	-1.859417	0.900958	0.949188

Questions this filter answers

What are the biquad coefficients for a 1.6 kHz peaking EQ filter at 48 kHz?

b0 = 1.068225, b1 = -1.822191, b2 = 0.794674, a1 = -1.822191, a2 = 0.862900, with a0 normalised to 1 — the RBJ Audio EQ Cookbook form at Q = 1.0000 and +6 dB of gain. Every other sample rate in the table above gives different numbers for the same filter, because w0 = 2πf0/Fs and every cosine and sine downstream of it moves.

Is a 1.6 kHz peaking EQ filter stable in 16-bit fixed point?

Yes. Rounding the five coefficients to a shared 1.14 scale leaves the largest pole at 0.9289322, against 0.9289240 exact, and the response drifts by at most 0.001 dB inside the band. 24-bit takes that to 0.0000 dB.

Where is the real −3 dB point of a 1.6 kHz peaking EQ filter?

989.4 Hz, which is 0.618× the 1.6 kHz corner. f0 and the −3 dB point are the same frequency only at Q = 1/√2; this page is designed at Q = 1.0000, and the Q sweep above shows the point moving from 3806.2 Hz to 1683.6 Hz across the sweep while f0 never moves.

How close to the unit circle are the poles of a 1.6 kHz peaking EQ filter?

0.9289240 at 48 kHz, as a conjugate pair at ±11.24°. Pole radius rises toward 1 as the corner frequency falls relative to the sample rate — the same filter at 192 kHz sits at 0.9816430 and at 8 kHz at 0.7044714. That distance is the whole story of the fixed-point table: a pole a few parts in 10⁵ from the circle has nowhere to be rounded to.

The neighbouring corners

One third-octave either side, and the same 1.6 kHz corner as every other filter type.

Method and limits. Coefficients follow the RBJ Audio EQ Cookbook, the bilinear transform of the analog prototype prewarped so the corner lands exactly on f0 — which is why +6.00 dB at 1.6 kHz holds at every sample rate in the table rather than only at low f0/Fs. Shelves fix the slope at S = 1, matching Web Audio's BiquadFilterNode, so Q is not read for those two types. Pole and zero radii are the roots of the quadratic, not sqrt(|a2|). The fixed-point rows model a single shared coefficient scale and no other quantisation: they say nothing about signal-path headroom, limit cycles or the accumulator width your implementation uses, all of which can make a filter that passes this table still misbehave. Nothing on this page is fetched or estimated — it is solved from the type and the frequency in the URL.