It would take one character change but then it wouldn't read the other format. The best option is to try and find a good open source .wav file reader that is compatible.
If we restricted the files to 16bit I think there is no problem BTW. This would not matter for our problem at all.
Even 8 bit would work, but would have no processing advantage in Python.
Stick to 16 bit 44100 or lower sampling rate.
So then if we restrict input files to 16 bit the built-in .wav reader should work. For the FFT's etc. the numbers are all converted to floats anyway. You can force everything to use 32bit floats but I don't know if that saves any time.
I think that's the way to fly for now, and removes a step of Sox conversion. Of course, Sox or audacity etc etc could still be used to convert pretty much any file format to 16 bit wav.
My vote is to standardise on 44.1/16 2 channel, until or unless Python gets sorted or someone finds or writes a compatible audio file handler. That's not much of an imposition, methinks.
LD
I should confirm, for the purpose of putting up files for analysis using my polar plot SW, pretty much any lossless file format, sample rate, bit depth or level is fine. Stereo or mono is fine, and pretty much any tone frequency for that matter.....
LD
LD
My bad, Scipy has it's own .wav reader distinct from the built-in one, we might be able to obviate all this file format worry. I will explore this today.
OK, the packed 24bit integer format is still not supported but 16bit int, 32bit int, and 32 bit normalized floats all seem to work fine. So I will change the code to eliminate the file conversion step with the caveat that some recorders use the 24bit packed format to save space recording 24bit audio and software converts them to 32bit float for editing so it might go unnoticed to the user.
Certainly if we stick with LD's recommendation we will be done with this. BTW the sample rate is also returned by the read function.
Certainly if we stick with LD's recommendation we will be done with this. BTW the sample rate is also returned by the read function.
Last edited:
Yes, but Audacity or any other program can do this, just open and resave no more headers etc. to edit. I don't know of any recorder that can't be told to use 16bit, just that like most folks for making recordings to edit I always have 24bit as a default.
I spent a day once doing a 24bit read/write in C including support for big or little endian words, It is not that hard and I guess the Python community needs one hard core audio geek to do it. It involves reading in 8bits at a time and reassembling/disassembling the data into even byte containers with some shuffling.
Last edited:
Here is an update, mono and stereo (first channel) .wav files work in 16bit int, 32bit int, and normalised 32bit float format. 24bit and some other esoteric floating point formats may not work (24bit for sure does not work). To be safe just use 16bit at any sampling rate (files need to be >=4sec). No resolution at all is lost at 16bit.
Thanks Scott. 
Now I just have to figure out how to invoke the python handler in OSX, or maybe Windoze 10. Never run a script before.
Now I just have to figure out how to invoke the python handler in OSX, or maybe Windoze 10. Never run a script before.
Thanks Scott.
Go to the Anaconda site there should be a guide. Things are easier from idle which is a very simple environment to run scripts. Anaconda installs idle and under Win10 you just type idle in a command window, open the script, and press F5 (run). You do need to put the stuff from my LA article where Python finds it, I will try to eliminate this step.
Last edited:
It would help non-programming users to include the defs from your Linear_Audio library directly in the code.
Also for some users a prompt for the wav file name rather than editing might be simpler.
It's a lot easier to use the code in Ubuntu than Windows
Also for some users a prompt for the wav file name rather than editing might be simpler.
It's a lot easier to use the code in Ubuntu than Windows
For the same reason changing over to Python's IIR filters will probably also speed things up even more. The other idea is good, the only thing better would be a drag and drop. I'm working on the filters today (looks easy).
For ultimate speed up of filters, remove them! They're not needed, no compromise.
LD
Late again, but that spectrum plot looks very close to the actually measured spectrum on my Kuzma. The plot with the mains sidebands is ex-factory, for the cleaner plot we tuned the AC motor phase shift capacitor. Worth.
Jan
