Breaking change (allow old behavior? (sfm & fftparams))

[rconstanzo]

After a bit of troubleshooting this morning I figured out why some old code (in C-C-Combine) wasn't working properly. The first part of this is that sfm now reports in dB, which is more useful, but not the same as before, and not the same as what the documentation says at the moment("a value between 0 1 - 1 indicates a very flat spectrum and hence more noisy..."). I think dB is a more useful metric here, and in my patch I was doing some atodb stuff with clamping to remove INFs, but maybe having an option to revert to old behavior (or at least stating the new behavior in the documentation) would be useful.

After going to reanalyze my files with this in mind I was greeted with a console window full of descriptors~: zero length file or segment. It seems that the updated version takes the fftparams as a minimum segment length so if I send descriptors~ a message of analyze buffer 1 0. 40. with fftparams 2048 128 (@44.1k) I get the zero length file or segment error. If I change my message to analyze buffer 1. 0. 46.44 then it works properly. This makes logical sense as that is how big that segment needs to be for the fftparams to analyze a full frame, but it does break existing patches as this was not clamped previously. I don't know if the previous version just zero-padded the end of something, but it did return values.

I can easily change my local code to take this in mind, but mainly thing that there's quite a bit of this code out there in the world which will no longer work.