New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug in FFT windowing #286
Comments
It's hard to say what to change, for accuracy I imagine you would want keep the window_length the same so this requires a higher fft order, however for speed you would want to keep the fft_order down which I imagine is how this incorrectness came about. I think the best solution is to do away with the windowing all together i.e. use the rectangular window as it's the widest |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
You windowing for the fft when calculating the mfccs is incorrect, which will reduce performance a little (dtw seems very robust). The default runtime configuration results in
frame_length = 1600
which is greater thanfft_order = 512
. However, this results in the lastframe_length - fft_order = 1088
elements being chopped off the hamming window. You actual window is only the first third of the hamming window, which is a very bad choice of window.aeneas/aeneas/mfcc.py
Line 218 in 4d200a0
aeneas/aeneas/mfcc.py
Line 230 in 4d200a0
besides the point, this should be
Your padding is appended only after you do the windowing
aeneas/aeneas/mfcc.py
Line 192 in 4d200a0
Same with the c code.
aeneas/aeneas/cmfcc/cmfcc_func.c
Line 519 in 4d200a0
aeneas/aeneas/cmfcc/cmfcc_func.c
Line 571 in 4d200a0
aeneas/aeneas/cmfcc/cmfcc_func.c
Lines 575 to 585 in 4d200a0
The text was updated successfully, but these errors were encountered: