In case it isn't clear the value used in the drc file is the number of samples the window will be but it is also on both sides of the impulse centre so the value is double what the corresponding window length will be. So 24000 / 1/44100 =0.544 S. For the 48000 value used in the strong file.You just pointed out the comment in the strong*.drc file "(544 ms at 20 Hz, 108 ms at 100 Hz, 10.8 ms at 1 kHz, 0.54 ms at 20 kHz)" relating it to FDWing and made it click. I think I know how to control different FDW's at different frequency ranges with this tool. I noticed those values when making the 176400.drc file and their application relevance didn't sink in until now.
When the sample rate changes the values need to be scaled up or down to keep the relative window lengths the same.
I am using 26460 at 44100 which works out to be 0.3 S at 20Hz.
Thanks gents. So it is:
I have been playing with the test convolutions and am noticing the trends generated by varying the XXWindowExponent.
Code:
(XXLowerWindow/2) * (1/BCSampleRate) = xx.xx seconds @ XXStartFreq
(XXUpperWindow/2) * (1/BCSampleRate) = xx.xx seconds @ XXEndFreq
with XXWindowExponent defining the integral curve between the 2
I have been playing with the test convolutions and am noticing the trends generated by varying the XXWindowExponent.
The attached snip from the manual explains it
All of the window lengths are printed to the screen as the program runs. You can have these remain on screen by putting a pause command into the script or you can redirect the whole lot to a text file. Much easier than running a lot of calculations.
Basically exponents under 1.0 push the mid band down in window time and those over 1.0 push it up but a 0.1 change in exponent is quite a lot.
All of the window lengths are printed to the screen as the program runs. You can have these remain on screen by putting a pause command into the script or you can redirect the whole lot to a text file. Much easier than running a lot of calculations.
Basically exponents under 1.0 push the mid band down in window time and those over 1.0 push it up but a 0.1 change in exponent is quite a lot.
Attachments
An example of my window at 44100:
Slightly different from a standard template as I let it run up to 22500 Hz in the top end.
R - Band: 0, 20.0 Hz, width: 13230, FIR, convolution...
R - Band: 1, 25.2 Hz, width: 9822, FIR, convolution...
R - Band: 2, 31.8 Hz, width: 7417, FIR, convolution...
R - Band: 3, 40.0 Hz, width: 5670, FIR, convolution...
R - Band: 4, 50.4 Hz, width: 4374, FIR, convolution...
R - Band: 5, 63.5 Hz, width: 3398, FIR, convolution...
R - Band: 6, 80.0 Hz, width: 2653, FIR, convolution...
R - Band: 7, 100.8 Hz, width: 2081, FIR, convolution...
R - Band: 8, 127.1 Hz, width: 1637, FIR, convolution...
R - Band: 9, 160.1 Hz, width: 1292, FIR, convolution...
R - Band: 10, 201.7 Hz, width: 1022, FIR, convolution...
R - Band: 11, 254.0 Hz, width: 811, FIR, convolution...
R - Band: 12, 320.4 Hz, width: 644, FIR, convolution...
R - Band: 13, 403.7 Hz, width: 513, FIR, convolution...
R - Band: 14, 508.2 Hz, width: 410, FIR, convolution...
R - Band: 15, 641.0 Hz, width: 328, FIR, convolution...
R - Band: 16, 809.1 Hz, width: 263, FIR, convolution...
R - Band: 17, 1019.7 Hz, width: 212, FIR, convolution...
R - Band: 18, 1281.9 Hz, width: 172, FIR, convolution...
R - Band: 19, 1614.6 Hz, width: 140, FIR, convolution...
R - Band: 20, 2047.0 Hz, width: 114, FIR, convolution...
R - Band: 21, 2578.9 Hz, width: 94, FIR, convolution...
R - Band: 22, 3256.4 Hz, width: 78, FIR, convolution...
R - Band: 23, 4140.9 Hz, width: 65, FIR, convolution...
R - Band: 24, 5235.5 Hz, width: 55, FIR, convolution...
R - Band: 25, 6640.3 Hz, width: 47, FIR, convolution...
R - Band: 26, 8314.2 Hz, width: 41, FIR, convolution...
R - Band: 27, 10525.4 Hz, width: 36, FIR, convolution...
R - Band: 28, 13371.4 Hz, width: 32, FIR, convolution...
R - Band: 29, 16774.4 Hz, width: 29, FIR, convolution...
F - Band: 30, 22500.0 Hz, width: 26, FIR, completed.
Slightly different from a standard template as I let it run up to 22500 Hz in the top end.
Cool, I may try to tweak the output to additionally display ms and cycles. Using the normalized cycles unit would be more intuitive (at least to me) across different sampling rates.An example of my window at 44100:
Slightly different from a standard template as I let it run up to 22500 Hz in the top end.
Here is mine using the same normalized values, but not immediately obvious without displaying cycles.
Code:
R - Band: 0, 10.0 Hz, width: 52920, FIR, convolution...
R - Band: 1, 11.4 Hz, width: 52919, FIR, convolution...
R - Band: 2, 12.8 Hz, width: 52918, FIR, convolution...
R - Band: 3, 14.2 Hz, width: 52917, FIR, convolution...
R - Band: 4, 17.1 Hz, width: 52915, FIR, convolution...
R - Band: 5, 18.5 Hz, width: 52914, FIR, convolution...
R - Band: 6, 21.3 Hz, width: 52912, FIR, convolution...
R - Band: 7, 22.7 Hz, width: 52911, FIR, convolution...
R - Band: 8, 25.6 Hz, width: 52909, FIR, convolution...
R - Band: 9, 28.4 Hz, width: 52907, FIR, convolution...
R - Band: 10, 32.6 Hz, width: 52904, FIR, convolution...
R - Band: 11, 36.9 Hz, width: 52901, FIR, convolution...
R - Band: 12, 41.1 Hz, width: 52898, FIR, convolution...
R - Band: 13, 45.4 Hz, width: 52895, FIR, convolution...
R - Band: 14, 51.0 Hz, width: 52891, FIR, convolution...
R - Band: 15, 56.7 Hz, width: 52887, FIR, convolution...
R - Band: 16, 63.7 Hz, width: 52882, FIR, convolution...
R - Band: 17, 72.2 Hz, width: 52876, FIR, convolution...
R - Band: 18, 80.6 Hz, width: 52870, FIR, convolution...
R - Band: 19, 90.5 Hz, width: 52863, FIR, convolution...
R - Band: 20, 101.8 Hz, width: 52855, FIR, convolution...
R - Band: 21, 114.4 Hz, width: 52846, FIR, convolution...
R - Band: 22, 127.1 Hz, width: 52837, FIR, convolution...
R - Band: 23, 142.6 Hz, width: 52826, FIR, convolution...
R - Band: 24, 160.8 Hz, width: 52813, FIR, convolution...
R - Band: 25, 180.5 Hz, width: 52799, FIR, convolution...
R - Band: 26, 202.9 Hz, width: 52783, FIR, convolution...
R - Band: 27, 226.7 Hz, width: 52766, FIR, convolution...
R - Band: 28, 254.6 Hz, width: 52746, FIR, convolution...
R - Band: 29, 285.3 Hz, width: 52724, FIR, convolution...
R - Band: 30, 320.1 Hz, width: 52699, FIR, convolution...
R - Band: 31, 360.4 Hz, width: 52670, FIR, convolution...
R - Band: 32, 403.3 Hz, width: 52639, FIR, convolution...
R - Band: 33, 453.1 Hz, width: 52603, FIR, convolution...
R - Band: 34, 508.2 Hz, width: 52563, FIR, convolution...
R - Band: 35, 571.4 Hz, width: 52517, FIR, convolution...
R - Band: 36, 641.2 Hz, width: 52466, FIR, convolution...
R - Band: 37, 718.8 Hz, width: 52409, FIR, convolution...
R - Band: 38, 807.0 Hz, width: 52344, FIR, convolution...
R - Band: 39, 905.4 Hz, width: 52271, FIR, convolution...
R - Band: 40, 1016.6 Hz, width: 52188, FIR, convolution...
R - Band: 41, 1140.4 Hz, width: 52095, FIR, convolution...
R - Band: 42, 1280.5 Hz, width: 51989, FIR, convolution...
R - Band: 43, 1437.6 Hz, width: 51869, FIR, convolution...
R - Band: 44, 1613.9 Hz, width: 51733, FIR, convolution...
R - Band: 45, 1811.4 Hz, width: 51579, FIR, convolution...
R - Band: 46, 2033.0 Hz, width: 51404, FIR, convolution...
R - Band: 47, 2281.5 Hz, width: 51205, FIR, convolution...
R - Band: 48, 2560.5 Hz, width: 50978, FIR, convolution...
R - Band: 49, 2874.2 Hz, width: 50718, FIR, convolution...
R - Band: 50, 3225.4 Hz, width: 50421, FIR, convolution...
R - Band: 51, 3620.5 Hz, width: 50079, FIR, convolution...
R - Band: 52, 4064.8 Hz, width: 49684, FIR, convolution...
R - Band: 53, 4561.5 Hz, width: 49229, FIR, convolution...
R - Band: 54, 5120.5 Hz, width: 48699, FIR, convolution...
R - Band: 55, 5747.2 Hz, width: 48081, FIR, convolution...
R - Band: 56, 6451.0 Hz, width: 47355, FIR, convolution...
R - Band: 57, 7240.8 Hz, width: 46497, FIR, convolution...
R - Band: 58, 8127.8 Hz, width: 45474, FIR, convolution...
R - Band: 59, 9123.6 Hz, width: 44243, FIR, convolution...
R - Band: 60, 10240.5 Hz, width: 42746, FIR, convolution...
R - Band: 61, 11494.6 Hz, width: 40898, FIR, convolution...
R - Band: 62, 12902.0 Hz, width: 38578, FIR, convolution...
R - Band: 63, 14481.6 Hz, width: 35601, FIR, convolution...
R - Band: 64, 16255.2 Hz, width: 31671, FIR, convolution...
R - Band: 65, 18245.6 Hz, width: 26289, FIR, convolution...
R - Band: 66, 20480.2 Hz, width: 18528, FIR, convolution...
R - Band: 67, 22988.2 Hz, width: 6471, FIR, convolution...
F - Band: 68, 24000.0 Hz, width: 96, FIR, completed.
My sweep is from [10-24k]Hz @ 176.4kHz using 1/6th octave bands versus the default 1/3rd octave bands.
Last edited:
Added the ms and cycles to the log output. The print changes were pretty simple.
I was surprised to see the cycles decrease and then increase.
Have to investigate what settings is causing this.
I was surprised to see the cycles decrease and then increase.
Have to investigate what settings is causing this.
Code:
R - Band: 0, 10.0 Hz, width: 52920, ms: 300.00, cycles: 3.00, sr: 176400, FIR, convolution...
R - Band: 1, 11.2 Hz, width: 45485, ms: 257.85, cycles: 2.89, sr: 176400, FIR, convolution...
R - Band: 2, 12.6 Hz, width: 39293, ms: 222.75, cycles: 2.81, sr: 176400, FIR, convolution...
R - Band: 3, 14.1 Hz, width: 34087, ms: 193.24, cycles: 2.73, sr: 176400, FIR, convolution...
R - Band: 4, 15.9 Hz, width: 29676, ms: 168.23, cycles: 2.67, sr: 176400, FIR, convolution...
R - Band: 5, 17.8 Hz, width: 25915, ms: 146.91, cycles: 2.62, sr: 176400, FIR, convolution...
R - Band: 6, 20.0 Hz, width: 22690, ms: 128.63, cycles: 2.57, sr: 176400, FIR, convolution...
R - Band: 7, 22.4 Hz, width: 19911, ms: 112.87, cycles: 2.53, sr: 176400, FIR, convolution...
R - Band: 8, 25.2 Hz, width: 17507, ms: 99.25, cycles: 2.50, sr: 176400, FIR, convolution...
R - Band: 9, 28.3 Hz, width: 15420, ms: 87.41, cycles: 2.47, sr: 176400, FIR, convolution...
R - Band: 10, 31.7 Hz, width: 13602, ms: 77.11, cycles: 2.45, sr: 176400, FIR, convolution...
R - Band: 11, 35.6 Hz, width: 12014, ms: 68.11, cycles: 2.43, sr: 176400, FIR, convolution...
R - Band: 12, 40.0 Hz, width: 10624, ms: 60.23, cycles: 2.41, sr: 176400, FIR, convolution...
R - Band: 13, 44.9 Hz, width: 9405, ms: 53.32, cycles: 2.39, sr: 176400, FIR, convolution...
R - Band: 14, 50.4 Hz, width: 8334, ms: 47.24, cycles: 2.38, sr: 176400, FIR, convolution...
R - Band: 15, 56.6 Hz, width: 7392, ms: 41.90, cycles: 2.37, sr: 176400, FIR, convolution...
R - Band: 16, 63.5 Hz, width: 6561, ms: 37.19, cycles: 2.36, sr: 176400, FIR, convolution...
R - Band: 17, 71.3 Hz, width: 5828, ms: 33.04, cycles: 2.35, sr: 176400, FIR, convolution...
R - Band: 18, 80.0 Hz, width: 5180, ms: 29.37, cycles: 2.35, sr: 176400, FIR, convolution...
R - Band: 19, 89.8 Hz, width: 4608, ms: 26.12, cycles: 2.35, sr: 176400, FIR, convolution...
R - Band: 20, 100.8 Hz, width: 4101, ms: 23.25, cycles: 2.34, sr: 176400, FIR, convolution...
R - Band: 21, 113.2 Hz, width: 3652, ms: 20.70, cycles: 2.34, sr: 176400, FIR, convolution...
R - Band: 22, 127.0 Hz, width: 3254, ms: 18.45, cycles: 2.34, sr: 176400, FIR, convolution...
R - Band: 23, 142.6 Hz, width: 2902, ms: 16.45, cycles: 2.35, sr: 176400, FIR, convolution...
R - Band: 24, 160.0 Hz, width: 2589, ms: 14.68, cycles: 2.35, sr: 176400, FIR, convolution...
R - Band: 25, 179.6 Hz, width: 2311, ms: 13.10, cycles: 2.35, sr: 176400, FIR, convolution...
R - Band: 26, 201.7 Hz, width: 2064, ms: 11.70, cycles: 2.36, sr: 176400, FIR, convolution...
R - Band: 27, 226.4 Hz, width: 1845, ms: 10.46, cycles: 2.37, sr: 176400, FIR, convolution...
R - Band: 28, 254.0 Hz, width: 1651, ms: 9.36, cycles: 2.38, sr: 176400, FIR, convolution...
R - Band: 29, 285.1 Hz, width: 1478, ms: 8.38, cycles: 2.39, sr: 176400, FIR, convolution...
R - Band: 30, 320.1 Hz, width: 1324, ms: 7.51, cycles: 2.40, sr: 176400, FIR, convolution...
R - Band: 31, 359.4 Hz, width: 1187, ms: 6.73, cycles: 2.42, sr: 176400, FIR, convolution...
R - Band: 32, 403.6 Hz, width: 1065, ms: 6.04, cycles: 2.44, sr: 176400, FIR, convolution...
R - Band: 33, 452.9 Hz, width: 957, ms: 5.43, cycles: 2.46, sr: 176400, FIR, convolution...
R - Band: 34, 508.3 Hz, width: 861, ms: 4.88, cycles: 2.48, sr: 176400, FIR, convolution...
R - Band: 35, 570.8 Hz, width: 775, ms: 4.39, cycles: 2.51, sr: 176400, FIR, convolution...
R - Band: 36, 640.5 Hz, width: 699, ms: 3.96, cycles: 2.54, sr: 176400, FIR, convolution...
R - Band: 37, 719.2 Hz, width: 631, ms: 3.58, cycles: 2.57, sr: 176400, FIR, convolution...
R - Band: 38, 806.7 Hz, width: 571, ms: 3.24, cycles: 2.61, sr: 176400, FIR, convolution...
R - Band: 39, 906.0 Hz, width: 517, ms: 2.93, cycles: 2.66, sr: 176400, FIR, convolution...
R - Band: 40, 1017.3 Hz, width: 469, ms: 2.66, cycles: 2.70, sr: 176400, FIR, convolution...
R - Band: 41, 1143.3 Hz, width: 426, ms: 2.41, cycles: 2.76, sr: 176400, FIR, convolution...
R - Band: 42, 1283.8 Hz, width: 388, ms: 2.20, cycles: 2.82, sr: 176400, FIR, convolution...
R - Band: 43, 1437.3 Hz, width: 355, ms: 2.01, cycles: 2.89, sr: 176400, FIR, convolution...
R - Band: 44, 1619.2 Hz, width: 324, ms: 1.84, cycles: 2.97, sr: 176400, FIR, convolution...
R - Band: 45, 1811.6 Hz, width: 298, ms: 1.69, cycles: 3.06, sr: 176400, FIR, convolution...
R - Band: 46, 2034.9 Hz, width: 274, ms: 1.55, cycles: 3.16, sr: 176400, FIR, convolution...
R - Band: 47, 2280.9 Hz, width: 253, ms: 1.43, cycles: 3.27, sr: 176400, FIR, convolution...
R - Band: 48, 2561.2 Hz, width: 234, ms: 1.33, cycles: 3.40, sr: 176400, FIR, convolution...
R - Band: 49, 2877.6 Hz, width: 217, ms: 1.23, cycles: 3.54, sr: 176400, FIR, convolution...
R - Band: 50, 3229.7 Hz, width: 202, ms: 1.15, cycles: 3.70, sr: 176400, FIR, convolution...
R - Band: 51, 3646.2 Hz, width: 188, ms: 1.07, cycles: 3.89, sr: 176400, FIR, convolution...
R - Band: 52, 4099.5 Hz, width: 176, ms: 1.00, cycles: 4.09, sr: 176400, FIR, convolution...
R - Band: 53, 4573.3 Hz, width: 166, ms: 0.94, cycles: 4.30, sr: 176400, FIR, convolution...
R - Band: 54, 5171.0 Hz, width: 156, ms: 0.88, cycles: 4.57, sr: 176400, FIR, convolution...
R - Band: 55, 5774.9 Hz, width: 148, ms: 0.84, cycles: 4.85, sr: 176400, FIR, convolution...
R - Band: 56, 6538.6 Hz, width: 140, ms: 0.79, cycles: 5.19, sr: 176400, FIR, convolution...
R - Band: 57, 7258.5 Hz, width: 134, ms: 0.76, cycles: 5.51, sr: 176400, FIR, convolution...
R - Band: 58, 8156.7 Hz, width: 128, ms: 0.73, cycles: 5.92, sr: 176400, FIR, convolution...
R - Band: 59, 9308.7 Hz, width: 122, ms: 0.69, cycles: 6.44, sr: 176400, FIR, convolution...
R - Band: 60, 10276.4 Hz, width: 118, ms: 0.67, cycles: 6.87, sr: 176400, FIR, convolution...
R - Band: 61, 11811.2 Hz, width: 113, ms: 0.64, cycles: 7.57, sr: 176400, FIR, convolution...
R - Band: 62, 12973.8 Hz, width: 110, ms: 0.62, cycles: 8.09, sr: 176400, FIR, convolution...
R - Band: 63, 14934.0 Hz, width: 106, ms: 0.60, cycles: 8.97, sr: 176400, FIR, convolution...
R - Band: 64, 16842.6 Hz, width: 103, ms: 0.58, cycles: 9.83, sr: 176400, FIR, convolution...
R - Band: 65, 18411.3 Hz, width: 101, ms: 0.57, cycles: 10.54, sr: 176400, FIR, convolution...
R - Band: 66, 21401.4 Hz, width: 98, ms: 0.56, cycles: 11.89, sr: 176400, FIR, convolution...
F - Band: 67, 24000.0 Hz, width: 96, ms: 0.54, cycles: 13.06, sr: 176400, FIR, completed.
Well, that would be the desired effect of something like MPWindowExponent being smaller than one. 🙂
Here's my list of cycles related to the previously presented numbers...
Presenting it as code to keep the spacing equal 😉
Here's my list of cycles related to the previously presented numbers...
Code:
R - Band: 0, 20.0 Hz, width: 13230, Cycles: 6.00
R - Band: 1, 25.2 Hz, width: 9822, Cycles: 5.61
R - Band: 2, 31.8 Hz, width: 7417, Cycles: 5.35
R - Band: 3, 40.0 Hz, width: 5670, Cycles: 5.14
R - Band: 4, 50.4 Hz, width: 4374, Cycles: 5.00
R - Band: 5, 63.5 Hz, width: 3398, Cycles: 4.89
R - Band: 6, 80.0 Hz, width: 2653, Cycles: 4.81
R - Band: 7, 100.8 Hz, width: 2081, Cycles: 4.76
R - Band: 8, 127.1 Hz, width: 1637, Cycles: 4.71
R - Band: 9, 160.1 Hz, width: 1292, Cycles: 4.69
R - Band: 10, 201.7 Hz, width: 1022, Cycles: 4.67
R - Band: 11, 254.0 Hz, width: 811, Cycles: 4.67
R - Band: 12, 320.4 Hz, width: 644, Cycles: 4.68
R - Band: 13, 403.7 Hz, width: 513, Cycles: 4.70
R - Band: 14, 508.2 Hz, width: 410, Cycles: 4.72
R - Band: 15, 641.0 Hz, width: 328, Cycles: 4.77
R - Band: 16, 809.1 Hz, width: 263, Cycles: 4.83
R - Band: 17, 1019.7 Hz, width: 212, Cycles: 4.90
R - Band: 18, 1281.9 Hz, width: 172, Cycles: 5.00
R - Band: 19, 1614.6 Hz, width: 140, Cycles: 5.13
R - Band: 20, 2047.0 Hz, width: 114, Cycles: 5.29
R - Band: 21, 2578.9 Hz, width: 94, Cycles: 5.50
R - Band: 22, 3256.4 Hz, width: 78, Cycles: 5.75
R - Band: 23, 4140.9 Hz, width: 65, Cycles: 6.10
R - Band: 24, 5235.5 Hz, width: 55, Cycles: 6.53
R - Band: 25, 6640.3 Hz, width: 47, Cycles: 7.08
R - Band: 26, 8314.2 Hz, width: 41, Cycles: 7.73
R - Band: 27, 10525.4 Hz, width: 36, Cycles: 8.59
R - Band: 28, 13371.4 Hz, width: 32, Cycles: 9.70
R - Band: 29, 16774.4 Hz, width: 29, Cycles: 11.03
F - Band: 30, 22500.0 Hz, width: 26, Cycles: 13.27
All of the default UpperWindow values appear to end up with more cycles than the LowerWindow starting # of cycles implying more HF corrections.
I would have assumed the desired trend would be a taper from larger to smaller in the # of cycles but that does not appear to be happening.
I would have assumed the desired trend would be a taper from larger to smaller in the # of cycles but that does not appear to be happening.
I can say that for me, the list I presented here actually is what I actually wanted to achieve 🙂.
Basically, if you'd begin with one of the standard templates, they have a fixed number of cycles (more or less, if we don't consider
the rounding errors).
See the green line with the WindowExponent being 1, if the top and bottom settings have an equal number of cycles, they will hold that
number of cycles throughout every frequency. Just set MPLowerWindow and MPUpperWindow to achieve the desired number of cycles.
If you'd take that as the base settings, and add a MPWindowExponent argument and make it less than 1, it would taper at mid frequencies.
Just like the graphs predicted. Should you want something different (I really don't with a template for an array) you would need
to set the MPUpperWindow to the desired number you want for the cycles of correction you want to end at. Then you can make
it taper down to that value like you mentioned (with the right WindowExponent).
I actually want a longer window on top with my array, both to accommodate the varying time arrival of arrays at high frequencies
but also because listening tests have shown me what the longer window on top can do for things like imaging and tonality.
Basically, if you'd begin with one of the standard templates, they have a fixed number of cycles (more or less, if we don't consider
the rounding errors).
See the green line with the WindowExponent being 1, if the top and bottom settings have an equal number of cycles, they will hold that
number of cycles throughout every frequency. Just set MPLowerWindow and MPUpperWindow to achieve the desired number of cycles.
If you'd take that as the base settings, and add a MPWindowExponent argument and make it less than 1, it would taper at mid frequencies.
Just like the graphs predicted. Should you want something different (I really don't with a template for an array) you would need
to set the MPUpperWindow to the desired number you want for the cycles of correction you want to end at. Then you can make
it taper down to that value like you mentioned (with the right WindowExponent).
I actually want a longer window on top with my array, both to accommodate the varying time arrival of arrays at high frequencies
but also because listening tests have shown me what the longer window on top can do for things like imaging and tonality.
Last edited:
Just a note, if you set MPPrefilterType to "S", a sliding window is used and you're not really using 1/3th or 1/6th octave bands but a stepless way of going through the octaves.My sweep is from [10-24k]Hz @ 176.4kHz using 1/6th octave bands versus the default 1/3rd octave bands.
See:
6.4.11 MPBandSplit
Fractional octave splitting of band windowing. Band windowing is performed in 1 / MPBandSplit of octave bands. Usual values are between 2 and 6. The higher this value the higher should be MPFilterLen. Values greater than 6 usually give no improvements.
For the sliding lowpass prefiltering this just gives the rate at which log messages are reported during the prefiltering procedure and has no effect on the prefiltering procedure itself, which is always stepless.
So the only real difference is the amount of messages you get in the logfile, once that MPPrefilterType is set to "S". In other words, a recommended tweak.
Just to add something to the above, the parameters are interactive and in your example you have increased the frequency extension at either end which is causing the parameters to react differently.I was surprised to see the cycles decrease and then increase.
Have to investigate what settings is causing this.
By using 10Hz at the bottom an octave higher at 20Hz the window has dropped to 128ms. If you set the window to 20Hz and used the same sample value you would get 300ms at 20Hz. You will likely need quite different sample and exponent values to get something similar to the values wesayso showed.
I agree with wesayso that the most critical window is that in the midrange and that it should not be too long. I would try a baseline config that uses window lengths similar to his and experiment from there. I suspect that you will end up back at something pretty close to wesayso's values. I did.
Say I want 6 cycles at 20 Hz. What number do I need to set MPLowerWindow to?
20 Hz, is 20 cycles per second. 1 cycle is: 1/20= 0.05 second. I want 6 cycles, right?
So I need 6 x 0.05 = 0.3 seconds (or 300 ms).
At 44100 I'd need 44100 x 0.3 = 13230.
If you remember from an earlier post from fluid, the number you fill in at MPLowerWindow is twice as big.
Say you want 6 cycles at 176.400 sample rate starting at 10 Hz.
1/10 = 0.1. 6 of these cycles duration is 0.6, so 0.6 x 176400 = 105840
MPLowerWindow would have to be: 211680 to achieve 6 cycles at 10 Hz using 176400 sample rate.
I hope this helps. 176400 is 4x 44100. So to translate a 44100 template to 176400 you could multiply all the window numbers times 4.
But once you move from 20 Hz down to 10 Hz, the window size needs to double to stay 6 cycles long.
Ditto for the top end...
20 Hz, is 20 cycles per second. 1 cycle is: 1/20= 0.05 second. I want 6 cycles, right?
So I need 6 x 0.05 = 0.3 seconds (or 300 ms).
At 44100 I'd need 44100 x 0.3 = 13230.
If you remember from an earlier post from fluid, the number you fill in at MPLowerWindow is twice as big.
So in this case MPLowerWindow would land at: 26460. Now where have I seen that number before...fluid said:In case it isn't clear the value used in the drc file is the number of samples the window will be but it is also on both sides of the impulse centre so the value is double what the corresponding window length will be. So 24000 / 1/44100 =0.544 S. For the4800044100 value used in the strong file.
fluid said:I am using 26460 at 44100 which works out to be 0.3 S at 20Hz.
wesayso said:ditto on that number at 44100 for me @ 20 Hz.
Say you want 6 cycles at 176.400 sample rate starting at 10 Hz.
1/10 = 0.1. 6 of these cycles duration is 0.6, so 0.6 x 176400 = 105840
MPLowerWindow would have to be: 211680 to achieve 6 cycles at 10 Hz using 176400 sample rate.
I hope this helps. 176400 is 4x 44100. So to translate a 44100 template to 176400 you could multiply all the window numbers times 4.
But once you move from 20 Hz down to 10 Hz, the window size needs to double to stay 6 cycles long.
Ditto for the top end...
Thanks Gents.
I read up on the band split (there are a lot of tuning knobs in DRC) and tried both ways. The sliding window is supposed to be numerically more accurate by omitting the summation errors at the band boundaries. That being said, I haven't been able to detect any significant deltas in REW between the 2 algorithms.
I figured out how to get N cycles at 10Hz and 24Hz. Printing out the # cycles is more intuitive. It seems it would be more user friendly to specify start/stop cycles, start/stop frequency and sampling rate making the configuration files samplerate independent (except for specifying the single sample rate). Can probably do that in a script and automate the relationship between the different window values.
I also figured out why it wasn't following the target curve as I expected. The Psychoacoustic pass overrides the target curve.
Also figured out the target curve is at the FDW and not the actual room's response the mic sees (after disabling the Psychoacoustic filter). Updated the scripts to build both with and without the Psychoacoustic pass for listening tests.
I tarred up the Windows directory tree and moved it over to Linux where I have better tools. Converted the .bat to .sh scripts and made both channels compute in parallel and automatically deposit the filters in CamillaDSP's filters directory. Can also generate multiple filter type sets in parallel keeping the aggregate linear generation time to 1x (vs Nx) until I run out of CPU threads. This greatly streamlines the workflow. Export IR's from REW's measurements, double click on a desktop icon and newly installed filter sets are ready in just over a minute with no more hand copying.
Also investigating why the left and right RMS values get changed and playing with dynamic range compression. It looks like the largest swing in the frequency range determines how much a channel's RMS value is reduced. Increasing the MaxGain to increase dynamic range, also decreased the corresponding RMS output levels accordingly. If my assumptions are correct, I maybe able to attenuate the problem channel's largest swing delta so the resulting stereo filters RMS values match better.
The filters are sounding good, and the image is centered and stable. My room has a tendency to mess up the rightmost image of a right-2-left test track which DRC-FIR seems to consistently address nicely.
I read up on the band split (there are a lot of tuning knobs in DRC) and tried both ways. The sliding window is supposed to be numerically more accurate by omitting the summation errors at the band boundaries. That being said, I haven't been able to detect any significant deltas in REW between the 2 algorithms.
I figured out how to get N cycles at 10Hz and 24Hz. Printing out the # cycles is more intuitive. It seems it would be more user friendly to specify start/stop cycles, start/stop frequency and sampling rate making the configuration files samplerate independent (except for specifying the single sample rate). Can probably do that in a script and automate the relationship between the different window values.
I also figured out why it wasn't following the target curve as I expected. The Psychoacoustic pass overrides the target curve.
Also figured out the target curve is at the FDW and not the actual room's response the mic sees (after disabling the Psychoacoustic filter). Updated the scripts to build both with and without the Psychoacoustic pass for listening tests.
I tarred up the Windows directory tree and moved it over to Linux where I have better tools. Converted the .bat to .sh scripts and made both channels compute in parallel and automatically deposit the filters in CamillaDSP's filters directory. Can also generate multiple filter type sets in parallel keeping the aggregate linear generation time to 1x (vs Nx) until I run out of CPU threads. This greatly streamlines the workflow. Export IR's from REW's measurements, double click on a desktop icon and newly installed filter sets are ready in just over a minute with no more hand copying.
Also investigating why the left and right RMS values get changed and playing with dynamic range compression. It looks like the largest swing in the frequency range determines how much a channel's RMS value is reduced. Increasing the MaxGain to increase dynamic range, also decreased the corresponding RMS output levels accordingly. If my assumptions are correct, I maybe able to attenuate the problem channel's largest swing delta so the resulting stereo filters RMS values match better.
The filters are sounding good, and the image is centered and stable. My room has a tendency to mess up the rightmost image of a right-2-left test track which DRC-FIR seems to consistently address nicely.
I spotted the biggest differences in the pré-fetched window DRC is using for processing. Sliding was a bit smoother overall. Not a bad thing as it would prevent over-correction.Thanks Gents.
I read up on the band split (there are a lot of tuning knobs in DRC) and tried both ways. The sliding window is supposed to be numerically more accurate by omitting the summation errors at the band boundaries. That being said, I haven't been able to detect any significant deltas in REW between the 2 algorithms.
Once you learn the number DRC uses actually is referring to the number of samples it isn't a huge problem.I figured out how to get N cycles at 10Hz and 24Hz. Printing out the # cycles is more intuitive. It seems it would be more user friendly to specify start/stop cycles, start/stop frequency and sampling rate making the configuration files samplerate independent (except for specifying the single sample rate). Can probably do that in a script and automate the relationship between the different window values.
If one finds a window that works you won't change it all that much anyway.
Psycho-acoustic stage is turned off in my template on purpose. As is Ringing truncation. (better to avoid it anyway)I also figured out why it wasn't following the target curve as I expected. The Psychoacoustic pass overrides the target curve.
Also figured out the target curve is at the FDW and not the actual room's response the mic sees (after disabling the Psychoacoustic filter). Updated the scripts to build both with and without the Psychoacoustic pass for listening tests.
Just a note: If your speaker has a good enough dispersion pattern, the balance of the FWD won't differ all that much from the longer unfiltered room response...
One way to part the two (correction and target for tonal balance) is make a correction with DRC, next adjust the balance within REW with a longer window (like ~20 cycle). It should work quite well, I use it myself like this.
The DSP correction is based on a window that largely avoids the room where it is important (pretty essential really), the balance lets in a bit more of the room (and is done with a lot more broad strokes instead of fine tweaks). If the differences between the two is large (probably won't be that large in a good room with a decent performing speaker) than you'd need more room treatment targeted at the room's (or speaker dispersion) problem areas. The second stage should only need some balancing and (re)shaping if the room's reaction to the speaker is reasonable.
If the second stage needs a lot of work, something is off. It would probably be pretty hard to get or find a good balance that works with a lot of differing music genre's.
That's the most important part, right? 🙂The filters are sounding good, and the image is centered and stable. My room has a tendency to mess up the rightmost image of a right-2-left test track which DRC-FIR seems to consistently address nicely.
What is the best way (tool) to "pre-combine" 2 or more FIR filters (example: XO FIR and driver correction FIR) that maintains bit-depth, resolution and taps ?
I see REW has Trace Arithmetic functions, but it appears to be 16-bit.
Thanks much.
I see REW has Trace Arithmetic functions, but it appears to be 16-bit.
Thanks much.
REW Getting set up for measuringOn Windows platforms REW can use either the Java audio drivers or ASIO drivers, on other platforms only Java drivers are supported. The Windows Java drivers support sample rates up to 192 kHz but only 16-bit data (based on the Java 8 runtime at the time of writing, Dec 2020). Use ASIO on Windows for the full sample resolution the interface supports. On macOS and Linux 32-bit or 24-bit data is used if the interface offers it.
Is there a way to use DRC-FIR to correct an individual driver and then combine the driver's correction FIR filter with an XO FIR filter ?
Example: Do a partial range sweep on a sub [10-100]Hz, create a DRC-FIR correction filter and then combine that filter with a RePhase 50Hz linear phase low pass filter such that the resulting aggregate filter does both individual driver correction and XO ?
What tool would be used to combine the 2 FIRs into one (REW's trace arithmetic functions) ?
Thanks much.
Example: Do a partial range sweep on a sub [10-100]Hz, create a DRC-FIR correction filter and then combine that filter with a RePhase 50Hz linear phase low pass filter such that the resulting aggregate filter does both individual driver correction and XO ?
What tool would be used to combine the 2 FIRs into one (REW's trace arithmetic functions) ?
Thanks much.
Trace arithmetic works, DRC itself could probably be tricked into doing it as a test convolution with the two files inserted as dummies.
A example of a numpy convolution reverb script here a few posts down that looks like it would work too.
https://dsp.stackexchange.com/quest...-room-impulse-response-with-a-wav-file-python
A example of a numpy convolution reverb script here a few posts down that looks like it would work too.
https://dsp.stackexchange.com/quest...-room-impulse-response-with-a-wav-file-python
- Home
- Loudspeakers
- Full Range
- A convolution based alternative to electrical loudspeaker correction networks