KSTR said:
I really don't see this as a "problem", the inverse of a sequence is uniquely defined. When not using the inverse you will introduce artifacts. I will rather LP, HP the result.
We really need a numerical example to justify the faded inverses used by DRC and others. I have tried several transfer functions that all validates my method
- Power expansion like y = 0.5x + 0.1x^2 + 0.2x^3 + 0.1x^4 +...
- Clipping to amplitude en after multiplied buy 1.25
- Introducing echoes y = 0.5x + 0.2x[i-100] - 0.2x[i-1000]
My problem is that they use intuitive arguments for fading the inverse. We need a transfer function / filter that will prove that using the real inverse is not working.
Fade in/out is only beneficial for people using the Farina method to generate the inverse as it reduces the transients at the beginning/end that otherwise cause errors in deconvolution. When the inverse is derived from the FFT of the stimulus fading in/out offers only cosmetic benefit, i.e. the FFT of the stimulus looks nicer and there is no possibility of an audible click at the end of a band limited sweep.
JohnPM said:
So you agree that fade in/out should be removed from HOLMImpulse?
(since I use FFT to create the exact inverse)
NB: When making LP/HP measurements in HOLMImpulse there is indirectly fading to the signal since the logsweep is convolved with a LP/HP FIR filter. The inverse is still the inverse of the full-range logsweep. Så the LP/HP is "simulating" a digital filter in the speaker.
JohnPM said:
Yes I get the idea now. so when I start the unfaded logsweep at 10 Hz, then I in fact start it at let us say 8 Hz and fade in. The real logsweep will still have a length of 2^N then extended with in-out-tfading. I might try this. Right now I have now frequency end - sweeping to Fs, so outfade is not relevant.
New Release 1.2.0.2
First, thanks for this great software. I find it works very well and has (I think) an intuitive interface. After struggling to perform measurements with SpeakerWorkshop for several years this is a huge improvement.
Unfortunately, one of the two machines I use this on is a rather old desktop that does not include SSE2 (the other is an SSE2 enabled laptop). Thus I have what may seem to be a bit of an odd request. I downloaded the latest version and of course it does not work on my non SSE2 enabled desktop. Unless there is some way to make the new version run on my ancient hardware, I would really appreciate it if someone could please send me the install file for the previous version so that I could at least continue to use the desktop for measurements until I upgrade this machine in the fall. TIA
Again, thanks for a really intriguing and useful piece of software!
First, thanks for this great software. I find it works very well and has (I think) an intuitive interface. After struggling to perform measurements with SpeakerWorkshop for several years this is a huge improvement.
Unfortunately, one of the two machines I use this on is a rather old desktop that does not include SSE2 (the other is an SSE2 enabled laptop). Thus I have what may seem to be a bit of an odd request. I downloaded the latest version and of course it does not work on my non SSE2 enabled desktop. Unless there is some way to make the new version run on my ancient hardware, I would really appreciate it if someone could please send me the install file for the previous version so that I could at least continue to use the desktop for measurements until I upgrade this machine in the fall. TIA
Again, thanks for a really intriguing and useful piece of software!
SSE2
Previous without SSE2:
http://www.holmacoustics.com/downloads/HOLMImpulse/HOLMImpulse-1.2.0.0.msi
I'll introduce the specific SSE2 version again from 1.2.0.4
ilardi said:
Previous without SSE2:
http://www.holmacoustics.com/downloads/HOLMImpulse/HOLMImpulse-1.2.0.0.msi
I'll introduce the specific SSE2 version again from 1.2.0.4
Second! Have already used the software to great effect (I enjoy it so much more than arta) with single drivers, but this would be icing on the cake.
Can I surmise from this that you have a (pre)alpha version with the capability?
gedlee said:
Please tell me this is not what you usually use for measurement (summas etc)?! Onboard sound on a $10 OEM motherboard?!?
http://www.holmacoustics.com/downloads/HOLMImpulse/ChangeLog.txt
Version 1.2.0.4 (2009-07-09)
Features/Changes:
* Frequency domain - Export "Extend phase when changing sign" option
* Impulse domain - Import as text file
* Impulse domain - Import as wave/flac/mp3/au-file
* Measuring: Extend to Nyquist frequency for nicer impulse view
* Autodetect SSE2 support from CPU identifier when autoupdating
Bugfixes:
* Frequency domain - Export Logarithmic was nearly nonsense
* Frequency domain - Export was allways PSpice format
* Frequency domain - Export as PSpice compatiable text-file
* Out of memory when zooming in on the graphs
Notes:
* SSE2-version is new reenabled
Known bugs:
* Crashes at signal length = 21
* Make Dac-Adc calibration does not work
Upcoming features
http://www.holmacoustics.com/downloads/HOLMImpulse/Issues.txt
Impulse domain - Import as wave/flac/mp3/au-file
I like this feature myself. I have made a test:
1. Play a Dirac sample at 44.1 kHz direct to a mid-driver (SS-15W)
2. Record the peak in Audacity
3. Save the waveform
4. Import waveform impulse into HOLMImpulse
5. Make measurement in HOLMImpulse direct to the mid-driver (SS-15W)
6. Compare
I know that in theory the impulses should be the same, but I had never expected them
to equal this much - you might not believe I have actually made the test. It is good that I have consistency, but I'm left with the
question why I'm using logsweep when I can measure everything in just one sample... I know: S/N ratio, Harmonic distortion, ...
But it does take the technicalities out of measuring - everybody with a brain can understand that if a Dirac is on a CD, then the driver plays a peak, not a Dirac. so what comes out of the speaker and into your ear is not what is on the CD.
Version 1.2.0.4 (2009-07-09)
Features/Changes:
* Frequency domain - Export "Extend phase when changing sign" option
* Impulse domain - Import as text file
* Impulse domain - Import as wave/flac/mp3/au-file
* Measuring: Extend to Nyquist frequency for nicer impulse view
* Autodetect SSE2 support from CPU identifier when autoupdating
Bugfixes:
* Frequency domain - Export Logarithmic was nearly nonsense
* Frequency domain - Export was allways PSpice format
* Frequency domain - Export as PSpice compatiable text-file
* Out of memory when zooming in on the graphs
Notes:
* SSE2-version is new reenabled
Known bugs:
* Crashes at signal length = 21
* Make Dac-Adc calibration does not work
Upcoming features
http://www.holmacoustics.com/downloads/HOLMImpulse/Issues.txt
Impulse domain - Import as wave/flac/mp3/au-file
I like this feature myself. I have made a test:
1. Play a Dirac sample at 44.1 kHz direct to a mid-driver (SS-15W)
2. Record the peak in Audacity
3. Save the waveform
4. Import waveform impulse into HOLMImpulse
5. Make measurement in HOLMImpulse direct to the mid-driver (SS-15W)
6. Compare
I know that in theory the impulses should be the same, but I had never expected them
to equal this much - you might not believe I have actually made the test. It is good that I have consistency, but I'm left with the
question why I'm using logsweep when I can measure everything in just one sample... I know: S/N ratio, Harmonic distortion, ...
But it does take the technicalities out of measuring - everybody with a brain can understand that if a Dirac is on a CD, then the driver plays a peak, not a Dirac. so what comes out of the speaker and into your ear is not what is on the CD.
Attachments
DUT response import
I think the most general DUT response import is:
1. Import the signal
2. Import the DUT response
3. zero-pad the signal and DUT-response to nearest 2^N length
4. Make the inverse signal and convolve
5. Locate the impulse peak
This way we can use any signal and any DUT. Then if we save the signal together with the DUT-response we always have the correct signal instead of being in doubt weather you started at 10Hz or if you had applied a filter to the signal or...
What do you people think?
KSTR said:
I think the most general DUT response import is:
1. Import the signal
2. Import the DUT response
3. zero-pad the signal and DUT-response to nearest 2^N length
4. Make the inverse signal and convolve
5. Locate the impulse peak
This way we can use any signal and any DUT. Then if we save the signal together with the DUT-response we always have the correct signal instead of being in doubt weather you started at 10Hz or if you had applied a filter to the signal or...
What do you people think?
Re: DUT response import
And with the complete import option as you plan it one could contercheck if the processing/DUT is really consistent with the linear superposition principle, that is if the chains
a) signal --> response --> user filter
b) signal --> user filter --> response
are identical in the basic response (but not in the S/N and in the distortion, that is obvoius). Which then yould be a nice check for the LTI-quality of the system under test, etc
- Klaus
This would really be the most flexible solution. However, with the new IR import feature (which really makes my day, Ask, BIG "THANK YOU"!) my most basic needs are fully satisfied for the moment... because your software evolves more and more into a very good (& simple to use) post-processing tool as well, besides the core functionality of measuring IR's. Like exporting an already measuerd IR, process it with some filter or what have you, import it back and compare etc. Exactly what I need right now, excellent!askbojesen said:
And with the complete import option as you plan it one could contercheck if the processing/DUT is really consistent with the linear superposition principle, that is if the chains
a) signal --> response --> user filter
b) signal --> user filter --> response
are identical in the basic response (but not in the S/N and in the distortion, that is obvoius). Which then yould be a nice check for the LTI-quality of the system under test, etc
- Klaus
Checked the IR import after applying some processing (convolution with a linphase-correction kernel), works!
I see that you don't display HD info so far, which makes sense since you cannot make any assumptions about the way the IR was generated.
This knowledge would also be a benefit of the the full blown import (or maybe a button would be an option that a round-trip export-import cycle was used and the setup parameters are still valid for that slot -- or the one it was copied to, whatever).
Anyway, this piece of software is on a constant route way up to the top!
- Klaus
I see that you don't display HD info so far, which makes sense since you cannot make any assumptions about the way the IR was generated.
This knowledge would also be a benefit of the the full blown import (or maybe a button would be an option that a round-trip export-import cycle was used and the setup parameters are still valid for that slot -- or the one it was copied to, whatever).
Anyway, this piece of software is on a constant route way up to the top!
- Klaus
Version 1.2.0.6 (2009-07-11)
Features/Changes:
* Static libsnd library (used for import and export of wavefiles)
Bugfixes:
* Moving time offset while lowpass or highpass currupted data
* No Wavefile type when exporting impulse as wavefile
* Memory error when reading Harmonic Distortion from saved measurement
* QBox manipulation
Notes:
* SSE2-version is not maintained, since the FFT-algorithms in fact was slower with SSE2 using the VC++ compiler
-------------------------------
- I got the "memory violation error during zoom-in on the IR" my self
using interpolated IR, but I'm not able to reproduce in 1.2.0.6
Features/Changes:
* Static libsnd library (used for import and export of wavefiles)
Bugfixes:
* Moving time offset while lowpass or highpass currupted data
* No Wavefile type when exporting impulse as wavefile
* Memory error when reading Harmonic Distortion from saved measurement
* QBox manipulation
Notes:
* SSE2-version is not maintained, since the FFT-algorithms in fact was slower with SSE2 using the VC++ compiler
-------------------------------
- I got the "memory violation error during zoom-in on the IR" my self
using interpolated IR, but I'm not able to reproduce in 1.2.0.6
Ask,
Problem seems to persist. Every time I shift the IR a little, using explicit values (say increase the IR sample offset by 5, and then back agan by -5, or when I use auto detect) the curves dissappear (FR mag and phase are still correctly displayed and updated). Relaunch of the prog fixes it, so no data seems to be corrupted, only the IR display goes mad. Also happens with original (non-imported) IRs. No crashes, only corrupted display when zooming in.
Settings: inter-sample Interpolation ON, splines ON
I work around that (when needed) with 4x oder 8x upsampling of the IRs and splines OFF, but this kills performance on my lowly PentiumIV/512MB sort of 5 sec response time for every single user action...
BTW, do the splines really render the "analog" shape of the IR like, for example, Audition does (I think they do "graphical upsampling", of sorts)?
Anyway, thanks four your quick reaction and all the efforts!
- Klaus
Problem seems to persist. Every time I shift the IR a little, using explicit values (say increase the IR sample offset by 5, and then back agan by -5, or when I use auto detect) the curves dissappear (FR mag and phase are still correctly displayed and updated). Relaunch of the prog fixes it, so no data seems to be corrupted, only the IR display goes mad. Also happens with original (non-imported) IRs. No crashes, only corrupted display when zooming in.
Settings: inter-sample Interpolation ON, splines ON
I work around that (when needed) with 4x oder 8x upsampling of the IRs and splines OFF, but this kills performance on my lowly PentiumIV/512MB sort of 5 sec response time for every single user action...
BTW, do the splines really render the "analog" shape of the IR like, for example, Audition does (I think they do "graphical upsampling", of sorts)?
Anyway, thanks four your quick reaction and all the efforts!
- Klaus
Bugfix
Bug fixed
Version 1.2.0.8 (2009-07-11)
Bugfixes:
* System.AccessViolationException: When zooming to IR after sample shifting (Was caused by ArrayCircShift function taking argurement by point reference)
http://www.holmacoustics.com/downloads/HOLMImpulse/ChangeLog.txt
This was an excellent error-report
The first step in fixing a bug is to reproduce the error thank you very much for the details
No.... I only use cubic-splines. Due to performance and effort.
Bug fixed
Version 1.2.0.8 (2009-07-11)
Bugfixes:
* System.AccessViolationException: When zooming to IR after sample shifting (Was caused by ArrayCircShift function taking argurement by point reference)
http://www.holmacoustics.com/downloads/HOLMImpulse/ChangeLog.txt
KSTR said:
This was an excellent error-report
The first step in fixing a bug is to reproduce the error thank you very much for the details
No.... I only use cubic-splines. Due to performance and effort.