drc-fir-users Mailing List for Digital Room Correction
Brought to you by:
dsbragio
You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(2) |
Jun
(3) |
Jul
|
Aug
(2) |
Sep
(20) |
Oct
(10) |
Nov
(33) |
Dec
(10) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(82) |
Feb
(46) |
Mar
(15) |
Apr
(23) |
May
(18) |
Jun
(111) |
Jul
(38) |
Aug
(58) |
Sep
(17) |
Oct
(18) |
Nov
(16) |
Dec
(7) |
2007 |
Jan
(33) |
Feb
(33) |
Mar
(24) |
Apr
|
May
(19) |
Jun
(2) |
Jul
(43) |
Aug
(309) |
Sep
(163) |
Oct
(58) |
Nov
(146) |
Dec
(69) |
2008 |
Jan
(86) |
Feb
(14) |
Mar
(4) |
Apr
(58) |
May
(40) |
Jun
(30) |
Jul
(19) |
Aug
(132) |
Sep
(4) |
Oct
(17) |
Nov
|
Dec
(26) |
2009 |
Jan
(65) |
Feb
|
Mar
(93) |
Apr
(4) |
May
(7) |
Jun
(11) |
Jul
(10) |
Aug
(5) |
Sep
(5) |
Oct
(17) |
Nov
(32) |
Dec
(24) |
2010 |
Jan
(29) |
Feb
|
Mar
(3) |
Apr
(23) |
May
(16) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
(6) |
Nov
(11) |
Dec
(23) |
2011 |
Jan
(4) |
Feb
|
Mar
(2) |
Apr
(3) |
May
|
Jun
(3) |
Jul
(1) |
Aug
(19) |
Sep
(38) |
Oct
(40) |
Nov
(15) |
Dec
(3) |
2012 |
Jan
(2) |
Feb
(14) |
Mar
(8) |
Apr
|
May
|
Jun
(7) |
Jul
|
Aug
(26) |
Sep
(1) |
Oct
(3) |
Nov
(3) |
Dec
(7) |
2013 |
Jan
(1) |
Feb
(3) |
Mar
|
Apr
(4) |
May
(3) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
(2) |
Feb
|
Mar
(5) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
(3) |
Feb
|
Mar
|
Apr
(6) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
(6) |
Dec
(1) |
2016 |
Jan
(5) |
Feb
(2) |
Mar
(2) |
Apr
(2) |
May
(5) |
Jun
(4) |
Jul
(2) |
Aug
(3) |
Sep
(4) |
Oct
(3) |
Nov
(1) |
Dec
|
2017 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(7) |
Oct
(1) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(28) |
Nov
(11) |
Dec
|
2021 |
Jan
(21) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Fábio J. <fab...@gm...> - 2022-05-02 16:11:19
|
lol. take a break. do some other stuff and come back to the software. Em seg., 2 de mai. de 2022 às 11:12, Johan Taunajik <j19...@gm...> escreveu: > I have super ears, I feel a change in aesthetics in sounds. > Maybe I'm a bit autistic around things with sounds. > I don't have a calculator, what number is 1e-8 in normal factor dB? > > Den man. 2. maj 2022 kl. 12.08 skrev Denis Sbragion < > d.s...@ne...>: > >> Hello Johan, >> >> Quoting Johan Taunajik <j19...@gm...>, Mon, 2 May 2022 11:15:26 >> -0200: >> >> And found out that the minimum correction file is like 1e-8 intervals. Is >> there a way to have like 1e-15? (I am not so good at programming, but I >> have compiled the app with -march=native -mtune=native -Ofast. Yeah, it is >> faster.) >> >> ... >> >> I'm not sure I understand what you're looking for. DRC uses double >> precision arithmetics since few versions, and this already means errors on >> the order of 1e-15. >> >> But, most important, do you understand what this really means? An error >> of 1e-8 is something like a +-0.0000001 dB error in the magnitude response >> and something like -160 dBFS for THD or noise. The JND for magnitude >> response errors is at most around 0.1 dB and for THD+N is around -100 dBFS, >> but these limits could be reached only in some quite uncommon specific >> situations. Most of the times it is more like +-0.5 dB for magnitude >> response, -60 dBFS for THD, and around -80 dBFS for noise. >> >> There's no way you're going to hear a 1e-8 error in real life, let alone >> a 1e-15 one. >> >> Bye, >> Denis Sbragion >> _______________________________________________ >> Drc-fir-users mailing list >> Drc...@li... >> https://lists.sourceforge.net/lists/listinfo/drc-fir-users >> > > > -- > Hilsen > Johan Taunajik > _______________________________________________ > Drc-fir-users mailing list > Drc...@li... > https://lists.sourceforge.net/lists/listinfo/drc-fir-users > |
From: Denis S. <d.s...@ne...> - 2022-05-02 15:29:46
|
Quoting Johan Taunajik <j19...@gm...>, Mon, 2 May 2022 13:14:01 -0200: > I am actually using Double, and can't get a higher e-'number' than > that I have been using. My impression is simply that you don't know what you're doing and what you're talking about. Denis Sbragion |
From: Johan T. <j19...@gm...> - 2022-05-02 15:14:23
|
Yeah, k. I am actually using Double, and can't get a higher e-'number' than that I have been using. Den man. 2. maj 2022 kl. 13.11 skrev Denis Sbragion <d.s...@ne... >: > Quoting Johan Taunajik <j19...@gm...>, Mon, 2 May 2022 12:11:39 > -0200: > > I have super ears, I feel a change in aesthetics in sounds. > Maybe I'm a bit autistic around things with sounds. > > Please, get back to earth, nobody can ear a magnitude response error of > +-0.0000001 dB, it's even impossible to measure it. > > Aaand, is there any hint where I can edit to address the minimum change in > the Correction Files? > > DRC has a define in drc.h which let you switch from single precision > arithmetic to double precision arithmetic, but double precision is already > the default and you can't get better than it. Double precision already > provides something like 1e-16 precision, way way more than what's needed > for almost any conceivable audio application, for sure way way more than > what's needed for DRC. > > Please stop all this nonsense. > Denis Sbragion > _______________________________________________ > Drc-fir-users mailing list > Drc...@li... > https://lists.sourceforge.net/lists/listinfo/drc-fir-users > -- Hilsen Johan Taunajik |
From: Denis S. <d.s...@ne...> - 2022-05-02 15:11:32
|
Quoting Johan Taunajik <j19...@gm...>, Mon, 2 May 2022 12:11:39 -0200: > I have super ears, I feel a change in aesthetics in sounds. > Maybe I'm a bit autistic around things with sounds. Please, get back to earth, nobody can ear a magnitude response error of +-0.0000001 dB, it's even impossible to measure it. > Aaand, is there any hint where I can edit to address the minimum > change in the Correction Files? DRC has a define in drc.h which let you switch from single precision arithmetic to double precision arithmetic, but double precision is already the default and you can't get better than it. Double precision already provides something like 1e-16 precision, way way more than what's needed for almost any conceivable audio application, for sure way way more than what's needed for DRC. Please stop all this nonsense. Denis Sbragion |
From: Johan T. <j19...@gm...> - 2022-05-02 14:22:20
|
Aaand, is there any hint where I can edit to address the minimum change in the Correction Files? Den man. 2. maj 2022 kl. 12.11 skrev Johan Taunajik <j19...@gm...>: > I have super ears, I feel a change in aesthetics in sounds. > Maybe I'm a bit autistic around things with sounds. > I don't have a calculator, what number is 1e-8 in normal factor dB? > > Den man. 2. maj 2022 kl. 12.08 skrev Denis Sbragion < > d.s...@ne...>: > >> Hello Johan, >> >> Quoting Johan Taunajik <j19...@gm...>, Mon, 2 May 2022 11:15:26 >> -0200: >> >> And found out that the minimum correction file is like 1e-8 intervals. Is >> there a way to have like 1e-15? (I am not so good at programming, but I >> have compiled the app with -march=native -mtune=native -Ofast. Yeah, it is >> faster.) >> >> ... >> >> I'm not sure I understand what you're looking for. DRC uses double >> precision arithmetics since few versions, and this already means errors on >> the order of 1e-15. >> >> But, most important, do you understand what this really means? An error >> of 1e-8 is something like a +-0.0000001 dB error in the magnitude response >> and something like -160 dBFS for THD or noise. The JND for magnitude >> response errors is at most around 0.1 dB and for THD+N is around -100 dBFS, >> but these limits could be reached only in some quite uncommon specific >> situations. Most of the times it is more like +-0.5 dB for magnitude >> response, -60 dBFS for THD, and around -80 dBFS for noise. >> >> There's no way you're going to hear a 1e-8 error in real life, let alone >> a 1e-15 one. >> >> Bye, >> Denis Sbragion >> _______________________________________________ >> Drc-fir-users mailing list >> Drc...@li... >> https://lists.sourceforge.net/lists/listinfo/drc-fir-users >> > > > -- > Hilsen > Johan Taunajik > -- Hilsen Johan Taunajik |
From: Johan T. <j19...@gm...> - 2022-05-02 14:11:57
|
I have super ears, I feel a change in aesthetics in sounds. Maybe I'm a bit autistic around things with sounds. I don't have a calculator, what number is 1e-8 in normal factor dB? Den man. 2. maj 2022 kl. 12.08 skrev Denis Sbragion <d.s...@ne... >: > Hello Johan, > > Quoting Johan Taunajik <j19...@gm...>, Mon, 2 May 2022 11:15:26 > -0200: > > And found out that the minimum correction file is like 1e-8 intervals. Is > there a way to have like 1e-15? (I am not so good at programming, but I > have compiled the app with -march=native -mtune=native -Ofast. Yeah, it is > faster.) > > ... > > I'm not sure I understand what you're looking for. DRC uses double > precision arithmetics since few versions, and this already means errors on > the order of 1e-15. > > But, most important, do you understand what this really means? An error of > 1e-8 is something like a +-0.0000001 dB error in the magnitude response and > something like -160 dBFS for THD or noise. The JND for magnitude response > errors is at most around 0.1 dB and for THD+N is around -100 dBFS, but > these limits could be reached only in some quite uncommon specific > situations. Most of the times it is more like +-0.5 dB for magnitude > response, -60 dBFS for THD, and around -80 dBFS for noise. > > There's no way you're going to hear a 1e-8 error in real life, let alone a > 1e-15 one. > > Bye, > Denis Sbragion > _______________________________________________ > Drc-fir-users mailing list > Drc...@li... > https://lists.sourceforge.net/lists/listinfo/drc-fir-users > -- Hilsen Johan Taunajik |
From: Denis S. <d.s...@ne...> - 2022-05-02 14:08:38
|
Hello Johan, Quoting Johan Taunajik <j19...@gm...>, Mon, 2 May 2022 11:15:26 -0200: > And found out that the minimum correction file is like 1e-8 > intervals. Is there a way to have like 1e-15? (I am not so good at > programming, but I have compiled the app with -march=native > -mtune=native -Ofast. Yeah, it is faster.) ... I'm not sure I understand what you're looking for. DRC uses double precision arithmetics since few versions, and this already means errors on the order of 1e-15. But, most important, do you understand what this really means? An error of 1e-8 is something like a +-0.0000001 dB error in the magnitude response and something like -160 dBFS for THD or noise. The JND for magnitude response errors is at most around 0.1 dB and for THD+N is around -100 dBFS, but these limits could be reached only in some quite uncommon specific situations. Most of the times it is more like +-0.5 dB for magnitude response, -60 dBFS for THD, and around -80 dBFS for noise. There's no way you're going to hear a 1e-8 error in real life, let alone a 1e-15 one. Bye, Denis Sbragion |
From: Johan T. <j19...@gm...> - 2022-05-02 13:15:44
|
Hi, I am an audiophile. (Johan Taunajik) And I really like your APP quite a lot. I have been working on my Custom Microphone correction for a long time now (6-8 years). And found out that the minimum correction file is like 1e-8 intervals. Is there a way to have like 1e-15? (I am not so good at programming, but I have compiled the app with -march=native -mtune=native -Ofast. Yeah, it is faster.) The limit is like 1e-8, and I want more numbers after 1e-8, but DRC-FIR won't do after 1e-8, like changing in a 1e-10 correction file, and won't change the calculated PCM - DRC Corrected. Is there any way in source code (change) that can calculate, way more than the 5e-9 limit? (0.0000000001) I have reached my own personal liking quite a lot, as an audiophile, I need to go more than 5e-9. I have been working on my correction file for a long time... and need to go beyond that limit. Help me pls? (I am using hardware Steinberg UR22 MKll - Behringer ECM8000, not the best hardware around) Yeah I looked a bit around in source codes, but couldn't find any clues. I am not very programmer skilled. -- Hilsen Johan Taunajik |
From: Denis S. <d.s...@ne...> - 2021-08-29 09:34:17
|
Hello Fábio, Quoting Fábio Wolarski <fab...@gm...>, Sat, 28 Aug 2021 09:33:54 -0300: > I found out that the flatter the envelope of the unsmoothed > graph, the more the smoothed graph resembles the traditional house > curves, in my case a specific one from Olive Tool (not the > traditional Harman). > Also on the subjective side the sound becomes incredibly "3d". > I have been playing around with unsmoothed graphs and > the psychoacoustic target function. using trial and error > with PTBandWidth, PTPeakDetectionStrength and the windowing values I > managed to approach a flat envelope on the unsmoothed graph. > Unfortunately this has it's limitations since DRC doesn't really target this. > Are there any further variables I can play around with to achieve my goal? I don't understand exactly what you're trying to do. The psychoacoustic target is designed to get a flat envelope, but not perfectly flat, because this isn't what other algorithms do in the literature, notably MVDR. If you want a flatter envelope you should increase the PTPeakDetectionStrength value, but be careful, because above some value it will start overflowing and the exact overflowing value cannot be computed easily. It should be somewhere around 60, but no exact value is available. The fact that you get a smoothed house curve with a flat envelope is expected. There's a known relationship between the peak and the average value of the magnitude response in a diffuse field: Delta(dB) = 4.34 * Ln(Ln(B * T)) Where B is the bandwidth, T is the reverberation time and Delta(dB) is the difference between the peaks in the magnitude response and its average over a B bandwith, i.e. over a "B smoothing". Put the usual 1/3 of octave smoothing and some reasonable value for T in that formula and you'll see that a flat envelope in a typical house room will provide something really close to the well know Moeller curve over 1/3 oct smoothing. Considering also that T is within a double logarithm the result will be almost independent from the reverberation time. The problem here is that most room don't provide a perfect diffuse field so the correction provided by the "one size fits all" Moeller curve couldn't be good for all rooms. Bye, -- Denis Sbragion |
From: Fábio W. <fab...@gm...> - 2021-08-28 12:34:16
|
Hi Denis and users, I found out that the flatter the envelope of the unsmoothed graph, the more the smoothed graph resembles the traditional house curves, in my case a specific one from Olive Tool (not the traditional Harman). Also on the subjective side the sound becomes incredibly "3d". I have been playing around with unsmoothed graphs and the psychoacoustic target function. using trial and error with PTBandWidth, PTPeakDetectionStrength and the windowing values I managed to approach a flat envelope on the unsmoothed graph. Unfortunately this has it's limitations since DRC doesn't really target this. Are there any further variables I can play around with to achieve my goal? Thanks Fábio |
From: Fábio W. <fab...@gm...> - 2021-01-29 16:34:17
|
never mind, I figuered I could run Align2 from terminal and see all the variables. seams to be --PLStartFreq Em sex., 29 de jan. de 2021 às 13:21, Fábio <fab...@gm...> escreveu: > Algin2 doesn't limit the window, (xx)StartFreq(s) are at 20Hz. > but it has a field to limit the correction, and it does limit it. how does > it > do it? > > > |
From: Fábio <fab...@gm...> - 2021-01-29 16:22:22
|
Algin2 doesn't limit the window, (xx)StartFreq(s) are at 20Hz. but it has a field to limit the correction, and it does limit it. how does it do it? |
From: Denis S. <d.s...@ne...> - 2021-01-25 16:48:36
|
Hello Roger, sorry for the delay. Quoting Roger Monteith <rog...@ho...>: > Can you confirm my understand here ? > - The stages before the Post Filtering are targeting a particular > frequency response (gentle slope down toward high frequencies) and > minimum phase response. > - Post-filtering stage then applies the "delta" values in the target > response to this. Using the --PSFilterType=L means the minimum > phase characteristic from the previous stage remains unchanged. No, it doesn't work that way. Even though before the PS stage there are certain operations which are carried out by minimum phase processing, this doesn't mean that the target is minimumn phase. Essentially at any stage before the PS stage the target is always to get to a linear phase response. After that you can choose either to keep the linear phase response or to switch to a different phase response. If you switch you have two further options, either a minimum phase *correction*, which has zero latency but discards any excess phase correction and corrects only the minimum phase, or a minimum phase *target* response, with a reasonable trade-off between latency and phase linearity. Of course having a linear phase target doesn't mean that the final response is exactly a linear phase response. A perfect linear phase response would have either unacceptable pre-echo, cause the response must be perfectly symmetrical, or a tiny listening area, like the size of a pin-head, 'cause you would need to correct too much to make the pre-echo low enough in level to be inaudible. There's a lot of psychoacoustic involved and getting the right balance is quite a complicated task. > I had wanted to force the response to a linear phase across the HP > filter region, but because my main speaker already have significant > roll-off, and associated natural phase shift, just setting the > --PSFilterType=L was not enough to get me linear phase. ... We started from the idea of using the target response as a crossover. For this to work the two sides of the crossover need to sum up to a perfect unitary response, i.e. perfectly linear both in phase and amplitude. This could be achieved with DRC only by leveragin the "perfect reconstruction filterbank" condition for FIR filters, which impose the use of linear phase filters. By setting --PSFilterType=L DRC uses linear phase filters for the target response, so, by carefully setting both the target response and the windowing, you could get pairs of filters providing both room correction and crossover functions. But it isn't easy, you must be really careful while measuring and you have to really be careful with the DRC settings. I'm not suggesting this approach, it's really really difficult to carry it out properly. Instead use an xover to do the xover and DRC to do the correction after the xover has been properly set up. Even in my own system I separated xover and correction functions, even though they're both performed by the same program (BruteFIR), and I perform the correction by measuring with the xover in place. Bye, -- Denis Sbragion |
From: Fábio <fab...@gm...> - 2021-01-20 23:53:14
|
sorry, when I wrote I observe "excess phase", I actualy meant excess group delay |
From: Fábio <fab...@gm...> - 2021-01-20 23:47:51
|
Em quarta-feira, 20 de janeiro de 2021, às 19:38:37 -03, Roger Monteith escreveu: > Hi Denis, > > Thanks for the response. Thanks for making the software available! > > I had actually used that setting, but it had not quite the effect I had > hoped for. > > Can you confirm my understand here ? > - The stages before the Post Filtering are targeting a particular > frequency response (gentle slope down toward high frequencies) and > minimum phase response. > - Post-filtering stage then applies the "delta" values in the target > response to this. Using the --PSFilterType=L means the minimum phase > characteristic from the previous stage remains unchanged. > > I had wanted to force the response to a linear phase across the HP > filter region, but because my main speaker already have significant > roll-off, and associated natural phase shift, just setting the > --PSFilterType=L was not enough to get me linear phase. > > Anyway, to learn more about all this I've gone back to working > REW+RePhase as it allows some more manual control - better to understand > the issues. > In the last tuning I decided to go with the "inherent" phase response of > the Sub and Main in the cross-over region and just try to apply smallest > phase corrections to improve the match. Result, the best sounding setup > I've managed yet ! > > But the sequence of steps to get to this setup was a bit convoluted, so > I'd like to still come back to DRC-FIR and try to find a way to > incorporate it in the measurement and tuning flow. So my plan is to > I'll listen to what I have now for a week or so then have another go > with DRC-FIR and see if I can use it to automate a bit more of the process. > > Thanks again, > > Roger > > > _______________________________________________ > Drc-fir-users mailing list > Drc...@li... > https://lists.sourceforge.net/lists/listinfo/drc-fir-users personaly I use the insane preset and filtertype=l and play around with the eplowerwindow while observing the exess phase in REW (which will make midrange acoustic artifacts visible as they will show as negative values). that way you can prety much get almost everything but very lowest freqencies near to linear phase I don't use the psychoacoustic target though and use --MPUpperWindow=44 -- EPUpperWindow=44 --RTUpperWindow=44 in order to only correct direct sound above 1000Hz. that way I can use a flat target without it resulting in bright sound. about my initial topic. I actualy got it to work (including the crossover). more on that later. I will also use the regular method and compare the results |
From: Roger M. <rog...@ho...> - 2021-01-20 22:38:57
|
Hi Denis, Thanks for the response. Thanks for making the software available! I had actually used that setting, but it had not quite the effect I had hoped for. Can you confirm my understand here ? - The stages before the Post Filtering are targeting a particular frequency response (gentle slope down toward high frequencies) and minimum phase response. - Post-filtering stage then applies the "delta" values in the target response to this. Using the --PSFilterType=L means the minimum phase characteristic from the previous stage remains unchanged. I had wanted to force the response to a linear phase across the HP filter region, but because my main speaker already have significant roll-off, and associated natural phase shift, just setting the --PSFilterType=L was not enough to get me linear phase. Anyway, to learn more about all this I've gone back to working REW+RePhase as it allows some more manual control - better to understand the issues. In the last tuning I decided to go with the "inherent" phase response of the Sub and Main in the cross-over region and just try to apply smallest phase corrections to improve the match. Result, the best sounding setup I've managed yet ! But the sequence of steps to get to this setup was a bit convoluted, so I'd like to still come back to DRC-FIR and try to find a way to incorporate it in the measurement and tuning flow. So my plan is to I'll listen to what I have now for a week or so then have another go with DRC-FIR and see if I can use it to automate a bit more of the process. Thanks again, Roger |
From: <jdi...@go...> - 2021-01-20 16:42:37
|
> On Jan 20, 2021, at 3:54 AM, Denis Sbragion <d.s...@ne...> wrote: > >> If you accepted pull-requests, I'd be happy to submit some additions to the documentation to rectify this. Heck, I'd even be happy to submit a working version of the now long-broken "measure" shellscript. >> >> But, apparently, that doesn't seem to be how things work around here? > > To accept pull request I'd have to migrate everything to GitHub or something like that. It needs time. Did I say you that all of this is done for free? Well, I offered ... > And well, around here things works as I want them to work, it's my project after all. You're free to fork it if you don't agree. This already happened with some of my projects in the past. Do you really want to know what happened to the roaring forks? Having contributed to more open-source projects than I can count, I think I have a pretty good idea how all this works ... Thanks for the clarifications. |
From: Denis S. <d.s...@ne...> - 2021-01-20 09:54:53
|
Quoting jdi...@go...: > An issue which is not mentioned *anywhere* in the glsweep/lsconv > documentation. It isn't mentioned that 2+2=4 either. The clock drift problem is well known since ages, well before USB mics were introduced, when some people wanted to measure with the sweep on a CD and recording with a separate soundcard, which incurs the same exact problem. I can't turn the DRC documentation into a full course on DSP and acoustic measuring, especially considering that DRC isn't about measuring, it's about correcting. The few measuring tools come as a bonus and I developed them only because when all this started, more than 20 (twenty, I repeat, twenty) years ago, there was no such tool available for free and even the commercial ones where for the most part MLS based. Now there are plenty, what's the point in developing another one? > But to expect users to hunt through the mailing list (a thoroughly > user-unfriendly process, in case you've ever tried it), for *crucial > information* that is absent from the documentation is ... a bit much. Again, complaining. Sourceforge provides hosting for free and you think only about complaining on the quality of its service. That information is crucial only if you want to measure using an approach which is problematic by itself and remains problematic even after contermeasures are put in place. See the discussion on the mailing list if you want some hint on what's involved. I know that USB mics are now widely used, but it's not my fault if the wrong approach took place so it's not my duty to fix it. Blame the mic manufacturer, which is about measuring, get money for it, and didn't warn you that USB mics aren't suited for sweep measurements. But I'm sure you already did, right? > If you accepted pull-requests, I'd be happy to submit some additions > to the documentation to rectify this. Heck, I'd even be happy to > submit a working version of the now long-broken "measure" shellscript. > > But, apparently, that doesn't seem to be how things work around here? To accept pull request I'd have to migrate everything to GitHub or something like that. It needs time. Did I say you that all of this is done for free? And well, around here things works as I want them to work, it's my project after all. You're free to fork it if you don't agree. This already happened with some of my projects in the past. Do you really want to know what happened to the roaring forks? Bye, -- Denis Sbragion |
From: <jdi...@go...> - 2021-01-20 08:08:46
|
> On Jan 20, 2021, at 12:41 AM, Denis Sbragion <d.s...@ne...> wrote: > > Quoting jdi...@go...: > >> Rather than having users waste their time (as I did) with glsweep/lsconv, they could be directed to use a more appropriate measuring tool, like REW. > > Or may be, to avoid wasting time, you could have studied a little how things work, so you would know that clock drift is one of the few things where the log sweep method has issues and you need to pay attention to. An issue which is not mentioned *anywhere* in the glsweep/lsconv documentation. > This attitude, which I see popping up more and more in recent times, is unbelievable. You have a tool for free, but instead of thanking for it or helping improving it, you just complain and ask others to do what you should have done from the beginning, like taking a look at the mailing list archives for example. DRC is a wonderful tool. And I am grateful for your hard work in developing it. But to expect users to hunt through the mailing list (a thoroughly user-unfriendly process, in case you've ever tried it), for *crucial information* that is absent from the documentation is ... a bit much. If you accepted pull-requests, I'd be happy to submit some additions to the documentation to rectify this. Heck, I'd even be happy to submit a working version of the now long-broken "measure" shellscript. But, apparently, that doesn't seem to be how things work around here? |
From: Denis S. <d.s...@ne...> - 2021-01-20 06:42:05
|
Quoting jdi...@go...: > Rather than having users waste their time (as I did) with > glsweep/lsconv, they could be directed to use a more appropriate > measuring tool, like REW. Or may be, to avoid wasting time, you could have studied a little how things work, so you would know that clock drift is one of the few things where the log sweep method has issues and you need to pay attention to. This attitude, which I see popping up more and more in recent times, is unbelievable. You have a tool for free, but instead of thanking for it or helping improving it, you just complain and ask others to do what you should have done from the beginning, like taking a look at the mailing list archives for example. Bye, -- Denis Sbragion |
From: <jdi...@go...> - 2021-01-19 17:01:20
|
> On Jan 19, 2021, at 9:01 AM, Denis Sbragion <d.s...@ne...> wrote: > > Quoting jdi...@go...: >> That seemed to produce (marginally) better results (possibly because I am using a USB microphone) than glsweep/lsconv. > > Yes, USB mics have clock drift problems that lsconv doesn't compensate for. There has been an heated discussion about this issue just few weeks ago. Take a look at the list archives for some more information. It might be worthwhile updating the documentation to reflect this. Rather than having users waste their time (as I did) with glsweep/lsconv, they could be directed to use a more appropriate measuring tool, like REW. |
From: Denis S. <d.s...@ne...> - 2021-01-19 15:01:59
|
Quoting jdi...@go...: > That seemed to produce (marginally) better results (possibly because > I am using a USB microphone) than glsweep/lsconv. Yes, USB mics have clock drift problems that lsconv doesn't compensate for. There has been an heated discussion about this issue just few weeks ago. Take a look at the list archives for some more information. Bye, -- Denis Sbragion |
From: <jdi...@go...> - 2021-01-18 20:23:56
|
> On Jan 18, 2021, at 3:20 AM, Denis Sbragion <d.s...@ne...> wrote: > > that script is 15 years old, trying to remember what I did then. BTW it's using both channels because a reference channel mesurement is performed. One channel is used to measure the system, the other channel is used in a loopback configuration to measure the soundcard and compensate for it. Stereo measurements isn't supported by that script, so you need to measure one channel at a time, switching cables from one channel to the other(s). I gather the preferred method, these days, is to skip glsweep/lsconv and do the IR measurements in REW. That seemed to produce (marginally) better results (possibly because I am using a USB microphone) than glsweep/lsconv. > Of course SoX could also have been changed since then and so may be some adjustment is needed to that too, but it shouldn't be so difficult. The script assumes that the soundcard left channel is used for system measurement and the right channel as a reference loopback. Fixing the script wasn't hard. The hard part was understanding/correcting for the hardware assumptions built into it. I'd still be interested in being able to do everything (from measurements to final corrections) on the Raspberry Pi (with hat-DAC) in my stereo system. But that would require more than just fixing the "measure" shellscript. |
From: Denis S. <d.s...@ne...> - 2021-01-18 11:26:16
|
Quoting Roger Monteith <rog...@ho...>: ... > What I could not easily find a way to do was to get DRC to force the > phase to flat in the LPF and HPF regions. By default it seems to > always target a minimal phase response (which can make the > cross-over messy). ... You can set a linear phase target by setting --PSFilterType=L. Be prepared for huge latencies. Bye, -- Denis Sbragion |
From: Denis S. <d.s...@ne...> - 2021-01-18 09:30:01
|
Hello Fábio, Quoting Fábio <fab...@gm...>: > I have problems with DRC and a subwoofer. > I know I could correct the complete signal (sub+main), but I am trying to > correct them seperatly and then send them through my linear phase crossover. ... trying this approach you're running into all sorts of problem. The main issue here is that if you apply the x-over after the correction there's no way for DRC to know what the x-over is doing and so correct it. The right approach is to setup first the x-oover and then measure the system with the x-over in place, so that DRC is fed with an impulse response which includes the x-over effect. The only way to use DRC also as an x-over is to fiddle with the target response, as Roger Monteith is somewhat explaining in another message. But to do this you have to ensure that the x-over sums up to a perfect unitary impulse response. The only simple way to achieve this is to ensure the "perfect reconstruction filterbank" condition for linear phase filters, which means using a linear phase target response which in turn implies a huge latency, equal to half the filter length, about 0.7 s with the default settings. All of this requires a really careful setup, playing attention to windowing, target responses and any other detail involved. Believe me, it's a mess, better to stay with the traditional approach of applying the correction to the whole system. Bye, -- Denis Sbragion |