Hi, thanks guys, awesome and generous replies.
Wesayso, the REW 5 cycle FDW sure looks smoother than the DRC 5 cycle.
Wonder how many cycles of REW it would take where there would be equivalency?
That's just a curiosity...not really asking you to waste time on it...because it seems like some trial and error with either, to find what works best.
I totally agree that timing is about first waves, the initial rise of all waves, hitting out ears at exactly the same time.
I guess it's why we often tune (time) to a spot, and then see (hope) how it holds up off-axis, huh?
Oh, and yes, i took "you" to be universal and not targeted at all 🙂
Fluid, agreed...i'm also thinking that context difference is the root difference.
Context of speaker in room, vs out.
Or said otherwise, room and speaker impulse, vs speaker impulse.
Especially a difference given the fact a line's impulse changes so dramatically indoors vs out..
Yep, maybe DRC is a better option for integrated room and speaker impulse...no clue really, haven't given it much consideration.
Other than thinking once a room is involved, it seems like the FIR file needs to span the entire frequency range, and for multi-ways it might best work as a global correction on the input, independent and in addition to the quasi anechoic multiway speaker processing. Just thinkin.... ???
Now THAT might get me interested in DRC 🙂
(or even DIRAC maybe)
Wesayso, the REW 5 cycle FDW sure looks smoother than the DRC 5 cycle.
Wonder how many cycles of REW it would take where there would be equivalency?
That's just a curiosity...not really asking you to waste time on it...because it seems like some trial and error with either, to find what works best.
I totally agree that timing is about first waves, the initial rise of all waves, hitting out ears at exactly the same time.
I guess it's why we often tune (time) to a spot, and then see (hope) how it holds up off-axis, huh?
Oh, and yes, i took "you" to be universal and not targeted at all 🙂
Fluid, agreed...i'm also thinking that context difference is the root difference.
Context of speaker in room, vs out.
Or said otherwise, room and speaker impulse, vs speaker impulse.
Especially a difference given the fact a line's impulse changes so dramatically indoors vs out..
Yep, maybe DRC is a better option for integrated room and speaker impulse...no clue really, haven't given it much consideration.
Other than thinking once a room is involved, it seems like the FIR file needs to span the entire frequency range, and for multi-ways it might best work as a global correction on the input, independent and in addition to the quasi anechoic multiway speaker processing. Just thinkin.... ???
Now THAT might get me interested in DRC 🙂
(or even DIRAC maybe)
They will not be equivalent because DRC can change the effective resolution of the window based on what you choose. REW is fixed at cycles or 1/n octave bandwidth choices so is less flexible.
That is exactly how I would use it on a traditional multiway. A really good speaker that is well designed should not need any fixing above 1K except for maybe a little bit of gentle EQ tilting to taste if that wasn't done in the crossover. Below that the room starts to become a factor and using DRC or something like it can be really beneficial to get the entire system tuned in situ.
Mark you seem to have cash for this sort of stuff so I would seriously look at Acourate, I have never used any of the commercial codes but I think that one would suit you if you could get your tap count up at least on the stereo input. I would take DRC-FIR over Dirac any day of the week. Acourate still tempts me Uli Bruggeman is a smart cookie.
Thx. I've looked and scoured the web a number of times regarding Acourate and Audiolense (and read the DRC manual several times).
Honestly, all the complex variables those programs offer don't seem to add value to me. They seem to reflect the lack of a well thought out, well integrated program, that directly handles what to do with variables they make the user suffer thru.... imho.
That said, and in the hope for more, one of the main issues I've seen with Acourate (which may be just 'websay' wrong) is that Acourate exports are either wav or some proprietary format.
Proprietary is a total nonstarter for me.... and I know from experience that wav is second class iffy.
Do you know if Acourate is limited to these two export formats?
I can't find docs beyond these...Documents and Tutorials - AudioVero
Related swerve......I've kinda come to trust proaudio products waaaay beyond home audio products.
The proaudio stuff is constantly under professional comparative evaluation ...for sure waaay more than home audio. And is used by big dog companies that can use whatever...
Admittedly, that's half the reason I'm drawn to FirD, Smaart, Qsys, etc....
Oh, and i hear you re Dirac...it's why i've never sprung for it, even in rather affordable implementations..
I won't say too much because I don't think you want what I want and there is nothing wrong with that.
The only other format I have seen mentioned is .dbl when using 64 bit coefficients but that would not be any use to you anyway.
To me it is an awesome toolbox from which I could choose the best options for the result I am looking for. Given your thoughts and opinion above I couldn't recommend you Acourate and DRC-FIR.
WAV is the standard that all convolvers can work with, I have no idea what experience lead you to your opinion but it is in no way a universal problem. There are different encoding options which all give a .wav file which could create issues if the hardware can only use one.
The only other format I have seen mentioned is .dbl when using 64 bit coefficients but that would not be any use to you anyway.
Thanks for your patience.
I don't mean to sound schizophrenic about the FIR programs. I just get all enthusiastic, excited to maybe take things up a notch, but when i look under their hood, i get dismayed again. Oh well, different tools for different tasks, different folks, i guess.
My understanding about wav files, is that care must be taken that a coefficient generated never exceed 1 +/- . It's why there are often proprietary formats, or components in DRC to avoid clipping, i think.
CSV appears to be the standard format in the prosound world without such potential issue.
Here's an interview with the guy who wrote FirD. About 2/3way down he talks about the wav issue.
The article also does a good job depicting the attitude i'm come to believe in regarding how much correction to use. fwiw 🙂
MYTH: FIR filters always add a lot of delay and are impractical for live sound
I don't mean to sound schizophrenic about the FIR programs. I just get all enthusiastic, excited to maybe take things up a notch, but when i look under their hood, i get dismayed again. Oh well, different tools for different tasks, different folks, i guess.
My understanding about wav files, is that care must be taken that a coefficient generated never exceed 1 +/- . It's why there are often proprietary formats, or components in DRC to avoid clipping, i think.
CSV appears to be the standard format in the prosound world without such potential issue.
Here's an interview with the guy who wrote FirD. About 2/3way down he talks about the wav issue.
The article also does a good job depicting the attitude i'm come to believe in regarding how much correction to use. fwiw 🙂
MYTH: FIR filters always add a lot of delay and are impractical for live sound
Dip and peak limiting is to avoid over-correction, not clipping. Just saying.
DRC functions in 32 bit floating point, Acourate uses 64 bit floating point.
One could make it an issue, but it isn't.
DRC functions in 32 bit floating point, Acourate uses 64 bit floating point.
One could make it an issue, but it isn't.
Hi wesayso, i think the issue with clipping and wavs is discussed in DRC 4.6.2.
That kind of stuff is over my head though..
I like that FirD has a real time engine that alerts whenever coefficients go out of bounds for wav. And my understanding is that CSV solves even that...
And yep, 32 bit vs 64? Who cares 🙂
The warning in DRC was for the output of a normalized FIR output file for a convolution engine with limitations. E.g. Brutefir convolution engine.
One can set a variable (Again? 😀) how to handle the output normalization. That choice would depend on your hardware.
(I guess this is Dennis's way to make sure you can use any program you like and still get the filter format right,
as he can't know what you are going to use the filters in)
Even with other formats than floating point, like the one you mentioned, after convolution you still need to make sure (take care)
you are not clipping the DAC etc. As the convolution process is: input [times] filter = output
Within the 32 bit floating point there is headroom. Probably even more within 64 bit FP (Acourate's default).
One has to make sure that the convolution step can be done without clipping anything. JRiver has a 64 bit DSP engine to ensure that.
Yet the user is responsible for gain settings to prevent clipping the output, like a DAC. (it has clip detection in its analyzer)
But this has nothing to do with either DRC-FIR, Acourate or Audiolense.
Nor is wav crippled if you do use the right formats for the job.
Hope that clears it up.
One can set a variable (Again? 😀) how to handle the output normalization. That choice would depend on your hardware.
(I guess this is Dennis's way to make sure you can use any program you like and still get the filter format right,
as he can't know what you are going to use the filters in)
Even with other formats than floating point, like the one you mentioned, after convolution you still need to make sure (take care)
you are not clipping the DAC etc. As the convolution process is: input [times] filter = output
Within the 32 bit floating point there is headroom. Probably even more within 64 bit FP (Acourate's default).
One has to make sure that the convolution step can be done without clipping anything. JRiver has a 64 bit DSP engine to ensure that.
Yet the user is responsible for gain settings to prevent clipping the output, like a DAC. (it has clip detection in its analyzer)
But this has nothing to do with either DRC-FIR, Acourate or Audiolense.
Nor is wav crippled if you do use the right formats for the job.
Hope that clears it up.
Last edited:
Thx. All that I pretty much get. It was the normalization options in DRC that was new to me.
I took the point toof that section of the manual to be, understand what your convolver needs, and make settings accordingly. And then all will be quite well with wav. But do make sure.
Emphasis on bit size seems funny to me as 24 bit already has 144dB dynamic range.
But i can see the easy jump to 32 float to go to over 190dB just for fixing low recording levels later.
64 bit with over 350dB seems total overkill.
At any rate, I'm happy with 24bit, CSV FIR files, and speakers with 100dB dynamic range (starting from 30dB as zero) 😀
Which kinda circles back on topic to the thread....contrast in dynamic range of the most limited component in the chain...our speakers.
I took the point toof that section of the manual to be, understand what your convolver needs, and make settings accordingly. And then all will be quite well with wav. But do make sure.
Emphasis on bit size seems funny to me as 24 bit already has 144dB dynamic range.
But i can see the easy jump to 32 float to go to over 190dB just for fixing low recording levels later.
64 bit with over 350dB seems total overkill.
At any rate, I'm happy with 24bit, CSV FIR files, and speakers with 100dB dynamic range (starting from 30dB as zero) 😀
Which kinda circles back on topic to the thread....contrast in dynamic range of the most limited component in the chain...our speakers.
This can be true but doesn't have to be as wesayso said. wav files are not all the same. We are leaving the road and heading off into the weeds here but...
Fixed point DSP can only handle fixed point numbers which is where the +1 limitation comes in, any more and it clips and who knows what you will get, that part is true.
Floating point DSP does not have this limitation (at that point) and 32bit FP can be stored in wav files, REW and rephase can both export to that format.
32-Bit Float Files Explained - Sound Devices
32-bit float
Compared to fixed-point files (16- or 24-bit), 32-bit float files store numbers in a floating-point format. This is fundamentally different than fixed point, because numbers in these WAV files are stored with “scientific notation”, using decimal points and exponents (for example “1.4563 x 106“ instead of “1456300”). This difference is significant because much larger and smaller numbers can be represented compared to a fixed-point representation. The formatting and encoding of the 32-bit word is not intuitive–it has been optimized for computers to be able to perform common math functions on it rather than for human-readability. The first bit indicates a positive or negative value, the next 8 bits indicate the exponent, and the last 23 bits indicate the mantissa. More info is available regarding this format (called IEEE-754).
DRC naturally outputs 32bit float as raw pcm data, so there is no header, this is the format that MiniDSP use except they insist on it having a .bin extension but it is still raw pcm. You helped me work this out before 😉
The half information and half marketing you get from those sort of interviews often leads to misunderstanding, whether intentional or not. Be wary of taking it at face value.
24 bit has the right number but 32 bit float already has a 1528dB dynamic range so you are right that more is not needed. See the previous link for the explanation.