a short title stating object and behaviour (i.e. fluid.bufnmf~ crashing on large buffers)
I was testing the ReComMa and the CLI versions on a collection of audio files that had been normalized using the sox command line tool. These file caused the command line tools (for which ReaCoMa also uses) to throw an Floating Point Exception. This format is the default output for the sox tool, so I had to specify that it needs to store the file as wavpcm in order to use the files with fluid-sines etc.
I did not see it specified anywhere in the documentatin that this WAV format was mandatory for use with the fluid commandline tools, or did I miss it?
Would it be possible to have the fluid tools be able to support Extended WAV format, or if not, would it be wise to specify the required format in the documentation somewhere?
If you have the sox command available to generate a file that the tools will choke on, that would be very helpful for reproducing.
We use a third-party library that, as far as I know, is meant to be pretty accepting of many of the possible variations of wav files. If there’s a specific thing that makes it sad, I can pass this on (and document the problem in the meantime, as you say).
Dear @weefuzzy,
Thanks for the quick reply, and for the really existing FluCoMa project!
Here are two files that are processed with sox and Audacity. On my and a friends computer the soxnorm version fails, and the audacitynorm version works fine. (Using a link to the folder where the two files are shared, since new users can’t post more than one link):
Using the command shntool I saw that the differenct betwenn the two audio files linked above is that the audacity exported one is of format Microsoft WAV, and that the sox exported one is WAV Extensible format.
The sox command that makes it sad is the following:
sox MotFastForm_6.wav MotFastForm_6_soxnorm.wav norm -0.1
The sox command that makes it happy is:
sox MotFastForm_6.wav -t wavpcm MotFastForm_6_soxnorm.wav norm -0.1
Hope this is helpful, and please let me know if you need anything else in order to see where the problem is.
Just wanted to pop in and say that it’s always encouraging to hear people are using things you make Feel free to drop me a line if you have any questions about ReaCoMa @eirikblekesaune
Hi, confirmed. Not only is the extensible chunk not supported, but the mysterious and unhelpful error message is down to a terrible lapse in error checking.
Two issues on github, should you wish to track the progress of this. One for the poor error message, the other for documenting the lack of wav extensible support. I’ll see about possibly getting support added to the 3rd party library.
Feel free to drop me a line if you have any questions about ReaCoMa