search

jthiem / nnresample

A resampling function based on placing the filter's first null on Nyquist (Null-on-Nyquist Resample)
MIT License
23 stars 3 forks source link

have u compared memory usage #11

Closed svilendobrev closed 5 years ago

svilendobrev commented 5 years ago

hi. This is not a problem by itself, but regarding your comparisons of quality of scikit /resampy / scipy.resample and now this resampler - have also compared memory-usage?

i've been resampling audio records (for comparing variants of same hour-long stuff) for quite some time, and scikit uses like 8x-10x less than scipy.resample, and is somewhat faster. You say there that scipy is faster but my experience says otherwise. It will be interesting to see, for long real audios (like 10+ minutes @ 44khz).. have fun

jthiem commented 5 years ago

Hi, interesting question! I have not compared memory usage, being primarily focused on the quality of the output, rather than computational or memory efficiency. As I pointed out in my blog post (or gist), scipy.resample is not suited for audio resampling. It is also not good for long signals (but very fast for short sequences).

Complexity is usually stated using O-notation. Most resampling methods for audio are actually O(N) if you take N to be the length of your signal. Resampling 10s of audio will take about twice as long as resampling 5s of audio.

Since scipy.resample works in the Fourier domain, with luck (your signal is of length 2^K, K being an integer) you can get complexity O(N*log(N)). That's still pretty good, but more than O(N).

However, the polyphase methods (like nnresample) have large set-up times, and scale badly with the length of the antialias filter (possibly O(N^2) tough don't quote me on this). So if your signal is large, the computational complexity growth is entirely dominated by that.

Now, memory usage. Polyphase methods (nnresample, resampy, etc.) need memory for the filter coefficients. Other than that, just the memory for the original and the resampled signal. The signal can be processed in chunks, and thus doesn't need to be all in the cache or RAM all at the same time.

Scipy.resample needs to store the frequency domain representation of the input signal. Again, this can be big, and needs to be all accessible during the conversion. A standard song at 44.1kHz will burst your L3 cache easy, starving your CPU.

Ergo: never, ever use scipy.resample for audio signals.

jthiem commented 5 years ago

Closing this issue as it is not really a bug - the discussion can continue though (I think github lets comments open?)