# Cepstrum calculation with 5-smoothing zero padding

I am trying to compute cepstrum of a signal x

An implementation of this in python is:

x_fft = np.fft.fft(x)
cepstrum = np.real(np.fft.ifft(np.log(abs(x_fft))))
cepstrum = cepstrum[0:len(audio_signal_frame) // 2]  #
cepstrum_db = 10 * np.log10(cepstrum ** 2)


I wanted to zero pad x to hamming number length before the cepstrum calculation to make the fft more efficient, i.e.:

x_padded = zeros(fftpack.next_fast_len(len(x)))
x_padded[0:len(x)] = x
x_fft = np.fft.fft(x_padded)
...rest of the cepstrum calculation...


However I am worried that this will affect the ifft in unintended ways (besides changing the quefrency resolution by the padded amount)

Looking at the Interpolated Cepstrum Estimation section of this paper it seems that there is an additional step 6 where they pad the fft signal by power of 2. However I am not sure if this step is required or how to implement if padding isn't in powers of 2 since hamming number is not strictly K power of 2.

• Seriously, I very much doubt that the speed difference of the unpadded FFT to your padded FFT matters measurably (unless the unpadded length is a product of primes > 13), so simply don't do that without having a benchmark that actually proves you're doing something good. – Marcus Müller Dec 5 '19 at 21:55
• @Marcus Müller I am processing a lot of files and I ran a similar algorithm that uses just the fft and zero padding with hamming number had a significant speed/memory boost compared to zero padding with power of 2 zeros, and both had significant difference compared to no padding. My only problem is that I am not sure if just zero padding the original signal would be an issue if I need to take an ifft afterward. – kkawabat Dec 5 '19 at 22:20
• well, I presume your not directly doing zeropad -> FFT -> IFFT -> throw away zeros but will actually do something with your frequency domain (probably, logarithms?) and that will indeed have an interaction with your zero padding. If speed is such an issue to you, try fftw instead of fftpack (== numpy.fft); it's typically a tad faster for non-power-of-2 transforms. (You might also want to start thinking about the calling overhead from python when you do that.) I tend to work in the high kilotransforms-per-second to megatransforms-per-second regime, and honestly, the overhead of zero padding… – Marcus Müller Dec 5 '19 at 22:27
• … (i.e. copying and/or memory reallocation) if you're not filling pre-allocated buffers with the non-zero data is usually worse than the loss you get for small-prime-factor lengths (what are your lengths, by the way?). – Marcus Müller Dec 5 '19 at 22:29
• In this case the length is a variable since we are taking a frame of speech data that is dependent on the pitch of the speaker. I will look into fftw, thank you for the suggestion, however I would like to have a better understanding on how to zeropad (non-power-of-2 amount) while still making sure FFT -> IFFT is accurate. Do you happen to know any resources that I can read up on this? Thank you for the replys. – kkawabat Dec 5 '19 at 22:49