I am honored šššI knew responding was a bad idea but I did it anyway, silly me. That situation is now rectified and you hold the bronze medal position on my ignore list.
Strange response after not coming back with just arguments?
With most, you mean most people?Dependās on the Audio Interface and particularly the desired input for that Audio Interface. Notably most will want the by-passed input that does not offer attenuation.
Can you explain why an attenuator would be a bad idea?
I may very well be misunderstanding what you are saying here, but we do need Octave (or similar software) for the mathematics and processing of the "raw" data since REW, ARTA, HOLMimpulse and other measurement suites don't have the ability to perform modal analysis or sound field separation. So some kind of mathematics package or custom software is going to be necessary. But I do certainly agree that export to other programs is also necessary, after all, getting all the fancy data doesn't do me much good if I can't design a speaker with it.Tom is correct: export to other programs (modeling programās in particular) should be the priority. After that, sure Octave (for those that want to put in the extra development).
The choice of the software should be based on (i) what you want to do and (ii) what you like to work with. I won't comment on (ii) because that's different for everyone, but (i) means that conventional audio test packages like REW etc. won't work because they do not allow you to do the sound field separation.
I'm currently doing my stuff in Octave, mostly because SFS and MATAA are available and I'm familiar with matlab (of which Octave is a clone).
Python would have been another option as SFS is also available in python and although I don't know much Python I seem to get things done. Kudos to python.
All I want to do is give people a choice how they do the measurements and how they do the postprocessing. I've imported manual angular measurements done using REW into Octave as test data for 2D model fitting and reevaluation. Now I can take automated measurements in Octave, but would like to use REW as a UI to see what I got. Later I hope to measure in Octave and process in Octave (2D) and (much) later full 3D SFS if we get the hardware in place.
Python would have been another option as SFS is also available in python and although I don't know much Python I seem to get things done. Kudos to python.
All I want to do is give people a choice how they do the measurements and how they do the postprocessing. I've imported manual angular measurements done using REW into Octave as test data for 2D model fitting and reevaluation. Now I can take automated measurements in Octave, but would like to use REW as a UI to see what I got. Later I hope to measure in Octave and process in Octave (2D) and (much) later full 3D SFS if we get the hardware in place.
Not sure. Can share a minimal code example?@mbrennwa : any idea what I'm doing wrong?
Not at the moment. Full code is in GitHub: https://github.com/TomKamphuys/Audio/blob/main/angular_measurement.m
I tried fade in, fade out. REW seems to use that. I tried continuing to the Nyquist frequency and putting zeros from the last zero crossing onwards. All to no avail.
I tried fade in, fade out. REW seems to use that. I tried continuing to the Nyquist frequency and putting zeros from the last zero crossing onwards. All to no avail.
It goes through the preamp section which often isnāt linear.With most, you mean most people?
Can you explain why an attenuator would be a bad idea?
preamp of the mic itself or audio interface?It goes through the preamp section which often isnāt linear.
I usually see pre-ringing explained as resulting from the type of filtering applied. Here's a synopsis from Sound on Sound:
Pre-ringing
Pre-ringing refers to an inherent character of the impulse response of linear-phase filters employed in D-A or A-D converters. In a conventional analogue or minimum phase filter, an input impulse signal will generate an output impulse response with a strong initial spike followed by a string of ripples of decrasing magnitude. In a linear-phase filter the impulse spike is preceded by a build-up of ripples in advance of the impulse arriving, and a symmetrical string of decaying ripples afterwards.
Might there be different filtering buried somewhere in the two processes?
Few
Many of us old guys like a GUI. And that is not exactly available in Octave/Matlab.What's wrong with keeping the data in Octave for automated processing and plotting? I feel that's 1000x more convenient than exporting the data to many files, importing each file to some other software, and process each and every file there, possibly manually.
A GUI can be added, if/where needed and suitable.Many of us old guys like a GUI. And that is not exactly available in Octave/Matlab.
Audio Interface.preamp of the mic itself or audio interface?
ex. the excellent id24 that fluid just purchased:
After getting the āmassagedā/processed data. (That data is not what I think of with respect to post-processing.)..getting all the fancy data doesn't do me much good if I can't design a speaker with it.
What happens if you use an MLS or pink noise instead of the sweep?
What happens if you don't use loopback?
What happens if you don't use a calfile on line 41?
MLS : pre ringing present
no loopback : different, but still looks like ringing
no calfile : pre ringing present
Tom one thing you can do to look at it in REW is to change the window settings to only look at the response before the peak. By looking at the frequency response or filtering the IR you can see the spectrum of the preringing. If it is an antialias filter or similar linear phase induced bandwith limit it should show around the Nyquist frequency.
I have seen a similar thing in REW when the timing is slightly off from where it thinks it should be. You can manually change the T=0 time and see if it changes anything.
I have seen a similar thing in REW when the timing is slightly off from where it thinks it should be. You can manually change the T=0 time and see if it changes anything.
Please try using the mataa_measure_signal_response(...) function for audio I/O instead of the mataa_measure_IR(...) so you can take a look at the data you get from the microphone and from the loopback channel. Check for things like clipping or cutoff at the beginning or end of the signals, or other undesired effects.no loopback : different, but still looks like ringing
- Home
- Design & Build
- Software Tools
- Klippel Near Field Scanner on a Shoestring