0
$\begingroup$

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.

Improve this question
$\endgroup$
9
  • $\begingroup$ 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. $\endgroup$
    – Marcus Müller
    Dec 5, 2019 at 21:55
  • $\begingroup$ @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. $\endgroup$
    – kkawabat
    Dec 5, 2019 at 22:20
  • $\begingroup$ 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… $\endgroup$
    – Marcus Müller
    Dec 5, 2019 at 22:27
  • $\begingroup$ … (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?). $\endgroup$
    – Marcus Müller
    Dec 5, 2019 at 22:29
  • $\begingroup$ 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. $\endgroup$
    – kkawabat
    Dec 5, 2019 at 22:49

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.