I have other windowing algorithms implementations that I would like to add.
Can you share one of your rephase files so I can check if one of those would fare better than the bartlett-hann one?
I plan to add Chebychev window with variable ripple floor, but I have to find a way to make it faster than it is now...
This is similar to the Kaiser window, and has some nice properties.
Parks–McClellan is not a window but a method to build filters, and rephase has its own
Here is the file. I was using "Bypass" mode to assure the SPL is smooth and flat at Zero. This was my main focus. Some minor deviation of phase at very LF is not as big a concern for me, but I looked to make that as good a possible also.
View attachment 2015-02-17rePhase44kBartlett-Hann.zip
Thanks
It looks like hann window also gives good results with your correction.
Also try to use a higher FFT size, like 65536, so you (and the iterative optimization process) get a more accurate view of what is going on down low.
Also try energy centering is this case: this will give you a better phase matching.
Anyway, I will keep your correction to check the new algorithms. Thank you.
As a side note, are you sure you need that much phase correction down low?
Measurements are often doubtful and almost meaningless at these frequencies, especially in domestic environment, so it is often better to stick with theoretical corrections at these frequencies (BR, etc.), or live them alone altogether.
Also, regarding in band phase correction, have you tried using some minimum-phase EQ to linearize the amplitude, and see the effect on phase?
I plan on adding an "excess phase" visualization in a future version, and use that as the preferred phase EQ target...
It looks like hann window also gives good results with your correction.
Also try to use a higher FFT size, like 65536, so you (and the iterative optimization process) get a more accurate view of what is going on down low.
Also try energy centering is this case: this will give you a better phase matching.
Anyway, I will keep your correction to check the new algorithms. Thank you.
As a side note, are you sure you need that much phase correction down low?
Measurements are often doubtful and almost meaningless at these frequencies, especially in domestic environment, so it is often better to stick with theoretical corrections at these frequencies (BR, etc.), or live them alone altogether.
Also, regarding in band phase correction, have you tried using some minimum-phase EQ to linearize the amplitude, and see the effect on phase?
I plan on adding an "excess phase" visualization in a future version, and use that as the preferred phase EQ target...
pos, thanks for the comments.
Yes, I played with all those options. I also found that Hann would be a good option. Go ahead and drop Bartlett-Hann, I am not really opposed to that.
I am reasonably confident my LF phase rise is accurate for my setup. It includes the phase correction for all my measurement chain devices; Audio Interface, AV Pre/Pro, DCX2496, P-Amp, and mic preamp. So the measurements should be representative of the true speaker response. I have a B-24 HP filter at 20Hz set in the DCX so that adds to the ported SWs. My measurements are set to start at 12Hz so I don’t pay much attention below that.
In my case the It would seem more convenient if RePhase just allowed stacking random filter orders at various freq to best match the phase rollup. The choices offered are not very easy to fit to my real world situation as you saw. I defer to you and others needs however as you are probably the more representative of common usage.
Regardless of my choice of house curve would I not want the direct sound phase to be linear at my LP? My logic has been that Irrespective of my choice of SPL it is still correct to have all freqs arrive at the same time. I suppose if my tapered house curve causes REW/Holm to report phase rotation that is in fact not there then this may be the wrong approach? I am not really sure of my logic on this point.
The SPL of my 5 identical speakers are EQed in the DCX with mic at the ~4m LP. EQ is done as well as I believe is appropriate given the DCX capabilities. The phase appears to appropriately follow the SPL when considering the disruptive impact of modes and reflections. I average these 5 speakers to better see the trend of the phase. I just ignore all the various midrange phase ripples. I sometimes confirm that all is well by turning off the SWs and measuring one main at 1m or so with the rePhase filter applied. I normally get a very smooth SPL and pretty linear phase from 80-20k when I do this.
Are you saying there is a better way to deal with this? I may well be missing some opportunities with my process so any comments you have would be appreciated. Below are some charts just to show what I am looking at prior to creating the phase correction filter that I use in FooBar.
Yes, I played with all those options. I also found that Hann would be a good option. Go ahead and drop Bartlett-Hann, I am not really opposed to that.
I am reasonably confident my LF phase rise is accurate for my setup. It includes the phase correction for all my measurement chain devices; Audio Interface, AV Pre/Pro, DCX2496, P-Amp, and mic preamp. So the measurements should be representative of the true speaker response. I have a B-24 HP filter at 20Hz set in the DCX so that adds to the ported SWs. My measurements are set to start at 12Hz so I don’t pay much attention below that.
In my case the It would seem more convenient if RePhase just allowed stacking random filter orders at various freq to best match the phase rollup. The choices offered are not very easy to fit to my real world situation as you saw. I defer to you and others needs however as you are probably the more representative of common usage.
Regardless of my choice of house curve would I not want the direct sound phase to be linear at my LP? My logic has been that Irrespective of my choice of SPL it is still correct to have all freqs arrive at the same time. I suppose if my tapered house curve causes REW/Holm to report phase rotation that is in fact not there then this may be the wrong approach? I am not really sure of my logic on this point.
The SPL of my 5 identical speakers are EQed in the DCX with mic at the ~4m LP. EQ is done as well as I believe is appropriate given the DCX capabilities. The phase appears to appropriately follow the SPL when considering the disruptive impact of modes and reflections. I average these 5 speakers to better see the trend of the phase. I just ignore all the various midrange phase ripples. I sometimes confirm that all is well by turning off the SWs and measuring one main at 1m or so with the rePhase filter applied. I normally get a very smooth SPL and pretty linear phase from 80-20k when I do this.
Are you saying there is a better way to deal with this? I may well be missing some opportunities with my process so any comments you have would be appreciated. Below are some charts just to show what I am looking at prior to creating the phase correction filter that I use in FooBar.
Reload the same file in a working zip this time.
I attempted to work the math back from a paper. I may be close .. I may be way off. Please don't use this to design a filter until someone with experience chimes in!
I have been using rePhase for almost 2 years. It is very easy to use and gives excellent results and sound quality. The idea of focusing on manual corrections is very good, I like to stay in control and selectively choose corrections. Amazingly rePhase is free, but the value is in my opinion very high. So Pos, when are you ready to receive donations? For sure, I am ready to donate.
One wish for improvement: it would be nice with a short explanation for each field in the settings. Fx. in the impulse settings, centering: what are the implications of choosing “use exact centering value” and the other options?
My current and most advanced use so far is for a 3 way active speaker system. My use is somewhat similar to Pano’s. The filters are implemented in a PC feeding a multichannel DAC that directly sends the signal to power amplifiers. The procedure is: measurement with Holm, import to rePhase for amplitude and phase linearization. After this I am free to play around with XO settings for filter generation and import the filters to JRiver via convolver interface. So far I have primarily used LR 24 dB for XO. Results are very good with a lot of details, dynamics and a very well defined soundscape. Taps are the largest available, 65536.
I have formerly regarded brickwall filters as a primitive, brutal concept for XO, but based on post 557, I tried it. The windows were hamming and blackmann in accordance with textbook recommendations. Surprise. Imaging became even better, the sound was even clearer and fuller and sweet spot widened both horizontally and vertically. This is probably due to the absence of crossover regions where one frequency is played back through two loudspeaker units (reduced comb filtering and remaining phase differences?). The sound was not fatiguing or unpleasant in any way. I had expected some audible ringing, but nothing of the kind manifested. The only drawback is a low whistling tone setting in as soon as playback is started, which is about 2/3 second before music starts to play (FIR filter delay). What might be the cause of this whistling and does anyone have suggestions to get rid of it? The processing time for generation is a lot faster for brickwall filters compared to LR, is the generation/calculation in rePhase different, and can this the reason for different sonic quality? Does anyone have suggestions for improving use of brickwall filters for XO?
I have just read the entire 600+ posts in this thread. This calls for a few tips of mine regarding issues raised.
Measurement of delay between loudspeaker units in active systems is very easy using Holm. Just send the frequency sweep in parallel to two amplifiers and measure in listening position. The impulse screen in Holm will show two peaks, and time delay between peaks can be read on the horizontal axis after setting it to show to time instead of samples which is default. This is the delay to implement in JRiver or VSTconvolver.
DSP processing of sound from all windows applications can be achieved easily through JRiver version 20 because it comes with a WDM driver. By choosing this as Windows standard sound unit, sound is automatically processed through JRivers DSP and filters. No need for starting loopback as in previous editions.
Synchronization of sound and video is automatically optimized when playing movies through JRiver due to the “lip sync” function. Synchronization of sound and video from other programs can be achieved by setting a manual delay for video in JRiver.
My last remarks has developed into something similar to a commercial for JRiver – sorry about that – I am not paid by JRiver. It is just so easy to integrate all functions related to DSP filters in JRivers standard functionality, so I have to praise it for that. I am not so pleased with its user interface, but that’s another story.
Phuu, this is a long post. Once again, thanks, thanks, thanks for rePhase.
One wish for improvement: it would be nice with a short explanation for each field in the settings. Fx. in the impulse settings, centering: what are the implications of choosing “use exact centering value” and the other options?
My current and most advanced use so far is for a 3 way active speaker system. My use is somewhat similar to Pano’s. The filters are implemented in a PC feeding a multichannel DAC that directly sends the signal to power amplifiers. The procedure is: measurement with Holm, import to rePhase for amplitude and phase linearization. After this I am free to play around with XO settings for filter generation and import the filters to JRiver via convolver interface. So far I have primarily used LR 24 dB for XO. Results are very good with a lot of details, dynamics and a very well defined soundscape. Taps are the largest available, 65536.
I have formerly regarded brickwall filters as a primitive, brutal concept for XO, but based on post 557, I tried it. The windows were hamming and blackmann in accordance with textbook recommendations. Surprise. Imaging became even better, the sound was even clearer and fuller and sweet spot widened both horizontally and vertically. This is probably due to the absence of crossover regions where one frequency is played back through two loudspeaker units (reduced comb filtering and remaining phase differences?). The sound was not fatiguing or unpleasant in any way. I had expected some audible ringing, but nothing of the kind manifested. The only drawback is a low whistling tone setting in as soon as playback is started, which is about 2/3 second before music starts to play (FIR filter delay). What might be the cause of this whistling and does anyone have suggestions to get rid of it? The processing time for generation is a lot faster for brickwall filters compared to LR, is the generation/calculation in rePhase different, and can this the reason for different sonic quality? Does anyone have suggestions for improving use of brickwall filters for XO?
I have just read the entire 600+ posts in this thread. This calls for a few tips of mine regarding issues raised.
Measurement of delay between loudspeaker units in active systems is very easy using Holm. Just send the frequency sweep in parallel to two amplifiers and measure in listening position. The impulse screen in Holm will show two peaks, and time delay between peaks can be read on the horizontal axis after setting it to show to time instead of samples which is default. This is the delay to implement in JRiver or VSTconvolver.
DSP processing of sound from all windows applications can be achieved easily through JRiver version 20 because it comes with a WDM driver. By choosing this as Windows standard sound unit, sound is automatically processed through JRivers DSP and filters. No need for starting loopback as in previous editions.
Synchronization of sound and video is automatically optimized when playing movies through JRiver due to the “lip sync” function. Synchronization of sound and video from other programs can be achieved by setting a manual delay for video in JRiver.
My last remarks has developed into something similar to a commercial for JRiver – sorry about that – I am not paid by JRiver. It is just so easy to integrate all functions related to DSP filters in JRivers standard functionality, so I have to praise it for that. I am not so pleased with its user interface, but that’s another story.
Phuu, this is a long post. Once again, thanks, thanks, thanks for rePhase.
Hi Laotzu1
I am pondering adding a paypal donation button when version 1.0.0 is released, but I am not sure yet.
Maybe a question mark button on the top corner of each tab?...
That is a good suggestion that I will try to implement for the 1.0.0 release
Regarding centering option, short answer is always use the ideal centering.
Other options might give you ripples around the impulse peak (that can be observed by loading the IR into holm) when the final fractional sample is different than the ideal value which artificially enforce a 0° phase as the Nyquist frequency.
You must use the same window, sampling freq and number of taps for both sides of the crossover or the summation will not be perfect.
Using additional corrections might also affect the final complementarity...
If you want steep slopes it is probably better to use LR with high slope values and make sure your window will let the resulting curve track the target ones close enough.
Also try reject high of low crossover types if you want to reject specific frequency ranges from your drivers...
Regarding the noise, I have no idea where it can come from.
Try loading the impulse in audacity or holm and look for any weird thing...?
Jriver most probably implements its convolution in the frequency domain, which can also imply all sorts of warts when not done properly, although I am sure their implementation is just fine...
Maybe try a direct time domain convolution engine just to make sure?
Regarding brickwall being faster to generate, it probably comes from the fact that iterative optimizations is bypassed (same as "none" setting) when they are used, becuase it somewhat goes against the very principle of that kind of filter...
Thank youI have been using rePhase for almost 2 years. It is very easy to use and gives excellent results and sound quality. The idea of focusing on manual corrections is very good, I like to stay in control and selectively choose corrections. Amazingly rePhase is free, but the value is in my opinion very high. So Pos, when are you ready to receive donations? For sure, I am ready to donate.
I am pondering adding a paypal donation button when version 1.0.0 is released, but I am not sure yet.
You mean like an integrated help functionality?
Maybe a question mark button on the top corner of each tab?...
That is a good suggestion that I will try to implement for the 1.0.0 release
Regarding centering option, short answer is always use the ideal centering.
Other options might give you ripples around the impulse peak (that can be observed by loading the IR into holm) when the final fractional sample is different than the ideal value which artificially enforce a 0° phase as the Nyquist frequency.
Brickwall filers are indeed the most prehistorical form of FIR filtering, and very easy to do (windowed sinc...).
You must use the same window, sampling freq and number of taps for both sides of the crossover or the summation will not be perfect.
Using additional corrections might also affect the final complementarity...
If you want steep slopes it is probably better to use LR with high slope values and make sure your window will let the resulting curve track the target ones close enough.
Also try reject high of low crossover types if you want to reject specific frequency ranges from your drivers...
Regarding the noise, I have no idea where it can come from.
Try loading the impulse in audacity or holm and look for any weird thing...?
Jriver most probably implements its convolution in the frequency domain, which can also imply all sorts of warts when not done properly, although I am sure their implementation is just fine...
Maybe try a direct time domain convolution engine just to make sure?
Regarding brickwall being faster to generate, it probably comes from the fact that iterative optimizations is bypassed (same as "none" setting) when they are used, becuase it somewhat goes against the very principle of that kind of filter...
Thanks for a very quick and thorough reply.
You have very good ideas about a help function integrated in the programme. That would be superb. Less can do it, fx. a document with screen dumps and a few comments on relevant topics. A lot of choices are self explanatory, like file menus etc., no need for writing about this.
Does this mean choosing "middle" and "use exact centering value" from the options?
I have tried LR48 and LR96. They sound a little smeared compared to brickwall. Maybe brickwall works well due to the very long filter with 65536 taps. Based on your recommendations, I will try using reject high and reject low for XO.
About loading the impulse in Holm? Do you mean export the impulse from rePhase as text file and import it in Holm? This looks identical for brickwall and LR24.
Edit: I don't know exactly what you mean by convolution in the time domain. JRiver uses VST convolver, and the implementation allows for correction of frequency as well as phase, so the convolution process includes time domain. For a start, I just used JRivers convolution for phase correction and it performed very well.
You have very good ideas about a help function integrated in the programme. That would be superb. Less can do it, fx. a document with screen dumps and a few comments on relevant topics. A lot of choices are self explanatory, like file menus etc., no need for writing about this.
Does this mean choosing "middle" and "use exact centering value" from the options?
I have tried LR48 and LR96. They sound a little smeared compared to brickwall. Maybe brickwall works well due to the very long filter with 65536 taps. Based on your recommendations, I will try using reject high and reject low for XO.
About loading the impulse in Holm? Do you mean export the impulse from rePhase as text file and import it in Holm? This looks identical for brickwall and LR24.
Edit: I don't know exactly what you mean by convolution in the time domain. JRiver uses VST convolver, and the implementation allows for correction of frequency as well as phase, so the convolution process includes time domain. For a start, I just used JRivers convolution for phase correction and it performed very well.
Last edited:
You are right, I should work on a simple google doc first.
Sorry, I realize my comment was misleading: by ideal I meant the "perfect impulse" centering option.
As for middle vs energy and other options, energy is supposed to be ideal but for some reasons (that I'll need to investigate) it does not always work out that well. If you know you are only using minimum-phase correction then using something like 1% or a few samples should be ideal, and of course when only using linear-phase correction middle is ideal (and is in fact enforced).
You can try higer slopes than that if you want to. LR can go up to 996dB/oct IIRC.
These filters are also quite misleading in their naming I am afraid: you cannot use reject high on one side and reject low on the other: you need to use a reject high low pass together with a reject high high pass to get a complementary crossover (and of course same goes for reject low).
The purpose of that crossover is to attenuate one driver much faster than the other.
For example if your woofer has known breakups (eg metal cone) you will want to use reject high, and let the tweeter have a shallower slope.
On the other hand if you have a more forgiving woofer (eg paper cone) and your tweeter has a high Fs or is crossed lower than its comfort zone you might want to use reject low...
Time-domain (FFT) convolution vs frequency-domain (direct) convolution are just two different ways of implementing a convolution, and should give the same result.
Time domain convolution is more CPU intensive, more brutal, but also more direct and simple, ie potentially less prone to errors and approximations
Software convolution engines usually use FFT convolution because it is faster to operate, whereas DSP hardware engines usually implement direct convolution because it requires less memory. It also implies less processing delay.
IMHO if you have the choice you should always use time-domain convolution.
Unfortunately I don't know of any software convolution engine implementing direct time-domain convolution
Hi pos,
i would say:
time domain= direct convolution
frequency domain=(FFT/IFFT) convolution.
An externally hosted image should be here but it was not working when we last tested it.
Unfortunately I don't know of any software convolution engine implementing direct time-domain convolution
You mean real time. Matlab and all its free clones have a convolve() function which is done in the brute force (slow) fashion. This can be used on small sound bites to verify accuracy. I have also verified that SoX's fft based fir function is good down to the numerical resolution.
Last edited:
Not to put words into Scott's mouth, but methinks he means that the FFT->multiplication->iFFT steps show no residual errors (at any of the bit levels he tested, which I'd assume are int16 through float64) versus a simple brute-force convolution in the time domain.
If so, and if the algorithm is fast, that's great news!
If so, and if the algorithm is fast, that's great news!
I meant there were no artifacts that were not hidden by the proper use of dither at the 24 bit level ~ -140dB. The numerical resolution of FFT <> IFFT with 64 bit floats is around -280 to -300 dB.
You might find some good articles linked at the Brutefir site. A properly done overlap and add FFT convolution gives exactly the same answer as the direct method. The time and frequency domain information are exact complements. You need care in padding the FFT because FFT convolution is circular.
Here's a plot I just did (Pano this is the FIR file I sent you) of 30 - 1/3 octave spaced tones that were inverse RIAA equalized and FIR filtered with Sox's fir command. The FIR was ~6000 points 32 bit floats normalized to 1. The results if blown up were +-.0005dB. I was a little sloppy in trimming the impulse response it might only take 4000 or so points to get < 1/2 lsb at 24bits.
EDIT - that's dB on the left axis, no spurs just the dither noise at ~-140dB also PYTHON has an arbitrary n FFT so no windowing is required, integer frequencies are automatically in exact bins at 96000 sample rate.
EDIT - that's dB on the left axis, no spurs just the dither noise at ~-140dB also PYTHON has an arbitrary n FFT so no windowing is required, integer frequencies are automatically in exact bins at 96000 sample rate.
Attachments
Last edited:
pos - Amazing what knowledgeable people like you are able to accomplish.
Beginners like me should probably not make suggestions, but I never listen to my own advices so here we go.
Documentation. I’m not sure you realize that in many ways you have already written most of the needed documentations? Some parts even repeatedly on different forums and threads when answering questions.
What I’m thinking. If you were to collect some of these and publish them as FAQ documentations? One could also start a Wiki page to hold this collection of answers, might even get maintained by power users and vendors?
Another one for the wish-list. This might or might not be easy to implement with copy/paste code?
I find myself zooming in and out a lot when working with -150dB graphs where I simultaneous need details at +5/-5dB
What if the where two plot screens? Both with different zoom settings (and disable check box if speed is an issue).
Could be implemented as Tab’s so only one are visible for low resolution screens.
Beginners like me should probably not make suggestions, but I never listen to my own advices so here we go.
Documentation. I’m not sure you realize that in many ways you have already written most of the needed documentations? Some parts even repeatedly on different forums and threads when answering questions.
What I’m thinking. If you were to collect some of these and publish them as FAQ documentations? One could also start a Wiki page to hold this collection of answers, might even get maintained by power users and vendors?
Another one for the wish-list. This might or might not be easy to implement with copy/paste code?
I find myself zooming in and out a lot when working with -150dB graphs where I simultaneous need details at +5/-5dB
What if the where two plot screens? Both with different zoom settings (and disable check box if speed is an issue).
Could be implemented as Tab’s so only one are visible for low resolution screens.