The time resolution of the IR is the soundcard sampling rate. The S/N is determined by the sweep length -> longer sweep means more energy in the stimulus. Neither affect CSD in the way you would want, the time resolution of a CSD is increased by using a shorter IR window, whilst the frequency resolution is increased by using a longer window. Have to choose your tradeoff there.David_Web said:
I was playing around with HOLM impulse a bit more and noticed the following:
1. For DAC-ADC calibration, if a make it using the MAKE function, then the calibration works, if I import the calibration data by first making a measurement -> export to HOLMImpulse calibration file, then import it and activate it, then the calibration file will not work. When I export, I used the full data range.
2. HOLMImpulse uses only one input and one output. This becomes a problem if different amplifiers are used if calibration is not redone. Probably most software that I have used takes one input as the reference, and the other input as the data. This way amplifier performance is removed from the measurement factor. Normally, amplifier response can be effected by speaker impedance. I have not compared how much difference it makes yet. I just think this imposes some uncertain factor in the measurement result.
3. When moving the cursor around the frequency response screen, the values displayed is the cusor value instead of the measured data. Is is more desireable to see the measured data.
1. For DAC-ADC calibration, if a make it using the MAKE function, then the calibration works, if I import the calibration data by first making a measurement -> export to HOLMImpulse calibration file, then import it and activate it, then the calibration file will not work. When I export, I used the full data range.
2. HOLMImpulse uses only one input and one output. This becomes a problem if different amplifiers are used if calibration is not redone. Probably most software that I have used takes one input as the reference, and the other input as the data. This way amplifier performance is removed from the measurement factor. Normally, amplifier response can be effected by speaker impedance. I have not compared how much difference it makes yet. I just think this imposes some uncertain factor in the measurement result.
3. When moving the cursor around the frequency response screen, the values displayed is the cusor value instead of the measured data. Is is more desireable to see the measured data.
soongsc said:
You can use 2 outputs, I do. But you're right, only one input - or mono.
Other software does allow you to compare 2 signals so that you can subtract the response of an amp, for example. But is that a good thing? Shouldn't the amp and speaker together be considered? Maybe it depends on what you want to do.
You could do the calibration thru the amp into a resistor to eliminate the nominal amp response, right? Of course it would be interesting to compare the two.
If basically, the amp response is effected by the driver because the driver is not a constant resistive load. Stereophile has measured effects of speaker load on amplifier response. For pure DIY, if we will never change the amplifier, then it probably would be fine to measure without removing the amplifier response effects.panomaniac said:
panomaniac said:
I made this point earlier and I think that it would be a good thing. The software now stores the output signal internally and uses that in its cross correlation. If it simply used the second input channel to record that signal, as it actually appears at the input to the speaker, then a better measurement of the speaker could be obtained because it would not include anything else in the path except the speaker. Even if the amp had poor frequency response or distortion, it would be ignored (I believe this is true, but I'd have to consider it in detail). This would then give a true SPL per volt measurement without having to consider the gain of the amp.
panomaniac said:Of course they are 2 different things. The repsonse of the speaker and the response of the speaker on a particular amplifier.
Both are good to know. Let's hope they are not too different!
I'd say if they are different then there is a problem. Mostly with Tube amps there is a significant difference, the tube amp usually having a very high output impedance. But this should be accounted for in the speaker design.
New Release
Hi folks!
I read all your post and prioritize.
What's new
ChangeLog.txt
Some of your requests have been implemented
Your reported bugs have been fixed
Version 1.2.0.0 (2009-06-29)
Features/Changes:
* New layout (Extra tab: 'Data analysis')
* Fade in/out in milliseconds
* Saving signals: Extend with zeroes when saving inverse signal
* Save the correlation to wave-file when measuring (Optional)
* Adjustable output level: -40 -> 0 dBFS
* Time-alignment - (Lock Time zero feature)
* Impulse domain: Autozoom and zoomout improved
* Response data analysis improved (Faster)
* Export Impulse: From/To samples are not reset when exporting again
* Stored in options: Save Wave files option
* Stored in options: Save Wave files filenames
* Stored in options: Chirp start freq and potens
* Stored in options: SQ-noise
Bugfixes:
* Sometimes options was not stored because form was destroyed before saving
* Impulse domain: Selected unit (distance, samples, time) was not saved
* Inverse signal: Saved waveform was time-reversed
* Time window: Disable auto apply window really does not apply any window now
* Time window: Is not locked when reopening measurement
NB:
* Not all old settings are migrated to this version
Known bugs and feature requests
Issues.txt This online document is a list of feature requests and known bugs. When you come up with an idea I add it to this list if I find the feature useful. E.g. your request for saving the impulse as wave-files learned me a lot.
HOLMImpulse FEATURE REQUESTS (Prioritized)
* Improve internal measurement saving method (Use impulse instead of frequency)
* Obtain static FadeIn/fadeOut values logsweep+chirp (Need further investigation)
* Offset times in samples/cm/msec (Now only in samples)
* Time window autodetect - Improve time window start
* Time window autodetect - Improve time window when using other timeoffset
* Time zero autodetect - Allow on existing measurements
* Move time offset with mouse in impulse domain
* Absolute gain (calibration dependent)
* Help as HTML pages
* Variable frequency end when using chirp and logsweep (Now only samplerate/2)
* Classical timewindows: Blackman, Hanning,...
* Measurement info: samplerate, length,...
* Open DUT-response as recorded wave-file then correlate afterwards
* Step response calculation from impulse response
* Protect Measurement causing popup when clear
* Cumulative spectral decay (CSD) 3D graph
* Variable number of slots
* Mixer Level-Adjust-Wizard
* Save settings to log-file at WARNING level (To improve support)
* Adjust latency for the soundcard (PortAudio)
* Show curve values instead of coordinates
* Show the recorded signal as wave-form
Hi folks!
I read all your post and prioritize.
What's new
ChangeLog.txt
Some of your requests have been implemented
Your reported bugs have been fixed
Version 1.2.0.0 (2009-06-29)
Features/Changes:
* New layout (Extra tab: 'Data analysis')
* Fade in/out in milliseconds
* Saving signals: Extend with zeroes when saving inverse signal
* Save the correlation to wave-file when measuring (Optional)
* Adjustable output level: -40 -> 0 dBFS
* Time-alignment - (Lock Time zero feature)
* Impulse domain: Autozoom and zoomout improved
* Response data analysis improved (Faster)
* Export Impulse: From/To samples are not reset when exporting again
* Stored in options: Save Wave files option
* Stored in options: Save Wave files filenames
* Stored in options: Chirp start freq and potens
* Stored in options: SQ-noise
Bugfixes:
* Sometimes options was not stored because form was destroyed before saving
* Impulse domain: Selected unit (distance, samples, time) was not saved
* Inverse signal: Saved waveform was time-reversed
* Time window: Disable auto apply window really does not apply any window now
* Time window: Is not locked when reopening measurement
NB:
* Not all old settings are migrated to this version
Known bugs and feature requests
Issues.txt This online document is a list of feature requests and known bugs. When you come up with an idea I add it to this list if I find the feature useful. E.g. your request for saving the impulse as wave-files learned me a lot.
HOLMImpulse FEATURE REQUESTS (Prioritized)
* Improve internal measurement saving method (Use impulse instead of frequency)
* Obtain static FadeIn/fadeOut values logsweep+chirp (Need further investigation)
* Offset times in samples/cm/msec (Now only in samples)
* Time window autodetect - Improve time window start
* Time window autodetect - Improve time window when using other timeoffset
* Time zero autodetect - Allow on existing measurements
* Move time offset with mouse in impulse domain
* Absolute gain (calibration dependent)
* Help as HTML pages
* Variable frequency end when using chirp and logsweep (Now only samplerate/2)
* Classical timewindows: Blackman, Hanning,...
* Measurement info: samplerate, length,...
* Open DUT-response as recorded wave-file then correlate afterwards
* Step response calculation from impulse response
* Protect Measurement causing popup when clear
* Cumulative spectral decay (CSD) 3D graph
* Variable number of slots
* Mixer Level-Adjust-Wizard
* Save settings to log-file at WARNING level (To improve support)
* Adjust latency for the soundcard (PortAudio)
* Show curve values instead of coordinates
* Show the recorded signal as wave-form
Feedback
I need your help
I need your help
- SSE2 - The SSE2 version is running slightly faster.
Does any of you NOT use the SSE2 version?
(My point is, that if every "modern" pc has a SSE2 FPU then there is no reason for making two versions)
- Vista 64 bit. Earl, I know that you are using Vista 64 bit - does this 32 bit version run on a 64 bit Vista?
- Convolution in Audition did not work for me (I used 30 min and gave up...), Klaus how do you convolve in Audition?
(Notice the bugfix in 1.2.0.0: Inverse signal: Saved waveform was time-reversed which was discovered by you and that was why I got garbage convolving. Sorry...
Re: Using wav files
Not at all stupid.
http://www.holmacoustics.com/downloads/HOLMImpulse/Issues.txt
+-----------------------------------------------------------------------+
HOLMImpulse FEATURE REQUESTS
+-----------------------------------------------------------------------+
* Open DUT-response as recorded wave-file then correlate afterwards
This feature is very important. It will give us the possibility to measure the response from CD-players, tape recorders, mp3-encoders, vinyl records... Simply
1. save the signal to wave-file
2. Transform to new media
3. Play and Record using eg. Audacity
4. Import to HOLMImpulse
Theo404 said:
Not at all stupid.
http://www.holmacoustics.com/downloads/HOLMImpulse/Issues.txt
+-----------------------------------------------------------------------+
HOLMImpulse FEATURE REQUESTS
+-----------------------------------------------------------------------+
* Open DUT-response as recorded wave-file then correlate afterwards
This feature is very important. It will give us the possibility to measure the response from CD-players, tape recorders, mp3-encoders, vinyl records... Simply
1. save the signal to wave-file
2. Transform to new media
3. Play and Record using eg. Audacity
4. Import to HOLMImpulse
>> Convolution in Audition did not work for me (I used 30 min
>> and gave up...), Klaus how do you convolve in Audition?
What can I say, as I don't have any problems.
Procedure is
- load impulse response (setup Audtion to always render to float) and select all or the needed part of it
- invoke the convolver to load the kernel
- - clear any previous loaded kernel
- - add the pulse, using the appropriate scaling. For impulses this should be 1, for other data (like the inverse) an estimate is given, I came to use x10 the value when convolving with the inverse
-- don't press "OK" (this will convolve the kernel with itself), press "close"
- load the data to be convolved
- invoke the convolver again, this time only pressing OK, to convolve with the already loaded kernel.
Problems: the kernel is restricted in length, in my system it cannot be greater than about 220000 samples, which limits for example usable sweep time to about 5 secs at 44.1k
Workaround/Upgrade: use "lsconv" (and "glsweep" too) from the free DRC-package, there is a ditribution with W32-binaries available. Together with the very mighty "sox" audio-tool (also W32-Versions, free) you have a nice toolset for the sweep, its inverse and for arbitrary convolution tasks. This would make your/other SW more or less unneccesary (or better said: an integrated alternative) for the task of generating proper IR's if you have some record-while-playback capabilities (under linux no deal, with windows its a bit tricky on the cmd-line level).
http://drc-fir.sourceforge.net/
http://sox.sourceforge.net/
Some parametrization would likely to be necessary for an arbitrary IR import option in HOLMI for the use of its postprocessing, especially I can think of the active sweep length and start/stop freqs. Is the IR restricted to powers of two, in your software (or would you just pad zeros if it is not?).
- Klaus
>> and gave up...), Klaus how do you convolve in Audition?
What can I say, as I don't have any problems.
Procedure is
- load impulse response (setup Audtion to always render to float) and select all or the needed part of it
- invoke the convolver to load the kernel
- - clear any previous loaded kernel
- - add the pulse, using the appropriate scaling. For impulses this should be 1, for other data (like the inverse) an estimate is given, I came to use x10 the value when convolving with the inverse
-- don't press "OK" (this will convolve the kernel with itself), press "close"
- load the data to be convolved
- invoke the convolver again, this time only pressing OK, to convolve with the already loaded kernel.
Problems: the kernel is restricted in length, in my system it cannot be greater than about 220000 samples, which limits for example usable sweep time to about 5 secs at 44.1k
Workaround/Upgrade: use "lsconv" (and "glsweep" too) from the free DRC-package, there is a ditribution with W32-binaries available. Together with the very mighty "sox" audio-tool (also W32-Versions, free) you have a nice toolset for the sweep, its inverse and for arbitrary convolution tasks. This would make your/other SW more or less unneccesary (or better said: an integrated alternative) for the task of generating proper IR's if you have some record-while-playback capabilities (under linux no deal, with windows its a bit tricky on the cmd-line level).
http://drc-fir.sourceforge.net/
http://sox.sourceforge.net/
Some parametrization would likely to be necessary for an arbitrary IR import option in HOLMI for the use of its postprocessing, especially I can think of the active sweep length and start/stop freqs. Is the IR restricted to powers of two, in your software (or would you just pad zeros if it is not?).
- Klaus
Convolution
HOLMImpulse does of course the convolution, it is a pure sanity check of the wave-files I save. It's nice to verify by other software that my inverse is correct using their convolution. I'll try to verify some day.
I could easily make cmd-like applications
inverse <file.wav> <inversefile.wav>
convolve <file1.wav> <file2.wav> <result.wav>
Would that be of any interest?
KSTR said:
HOLMImpulse does of course the convolution, it is a pure sanity check of the wave-files I save. It's nice to verify by other software that my inverse is correct using their convolution. I'll try to verify some day.
I could easily make cmd-like applications
inverse <file.wav> <inversefile.wav>
convolve <file1.wav> <file2.wav> <result.wav>
Would that be of any interest?
If it is equally good as the DRC tools and less complicated in handling as those (they are working on raw headerless 32bit floats, you need other SW like "sox" to convert from/to .WAV)), it for sure will be appreciated. Even more so would be a simple standalone record-while-playback tool, using the default devices
We are getting more and more to an open system approach, which I think is a very good idea for people wanting to use the SW in more ways than the basic self-contained standalone operation with a nice GUI, which of course is the simplest and most convenient way of usage for like 90% of the users.
- Klaus
We are getting more and more to an open system approach, which I think is a very good idea for people wanting to use the SW in more ways than the basic self-contained standalone operation with a nice GUI, which of course is the simplest and most convenient way of usage for like 90% of the users.
- Klaus
Re: Feedback
When you say "This 32-bit version" what do you mean. The version that I have from last week runs fine in 64-bit Vista.
If I could make one more request. In the save impulse as ASCII, could the header be turned off.
What I do that is kind of a pain in your software is polar response. I take a measurement and then save the impulse, rotate table, take measurement again, etc. The ideal would be to store each impulse response and then write out an array of impulse responses (length by # of angles) - what a God-send THAT would be!!! A single file with all the data!!
askbojesen said:
When you say "This 32-bit version" what do you mean. The version that I have from last week runs fine in 64-bit Vista.
If I could make one more request. In the save impulse as ASCII, could the header be turned off.
What I do that is kind of a pain in your software is polar response. I take a measurement and then save the impulse, rotate table, take measurement again, etc. The ideal would be to store each impulse response and then write out an array of impulse responses (length by # of angles) - what a God-send THAT would be!!! A single file with all the data!!
Block Export to textfile
So what do you want here?
Let us say we have some measurements in slot 0-49
Then you want to save frequency domain, or impulse domain
Frequency domain block export to text-file
A text files with the following columns:
Frequency | dB[0] | phase[0] | dB[1] | phase[1] | dB[2] | phase[2] | ...
Impulse domain block export to text-file
A text files with the following columns:
Sample number | Imp[0] | Imp[1] | Imp[2] ....
or ?
So what do you want here?
Let us say we have some measurements in slot 0-49
Then you want to save frequency domain, or impulse domain
Frequency domain block export to text-file
A text files with the following columns:
Frequency | dB[0] | phase[0] | dB[1] | phase[1] | dB[2] | phase[2] | ...
Impulse domain block export to text-file
A text files with the following columns:
Sample number | Imp[0] | Imp[1] | Imp[2] ....
or ?
Re: Block Export to textfile
The last one is almost perfect, except for sample #. My software does not like to read an array with different data types. It has no problem with any array of the same data type, but when the impulse data is say 32 bit float and the sample # is integer, then it doesn't like that. If the header contains the sample rate and the start sample # the rest is trivial and redundent
Ask - thanks for all your support. Your software is getting really good.
Maybe someday we should talk about you implimenting a different nonlinear distortion metric - one that actually has some meaning, unlike THD and the like.
On that subject, I have looked at the impulse responses for the harmonics and after the second, sometimes the third they basically all look like noise. How do you determine when these impulse start (I'm guessing samples / (2 * order) somthing like that) and how do you determine what's just noise and what's real data? If you just go to the location and then window and plot the data, I seriously doubt that these numbers have any meaning.
As with every system that I have looked at, the numbers for the higher orders get less and less reliable just as they are getting more and more perceptionally important. This is a real problem.
In another "nameless" system, a guage R&R study was done on the higher order terms. It was found that only the second was always reliable, sometimes the third, but beyond that they were all basically random. It's one thing to print the numbers and quite another to show that they have any significance.
askbojesen said:
The last one is almost perfect, except for sample #. My software does not like to read an array with different data types. It has no problem with any array of the same data type, but when the impulse data is say 32 bit float and the sample # is integer, then it doesn't like that. If the header contains the sample rate and the start sample # the rest is trivial and redundent
Ask - thanks for all your support. Your software is getting really good.
Maybe someday we should talk about you implimenting a different nonlinear distortion metric - one that actually has some meaning, unlike THD and the like.
On that subject, I have looked at the impulse responses for the harmonics and after the second, sometimes the third they basically all look like noise. How do you determine when these impulse start (I'm guessing samples / (2 * order) somthing like that) and how do you determine what's just noise and what's real data? If you just go to the location and then window and plot the data, I seriously doubt that these numbers have any meaning.
As with every system that I have looked at, the numbers for the higher orders get less and less reliable just as they are getting more and more perceptionally important. This is a real problem.
In another "nameless" system, a guage R&R study was done on the higher order terms. It was found that only the second was always reliable, sometimes the third, but beyond that they were all basically random. It's one thing to print the numbers and quite another to show that they have any significance.