A convolution based alternative to electrical loudspeaker correction networks

[fluid]

Ok I am just making sure that I got this right.
I can either change the base .drc file and then just keep the one batch script that runs it, or I can change the batch script and whatever with the "--" before it will override the .drc file correct?

Yes

As I am using the first approach (changing the .drc and keeping one base batch script)

This is equivalent and an acceptable work flow is it not?

You can do it that way there is nothing wrong with it. When you want to create 4 or 5 versions of the same filter with slight changes to 4 or 5 parameters it is easier to do it with an altered batch script.

Also, I have heard lots of people say that getting minimum phase in the bass and longer filter lengths especially help in the bass.
I am mostly looking to get nice tight punchy bass with DRC (and yes some general room correction as well)

For me minimum phase is the right target to aim for but I don't think you can easily ascribe punchy to any particular parameters, you really need to experiment and see what you prefer.

Anyways, changing the EPLowerWindow and ISPELowerWindow and EPFinalWindow would be how much low end phase correction it is correcting correct?

In the screenshot above you can see the parameters I changed, these are the main ones that affect phase correction.

And then changing the MPWindowExponent and RTWindowExponent is how much it focuses it computation / correction on the low vs high end. So if I primarily want to correct the phase in the bass then I would change the values to less than 1 (1 being linear, 0.2 being heavily weighted toward the low end). Would that be the right way of starting things off?

MP applies to minimum phase and RT to ringing truncation. Unless you switched on Ringing Truncation the related parameters will not do anything. The EP window exponent will have the biggest effect here. Going with a lower window exponent reduces both the time as well as the frequency extents so going low will really just begin to turn it off rather than concentrate it. You can set an upper frequency limit for the excess phase correction so that it is concentrated in the lower frequencies and doesn't apply across the whole frequency range.

 

[emailtim]

I would appreciate it if someone would be so gracious to answer the following questions. Both plots are made from the same applied filter.

How does one reconcile the output of DRC/DRCDesigner with REW with respect to Phase, Minimum Phase and Excess Phase ?

The following plot is the result of a STRONG full-range DRCDesigner filter applied to OB/Dipole stereo subs and 3-way line arrays. The XO's are linear phase made in RePhase and the full range DRC is done in DRC. Should the result be minimum phase or something else ? Should the minimum phase plot match the actual phase plot ?

The second question is about interpreting the step response. I see many step responses with a graceful arc at the bottom after the initial peak. This one has more of an angle @ 5.ms versus an arc. What does this sharper angle indicate ? Both channel plots track each other.

Thanks much !!!

 

[fluid]

How does one reconcile the output of DRC/DRCDesigner with REW with respect to Phase, Minimum Phase and Excess Phase ?

The following plot is the result of a STRONG full-range DRCDesigner filter applied to OB/Dipole stereo subs and 3-way line arrays. The XO's are linear phase made in RePhase and the full range DRC is done in DRC. Should the result be minimum phase or something else ? Should the minimum phase plot match the actual phase plot ?

The minimum phase response from REW represents the minimum phase version of the frequency response in the measurement. The REW excess phase response is the difference between the measured phase response and minimum phase response.

DRC can output minimum phase filters, linear phase or mixed phase filters depending on the settings used. DRC Designer may not give you access to these options.

If you asked for a minimum phase filter it should match the minimum phase response, if you asked for something else then there will be excess phase.

Sometimes there can be some overall delay in the measurement which will affect the HF phase response, you can realign the impulse if there is by offsetting the T=0 time and see the effect.

The step response does look as if it has some linear phase response before the peak and doesn't follow the minimum phase response entirely why is why there is that kink in the step.

 

[emailtim]

The minimum phase response from REW represents the minimum phase version of the frequency response in the measurement. The REW excess phase response is the difference between the measured phase response and minimum phase response.

DRC can output minimum phase filters, linear phase or mixed phase filters depending on the settings used. DRC Designer may not give you access to these options.

If you asked for a minimum phase filter it should match the minimum phase response, if you asked for something else then there will be excess phase.

Sometimes there can be some overall delay in the measurement which will affect the HF phase response, you can realign the impulse if there is by offsetting the T=0 time and see the effect.

The step response does look as if it has some linear phase response before the peak and doesn't follow the minimum phase response entirely why is why there is that kink in the step.

Fluid,

Thanks much. DRCDesigner just launches the "strong96000.drc" script with it's own target points file. The "strong96000.drc" indicates it is using minimum phase in the top comments, but I do not know the variables well enough to verify the comment section is accurate.

I will have to read up on the argument list.

Thanks much for the quick reply.

 

[fluid]

I will have to read up on the argument list.

MSOutFile is the option to extract a minimum phase filter version regardless of whatever other settings have been used before.

PSOutFile is the option to make a filter that is linear, mixed or minimum phase, the type of filter it will be is determined by PSFilterType being set to L,T or M respectively.

If you look those up in the DRC documentation there are other parameters that effect what result you will get too.

For someone with your computing ability I would recommend using gmad's scripts they really are the best way to change all the settings and try out the options.

 

[emailtim]

MSOutFile is the option to extract a minimum phase filter version regardless of whatever other settings have been used before.

PSOutFile is the option to make a filter that is linear, mixed or minimum phase, the type of filter it will be is determined by PSFilterType being set to L,T or M respectively.

If you look those up in the DRC documentation there are other parameters that effect what result you will get too.

For someone with your computing ability I would recommend using gmad's scripts they really are the best way to change all the settings and try out the options.

Fluid,

Thanks much, I will check those parameters out. It looks like PSFilterType is set to 'T' (mixed phase) which coincides with your reading of the Step Plot previously posted.

The Gmad's scripts that I saw just ran drc.exe via the CLI and then used SoX to create the stereo wav file from the raw mono pcm files. They used a basic .drc file and passed in override values via the command line. They did what DRCDesigner does when using the CUSTOM settings. Are those the scripts that you are referring to or something else ?

I have already wrote a bunch of scripts to automate the conversion of my 176.4kHz IR.wav files to 96kHz raw PCM files with some gain reduction to prevent clipping as a pre-processing stage and then post-processing scripts to convert the 96kHz filters back into 176.4kHz and 192kHz filters for playback in CamillaDSP's convolution engine. I just discovered Drc.exe supposedly supports both 32 and 64-bit floats. I am in the process of trying to get 64-bit floats working end-2-end for CamillaDSP.

I have also swiped the scripts coming out of DRCDesigner and modified then accordingly for various tasks such as extracting the intermediate files for the OCTAVE plot generation. The DRCDesigner scripts are mono.

The first set of filters caused 2 over-correction distortions on 1 channel and 3 in the other between [100-200]Hz. I redid my crossovers around that region and was able to reduce the over-corrections from 5 to 2 and minimized the severity of the remaining 2 but did not eliminate them entirely. Still have those 2 to fix. Drc.exe is trying to correct 2 deep narrow nulls that the bass driver doesn't like.

It is time for me to learn what the actual parameters do to make best use of them to get rid of the 2 over-corrections and future fine tuning. I also read it can be recompiled and run in Linux. My bash scripting is better than my DOS scripting (I cheat, I run cygwin).

It looks like Drc.exe is going to be a good match for CamillaDSP's multi-pass convolution functionality.

 

[fluid]

Are those the scripts that you are referring to or something else ?

Yes, they do more than that, they are pretty much the subject of this thread although it includes DRC in general too.
When you want to run a series of tests to work out the effects of different parameters it is helpful to copy the script and change a few things, that way there is a filter and settings stored for future reference.

The scripts create a test convolution and pass sox arguments to create wav files and move all the filters and tests to specific folders all in one go. I find this to be quite helpful. I have literally hundreds of filters that are saved and there would have been hundreds more that I didn't bother to keep.

Being able to quickly check the test convolution is very handy to see if the changes had the desired effect or not. There were many that didn't get listened to due to errors or the parameter doing something other than what I thought it would.

Certainly there are other ways to achieve the same thing but I can't imagine an easier way.

I have already wrote a bunch of scripts to automate the conversion of my 176.4kHz IR.wav files to 96kHz raw PCM files with some gain reduction to prevent clipping as a pre-processing stage and then post-processing scripts to convert the 96kHz filters back into 176.4kHz and 192kHz filters for playback in CamillaDSP's convolution engine.

DRC outputs raw pcm by default and it does not need to be converted to anything else if that format is supported in the convolver. Most do not and need wav files which is why the conversion process is used.

The DRCDesigner scripts are mono.

DRC only works in mono on one channel at at time, a stereo script just runs the two channels separately and then combines them into a stereo file at the end.

Drc.exe is trying to correct 2 deep narrow nulls that the bass driver doesn't like.

Look at the Dip Limiting settings DL and the peak limiting settings PL. If there is a lot of correction it can work better to apply a basic PEQ precorrection to get the response within a smaller window to make DRC's job easier and allow for lower gain settings.

 

[wesayso]

Some random thoughts:

If you look at gmad's scripts you'll notice that the window used is way smaller than the one in DRCDesigner's strong template.
Where do you measure? At the listening position of your speakers? A strong correction can make the graphs pretty, but is no guarantee it will sound any good or even natural. The shortest correction that does what it needs to do would be my preference. That could mean looking at your pré convolution result and try to identify what's wrong and can be fixed with some help of the room. Looking at early reflections and minimizing those before turning to DSP.
Two things determine the sound of the filters more than any other variable:

• the length of the correction window
• the target for the end result

Keep the first, the window, as short as possible while still being able to correct that first wave front.
Play with the target to determine a room curve that suits your taste. Play various music and songs and try to find a pleasing balance.
This can be time consuming and might take a while to work out. But I would say it is also very rewarding in the end.

It helps immensely to play at a set SPL level. meaning that all songs played should play at about an equal average volume. As the volume plays a very large part in our perception of balance. One may have found the perfect correction for loud songs and miss bass when playing something that is softer on playback (an probably more dynamic range). Personally I use JRiver's volume leveling to take care of that. It uses the R128 algorithm to achieve that average.
Maybe you already know all this stuff, but I hope it can't hurt to mention it, if only for the benefit of new viewers of this thread.

The need for an average SPL level due to the mixed levels in the content out there lies in the changing balance of our ears at different playback volume.

While a lot of people think, after seeing these graphs: hey I just alter my balance according to one of these graphs. But the one at the mixing table already took that concern to heart. The bigger mystery is at what average volume level the music was mixed and mastered.
That's why an average playback volume might help to find your balance. And it doesn't matter if you play 85 dB average or 75 dB. If you play back at that average level and grow towards a pleasing balance (in your room) it has a fair chance to sound great on a lot of material.

Personally, i play pretty loud on average(*) when I'm alone. About 85 to 87 dB on average. I find it a sweetspot for imaging and stage in the music and most probably it's actually pretty close to the average mixing levels used in studio's.
I have no need or want to play any louder, for instance to "rock out", as if the system is clean enough, it won't bring any real big change. I'd only run the chance to distort or really hurt my ears if i did. The more clean the system is, the less you really notice how loud the playback level is. For that I keep an SPL meter nearby.

(*) Average level of 85 to 87 dB in room means peaks that can be up to 20 dB louder. While it may not seem that loud to many, it is a sane level to keep one form getting (permanent) hearing damage. It is not a level that works if there's more people around, willing to have a civil conversation . The reason I like to play at this level is that it is much like bringing the recorded performance closer, putting me up front. Turning it down a little seems to increase the distance between me and the recording. With the right ambience it is the "I'm there" feeling that gets me every time.
As long as I'm not bothering anyone at that level and keep my ears safe during longer sessions, I like it.
I've had a lot of fun listening louder, before I really knew what level I was listening at. Getting an SPL meter was a good decision in my opinion.

 

[emailtim]

If you look at gmad's scripts you'll notice that the window used is way smaller than the one in DRCDesigner's strong template.

Thanks. I have done a bit of room treatment (diffusers and absorbers) and positioning to minimize the amount of corrections required. I still have first reflection sidewall treatments to finalize.

I think I am measuring @ 78dB levels based on Mitch Barnett's latest YouTube video

(if I remember correctly, will have to verify that).

I am measuring at the listening position for the DRC filters. I measured near-field for the individual driver linear phase filters.

My 2 remaining problem over-correction dips are [left=154 and right=216]Hz causing the playback THD at those frequencies (different frequencies most likely due to the asymmetric room). Steep crossover is at 250Hz so both are happening with the bass drivers.

$ diff -bw ./drc-3.2.3/sample/strong44100.drc "./GMADs_Scripts/Room Correction/drc-3.2.2/sample/strong-44.1.drc"
165,166c165,166
< PLStartFreq = 20
< PLEndFreq = 20000
---
> PLStartFreq = 100
> PLEndFreq = 10000

 

[wesayso]

Where you have a problem is still relatively high in frequency, yet you might get away with a few additional tweaks.
Where DRC is trying to over-correct, you could add a manual EQ tweak to get rid of that correction and even a bit more.
Next, add some extra (EQ) in the other channel so the sum of both channels remains flat.
Do the same on the other channel so the extra (over-correction) energy is gone, and the distortion is reduced significantly as measured in the sum of both channels.
I think it is just low enough in frequency (if it's a high enough Q peak/dip) to get away with that while still getting a very good balance overall.
One channel covering for the other and vice versa. Below about 250 Hz it shouldn't be a big draw-back.

I did it with my system in one channel (left) at ~70 Hz and another "problem" at ~30 Hz in the right. Nowadays I have subs that help me correct it per channel.
It has never been a problem though with this simple trick, but as said, your problem area's are a bit higher. I still believe this might work well enough in practice.

Just as a bit of information, in-room curves and their preferences as presented by Toole:

My personal preference was very close to the preferred curve of "Trained listeners only". So much that it has become my
standard go-to curve for a quick first target and I adjust a few little things from there on.

 

[wesayso]

In one of his reviews Mitch brought up the subject of room curves and went a bit more in-depth on that subject. In that article he
compared his "in-room" results with mine . As we both ended up with curves quite close to one another while being on the other end
of the globe and with completely different systems. I'll look for it... Mine was the one with the slightly higher level bass.
Here it is: Review Dynaudio Focus 600 XD

 

[fluid]

My 2 remaining problem over-correction dips are [left=154 and right=216]Hz causing the playback THD at those frequencies (different frequencies most likely due to the asymmetric room). Steep crossover is at 250Hz so both are happening with the bass drivers.

Can you post a shot of the measurement and the filter created along with the settings that caused it? DRC should not be trying to correct something to the point of causing clipping.

 

[emailtim]

Can you post a shot of the measurement and the filter created along with the settings that caused it? DRC should not be trying to correct something to the point of causing clipping.

I don't know if it is "clipping", but it is doing something the bass panel doesn't like. You can hear it in the 4M sweeps.

I am still in the stage of wrapping my head around the drc.exe toolset. I measure @ 176.4kHz because I can not get the mic-preamp to slave clock sync lock to the DAC at 192kHz, so I measure and create my filters @ 176.4kHz and then convert them to 192kHz for normal playback. I updated the rate-changer driver (Alsa_cdsp) code so I can quickly change between sample-rate and house-curve filter sets to swtich between recording and playback rates.

It looks like Drc.exe scripts are only setup for up to 96kHz, so my scripts resample back and forth between 176.4 and 96. With enough time, I will probably try to mod the Drc.exe 88.2kHz scripts into 176.4 so I will no longer need the intermediate pre-processing scripts, just the post-processing to derive 192kHz filters. After looking at the existing deltas between the *.drc rate files, most of the parameters are just doubled with frequency doubling (44.1 to 88.2 and 48 to 96).

That being said, I need to consider how Drc.exe will handle the extra frequency extension beyond 20Hz to 30kHz (and below 20Hz). The ribbons are supposed to produce up to 45kHz, not that I can actually hear anywhere near that (or my mic calibration file is up to the task, but the math should be able to function accordingly).

Here are the left=153Hz and right=215 THD distortion peaks caused by the applied STRONG filter. There was 5 and they were higher before I re-positioned the speakers and adjusted the XOs.

Here is the left original (green), corrected (purple) and filter (red default values in strong96000.drc). The target is a flat line and MaxGain wasn't changed from default (2.0 or 6dB).

I intentionally left the gains higher on the sub and bass where most of the "cuts" corrections would be needed assuming less correction as frequency increases. I wanted the algorithm to favor cuts over gains.

The curious thing is it is causing a THD spike at 153Hz and not the other deep narrow nulls. The right=215Hz deep narrow dip looks similar to the left.

The linear phase RePhase XO's are at the bottom (blue, purple, teal, gold).

I am already using some "tricks" to address room modes by overlapping the sub and bass panel centered @ 50Hz. RePhase has a linear phase XO with a 1 octave overlap that I am experimenting with. I am trying to emulate a 4-sub swarm between the bass and subs by averaging 4 room node locations across the "psuedo-swarm". It seems to do a good job so far considering I also get dipole cancellations from the front wall reflections.

The sub XO has OB/dipole rolloff compensation built in.
The NEO8 line array XO has a peak/dip correction built in.
The Ribbon line array XO has a "minimum-phase-1st-XO-erasure" filter built it to remove the phase change introduced by the Ribbon's protection capacitor. None of the other drivers have caps inline so this filter restores the ribbon's phase for easier integration.

 

[emailtim]

Where you have a problem is still relatively high in frequency, yet you might get away with a few additional tweaks.
Where DRC is trying to over-correct, you could add a manual EQ tweak to get rid of that correction and even a bit more.
Next, add some extra (EQ) in the other channel so the sum of both channels remains flat.
Do the same on the other channel so the extra (over-correction) energy is gone, and the distortion is reduced significantly as measured in the sum of both channels.
I think it is just low enough in frequency (if it's a high enough Q peak/dip) to get away with that while still getting a very good balance overall.
One channel covering for the other and vice versa. Below about 250 Hz it shouldn't be a big draw-back.

I did it with my system in one channel (left) at ~70 Hz and another "problem" at ~30 Hz in the right. Nowadays I have subs that help me correct it per channel.
It has never been a problem though with this simple trick, but as said, your problem area's are a bit higher. I still believe this might work well enough in practice.

Just as a bit of information, in-room curves and their preferences as presented by Toole:
View attachment 1005138
My personal preference was very close to the preferred curve of "Trained listeners only". So much that it has become my
standard go-to curve for a quick first target and I adjust a few little things from there on.

Right now I am focusing on flat curves until I get a grasp on the tool set.

Funny you should mention the tweaks. I read some of the Acourate threads and one of the tricks was to artificially add group delays to the opposing channels to compensate for the group delays that can't be cured in the opposite opposing channels to regain stereo symmetry. Adding warts versus removing warts to fix asymmetric room issues, not something I would have immediately considered.

The new version of Acourate sounds like it has some nice new features. Uli added functionality to solve 2 channels in lockstep to address asymmetric room concerns.

 

[emailtim]

Interesting. I just created a 176.4kHz strong.drc file from the 88.2kHz file and gave it a go.

The resulting filter does 1-2dB less correction on the 3 strongest peaks so there maybe some resolution issues going on using SoX to resample from 176.4kHz down to 96kHz and back again.

While doing this from scripts I see that the software could be upgraded to create multiple channels in parallel if the intermediate files have unique names (i.e. add a unique prefix or suffix the the intermediate names).

 

[fluid]

That is not a correction I would want, too much dip filling and your results demonstrate why it is not a good idea, 50 to 80% distortion.

I would measure and make filters at one specific sample rate and then resample the filters to the other rates later. The less resampling there is the better.

Cut vs boost is pretty irrelevant in a floating point DSP process as it is only the gain at the end that matters. As the correction is an inversion cut and boost doesn't seem the right way to look at it to me.

 

[emailtim]

That is not a correction I would want, too much dip filling and your results demonstrate why it is not a good idea, 50 to 80% distortion.

I would measure and make filters at one specific sample rate and then resample the filters to the other rates later. The less resampling there is the better.

Cut vs boost is pretty irrelevant in a floating point DSP process as it is only the gain at the end that matters. As the correction is an inversion cut and boost doesn't seem the right way to look at it to me.

Thanks much.

I made a strong176400.drc version from the strong88200.drc file, switched from f32 to f64, overrode all of the OutFileTypes to "D", recreated the same filter without the SoX downsampling and the 2 remaining THD spikes went away. Going full CLI script now and bypassing DRCDesigner.

I am investigating the test convolution scripts now. I was using REW's "trace arithmetic" to test-apply the filters which I am guessing the test convolution does the same thing.

I will try updating the code so all 4 serial drc.exe jobs can run in parallel.

cd C:\DRCDesigner\drc-3.2.3\sample

Set RATE=176400
Set EXTRA_RATE=192000
Set SOX="C:\DRCDesigner\sox-14.3.2\sox.exe"
Set MIC_CAL="C:\DRCDesigner\drc-3.2.3\source\mic\ECM8000_DRCDesigner_HAND_TWEAKED.cal"
Set POINTS_FILE="C:\DRCDesigner\drc-3.2.3\sample\DRCDesignerCustomizedPoints.txt"
Set DRC_FILE=strong%RATE%.drc
REM F 32 or D 64
Set F_TYPE=D
Set F_BITS=64
Set EXT=_STRONG_%F_TYPE%
Set F_FLAGS=--BCInFileType=%F_TYPE% --MCOutFileType=%F_TYPE% --HDMPOutFileType=%F_TYPE% --HDEPOutFileType=%F_TYPE% --MPPFOutFileType=%F_TYPE% --MPPFOutFileType=%F_TYPE% --EPPFOutFileType=%F_TYPE% --PCOutFileType=%F_TYPE% --ISOutFileType=%F_TYPE% --PTFilterFileType=%F_TYPE% --PTOutFileType=%F_TYPE% --PLOutFileType=%F_TYPE% --RTOutFileType=%F_TYPE% --PSOutFileType=%F_TYPE% --TCOutFileType=%F_TYPE%
Set STD_ARGS=--MCFilterType=M --MCPointsFile=%MIC_CAL% --PSPointsFile=%POINTS_FILE% --BCImpulseCenterMode=M --BCImpulseCenter=%RATE% %F_FLAGS% %DRC_FILE%


REM Reduce gain to avoid clipping ...
%SOX% -v 0.95  c:/tmp/L_IR.wav -t f%F_BITS% L_IR_%RATE%.pcm
%SOX% -v 0.95  c:/tmp/R_IR.wav -t f%F_BITS% R_IR_%RATE%.pcm

REM Filter Convolution
drc.exe --BCInFile=L_IR_%RATE%.pcm --PSOutFile=L_%RATE%%EXT%.pcm %STD_ARGS%
drc.exe --BCInFile=R_IR_%RATE%.pcm --PSOutFile=R_%RATE%%EXT%.pcm %STD_ARGS%

REM Test Convolution
drc.exe --BCInFile=L_IR_%RATE%.pcm --TCOutFile=L_%RATE%%EXT%_Test.pcm %STD_ARGS%
drc.exe --BCInFile=R_IR_%RATE%.pcm --TCOutFile=R_%RATE%%EXT%_Test.pcm s%STD_ARGS%

REM Create the %RATE% mono filters
%SOX% -t raw -e float -b %F_BITS% -r %RATE% -c 1 L_%RATE%%EXT%.pcm -e signed -t wavpcm c:/tmp/L_Mono_%RATE%%EXT%.wav
%SOX% -t raw -e float -b %F_BITS% -r %RATE% -c 1 R_%RATE%%EXT%.pcm -e signed -t wavpcm c:/tmp/R_Mono_%RATE%%EXT%.wav

REM Create the %RATE% mono test convolutions
%SOX% -t raw -e float -b %F_BITS% -r %RATE% -c 1 L_%RATE%%EXT%_Test.pcm -e signed -t wavpcm c:/tmp/L_Mono_%RATE%%EXT%_Test.wav
%SOX% -t raw -e float -b %F_BITS% -r %RATE% -c 1 R_%RATE%%EXT%_Test.pcm -e signed -t wavpcm c:/tmp/R_Mono_%RATE%%EXT%_Test.wav

REM Create a 192kHz (%EXTRA_RATE%) filter set, rate change required ...
%SOX% -r %RATE% c:/tmp/L_Mono_%RATE%%EXT%.wav -r %EXTRA_RATE% c:/tmp/L_Mono_%EXTRA_RATE%%EXT%.wav
%SOX% -r %RATE% c:/tmp/R_Mono_%RATE%%EXT%.wav -r %EXTRA_RATE% c:/tmp/R_Mono_%EXTRA_RATE%%EXT%.wav

%SOX% -r %RATE% c:/tmp/L_Mono_%RATE%%EXT%_Test.wav -r %EXTRA_RATE% c:/tmp/L_Mono_%EXTRA_RATE%%EXT%_Test.wav
%SOX% -r %RATE% c:/tmp/R_Mono_%RATE%%EXT%_Test.wav -r %EXTRA_RATE% c:/tmp/R_Mono_%EXTRA_RATE%%EXT%_Test.wav

 

[wesayso]

From the Strong DRC template I get: (544 ms at 20 Hz, 108 ms at 100 Hz, 10.8 ms at 1 kHz, 0.54 ms at 20 kHz)
Let's see, 20 Hz takes 50 ms, so 544 ms is more than 10 (almost 11) cycles at 20 Hz. With a window of this length you're pretty sure to bring in a lot of the "room" into your correction. Even though the RC in DRC stands for Room Correction, you'd be better off using it as sort of a speaker correction at mid and higher frequencies.
The plus side is you're correcting line arrays, but it would still react with the room, making the correction very (measurement) point specific.

What is your goal here? Is it to have the best looking graph or the best sounding filter . No doubt the "strong" filter would present the best looking graphs. But I highly doubt it's ability to produce a nice sounding filter, as you're introducing way to much (single measurement) point specific info into your window of correction.
Even though a line array averages out a lot of reflections from perpendicular planes, it will still have placement specific reflections from more parallel surfaces. Unless you're able to avoid all of those, but then a short window correction would have a huge likeness to a longer window anyway.

I'd advise to keep the window way shorter, like below 5 cycles. That way you still correct the room where it counts (at bass frequencies, where wave lengths are long) but leave out the (measurement) point specific room info in mid and high frequencies.

Take this as friendly advise, not gospel.
In the end, you decide what's best for you.

 

[emailtim]

From the Strong DRC template I get: (544 ms at 20 Hz, 108 ms at 100 Hz, 10.8 ms at 1 kHz, 0.54 ms at 20 kHz)
Let's see, 20 Hz takes 50 ms, so 544 ms is more than 10 (almost 11) cycles at 20 Hz. With a window of this length you're pretty sure to bring in a lot of the "room" into your correction. Even though the RC in DRC stands for Room Correction, you'd be better off using it as sort of a speaker correction at mid and higher frequencies.
The plus side is you're correcting line arrays, but it would still react with the room, making the correction very (measurement) point specific.

What is your goal here?

My goal here is to initially understand the tool, it's limits and how to effectively wield it. I just took the DRCDesigner training wheels off, got rid of the THD spikes, tweaked the scripts to work at 176.4/64-bit (native measuring and CamillaDSP processing values) and am now trying to understand what the individual knobs do. In the end, I would like to have an intelligent library of clean house curves/filters to compare and choose from.

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. I know Audiolense allows 2 (and an optional 3rd) zone of windowing (below and above Schrödinger's cat =), but don't know how many cycles each of those zones should ideally be other than more at lower frequencies and much less after the specific room's transition point. With REW, I would use a FDW of 6 cycles (right or wrong) for LF correction.

No doubt the "strong" filter would present the best looking graphs. But I highly doubt it's ability to produce a nice sounding filter, as you're introducing way to much (single measurement) point specific info into your window of correction.

Good to know. The sound is a step in the right direction, but its an iterative learning cycle. What I learn from experimentation, I then try to physically incorporate back into the room to eliminate the cause and then back out the electronic correction. I doubt I can do much physically about the room's asymmetry issues other than get a symmetric room or rely on DRC.

Even though a line array averages out a lot of reflections from perpendicular planes, it will still have placement specific reflections from more parallel surfaces. Unless you're able to avoid all of those, but then a short window correction would have a huge likeness to a longer window anyway.

The bass array is 67", mid array is 72", and the tweeter array is 60" with a 96" ceiling height, so it is pretty close to a real line array. I notice from the measurements that there is an arrival time delta between the middle and top/bottom of the array reaching the mic. I also notice that drc.exe is trying to correct those latent arrival times. Most of the room has been treated except for the ceiling and I still have an issue with the sidewalls to correct. The front wall has corner bass taps, broadband absorbers with diffusion panels and RPG diffractal diffuser clones. The asymmetric back of the room brings in most of my issues.

I'd advise to keep the window way shorter, like below 5 cycles. That way you still correct the room where it counts (at bass frequencies, where wave lengths are long) but leave out the (measurement) point specific room info in mid and high frequencies.

Thanks. I think I now know how to cascade down the window sizes in drc.exe as per your opening comment. Do you have a rule-of-thumb recommendations for the other 2 window sizes in cycles ?

Also, are there any range specific "amplitude" controls other than the target curve ?

Take this as friendly advise, not gospel.
In the end, you decide what's best for you.

I appreciate the information. It certainly accelerates the learning curve and is appreciated as such.

 

[wesayso]

DRC-FIR is smartly written with a lot of freedom for the end user. The windowing can be tailored to your own needs or liking. There are a couple of worthy variables to take note of. There is a window for frequency correction and a separate window for phase correction. Further you can use a WindowExponent in both of those windows to further shape the windowing.
The function or result of using the Window Exponent is shown in the DRC documentation:

One of the many images showing possible windowing curves. I use this feature to get a long enough window at bass frequencies,
a pretty short window at mid frequencies and a bit longer again on the top end. I've played with the windowing length in DRC-Designer
extensively, and listened to overdone lengthy windows up to very short windows and everything in between. From that I got a feel for
what worked for me. For instance, I use a Window Exponent of 0.93 to shape the length of my windowing to achieve the lengths I
thought worked best for me. As short as I dared to go while still reaching my goals. I am using about ~4 cycles at mid frequencies.

In all honesty, I usually do manual tweaks after this step. Mainly to be able to match left and right results to tight specs.
I also changed the way I do phase manipulation. I use pure minimum phase correction with DRC-FIR and do some manual tweaks
to change phase (at bass frequencies) within RePhase. Lots of work, but getting a better sounding result makes it worth it to me.
Basically I do it to use the phase tweaks to get a good balance in left + right channel combined at the listening spot. I could let
DRC-FIR do it for me, up to some level but I noticed more pré ringing that way in the graphs (not obvious in listening tests though).

I've made it a true study, much like you are planning to do and worked on it on and off over about 5 years to optimize. Will I ever be done? (*)
The simulations I have been doing over the last year in Vituixcad gave me new insights to change the way I think about processing (yet again).
It really made me more aware what parts are due to the array nature and what parts are caused by room effects.
It doesn't change my approach that I mentioned above, it does change the way I'll do the manual tweaks.

(*) except for true listening tests, most of the testing of variables was done virtually, by inspecting the DRC predictions within REW or by manually
convolving the results within REW with true measurements to see what it would be like. That saves a lot of time, but the many variables one can
use still make it kind of a never ending story .