dlib
dlib copied to clipboard
davisking
stft(), istft(), stftr() and istftr()
This is a branch of special_math. Hence why all the commit messages on that branch are appearing. Wasn't expecting that.
@davisking I think we should probably support 2D input, for example stereo audio channel. But then the STFT is 3D and of course matrix is 2D. Maybe the API is fine for now. If people want to STFT multiple audio channels, just loop over the channels and concatenate the STFTs in a std::vector. Any opinions or advice?
@davisking I think we should probably support 2D input, for example stereo audio channel. But then the STFT is 3D and of course
matrixis 2D. Maybe the API is fine for now. If people want to STFT multiple audio channels, just loop over the channels and concatenate the STFTs in astd::vector. Any opinions or advice?
Na, I don't any different ideas about it :shrug:
@davisking So the main thing is that stft and co require a window type. In my view, the best way to specify that is via an enum. In which case you have to wrap all the other window function with window(). If you have a better idea then I'm all ears. We shouldn't encourage users to use window(), I agree, they should use the specific window functions. However, in my view it's required for the implementation details of stft(). And I think other users might benefit from it too hence why it's in the API.
The other thing is the accuracy of cyl_bessel_i() which determines the accuracy of kaiser(). I've opted for a MUCH simpler implementation but it comes at the cost of some accuracy. IF however you compile with C++17 or a compiler that defines __cpp_lib_math_special_functions, then you use the standard library implementation for free and you get all the accuracy you need. I think this is better than porting 1500 lines of boost code that NOBODY understands except for maybe 2 people on this planet.
~~STFTs using kaiser window are now MUCH slower. I don't understand. I think it has something to do with the window now being a function object as opposed to enum. Or maybe I'm doing something dumb. @davisking Some help in identifying the slowdown would be great.~~
Scrap that. Found it. Before, default window arguments were being passed to the STFT functions. For kaiser, that meant a beta value of 0. That means kaiser() was calling cyl_bessel_i(0,0), which returns 1 directly and does not compute the sum expression in cyl_bessel_i(). Now, user has to pass something like kaiser_window{attenuation_t{60.0}} to the STFT functions. That's where the slow down is because it's actually having to compute the sum in kaiser(). So everything is working as it should be.
Note that you don't have to use a kaiser window for STFTs to work and be invertible. a Hann window works just as well and is much faster. All the window functions are there for completeness. Though I'm sure some ancient DSP expert would argue that for some set of circumstances, a Kaiser window is desirable. (It definitely is when doing filter design, but STFTs don't use filter per se)
I'll wait until master is updated with the C++14 stuff then I'll merge and this should pass the tests I think
I've made a basic change to the cmake scripts to enable C++14. Hopefully the tests will pass. I've noticed though that dlib is using pretty old cmake code and maybe it's time to modernise it to maybe 3.10.
Lol. CI really didn't like my cmake change
but i just compiled once, i will go ahead and check if its my setup or the code. just an FYI for now
or works with c++14 but not with c++17 or c++20. pre this change dlib with c++17 was no issue at all
@VisionEp1 What's your system? Tried on Godbold with MSVC and it works: https://godbolt.org/z/qzcKEacdW EDIT: actually it only works with v19.latest. Curious. I hate windows
Maybe you are using something older than Visual Studio 2019 @VisionEp1? I just the other day changed the CI to use only VS 2019 and newer since github actions started warning me about the older setups they have being deprecated :|