Bug in FFT windowing

[tom-huntington]

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 than fft_order = 512. However, this results in the last frame_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

frame_length_padded = max(frame_length, self.fft_order)

aeneas/aeneas/mfcc.py

Line 230 in 4d200a0

self.hamming_window = numpy.hamming(frame_length_padded)

besides the point, this should be

self.hamming_window = numpy.hamming(frame_length) 

Your padding is appended only after you do the windowing

aeneas/aeneas/mfcc.py

Line 192 in 4d200a0

fft = numpy.fft.rfft(frame, self.fft_order)

Same with the c code.

aeneas/aeneas/cmfcc/cmfcc_func.c

Line 519 in 4d200a0

hamming_coefficients = _precompute_hamming(frame_length);

aeneas/aeneas/cmfcc/cmfcc_func.c

Line 571 in 4d200a0

if (_apply_hamming(frame, frame_length, hamming_coefficients) != CMFCC_SUCCESS) {

aeneas/aeneas/cmfcc/cmfcc_func.c

Lines 575 to 585 in 4d200a0

	#ifdef USE_FFTW
	// fftw code
	if (_compute_power_fftw(frame, power, fft_order, plan) != CMFCC_SUCCESS) {
	return CMFCC_FAILURE;
	}
	#else
	// own code
	if (_compute_power(frame, power, fft_order, sin_table_full, sin_table_half) != CMFCC_SUCCESS) {
	return CMFCC_FAILURE;
	}
	#endif

[tom-huntington]

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