Hello Peter, thanks for your friendly and appreciative feedback! You are correct: for your use-case it would be sufficient to just have the input and the gain effect toughened up for floating point processing. The latter is trivial (you don't even have to change the code there in my opinion), the former should also be okay (since it handles floats by default), but unfortunately all the communication between the different modules in SoX is done via samples in _integer format_ and also the modules themselves use that as a fundamental type. So one has to change the internal and overall sample type sox_sample_t from int32 to float or double and then recompile _the whole system_ and see what happens. I haven't tried it yet, but my gut feeling is that there are a lot of type incompatibilities due to the initial design decision that samples are integers. As Måns has already pointed out: in principle an overall change to floating point would be extremely helpful. Gain staging would be completely unnecessary, because floats can handle very small and large sample values without a problem (and hence there would be no more "XXX samples clipped" messages). Because I had the urgent need, I did this reimplementation some time ago for a selected set of SoX audio effects, but I used C++ instead of C and even then it was somewhat tedious. And of course, I did not even touch the file format stuff at all, because this was not required for a DAW plugin (which gets its audio input from the DAW as a double or float sample stream and produces the same format as its output). So again: if there is some interest in a renovation of SoX, I offer to help. But I am not sure whether SoX is just some nerdy audio tool for a small community and the effort is futile?! Best regards, Thomas _______________________________________________ Sox-users mailing list Sox-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/sox-users
