Comment by ~breakfastquay on ~breakfastquay/rubberband
All past releases are at https://breakfastquay.com/files/releases/
Comment by ~breakfastquay on ~breakfastquay/rubberband
John - The link in my previous comment didn't "click" properly because the Markdown processing included the following full-stop in the link. I've edited it to add a space. But I think it is a page you have read before.
Yes, the samples have been through a forward FFT before the complex magnitude is taken, but that is very mathematically predictable (unlike something like a recursive filter say).
You definitely shouldn't be seeing sample counts consistently wildly over or consistently wildly under the passed value, no - they should average out.
If your product is using Rubber Band 1.8 at the moment, the integration must have been done quite some time ago. Has it worked before? When did it stop working?
Comment by ~breakfastquay on ~breakfastquay/rubberband
John - Have you definitively demonstrated that none of the float values you're passing to process() - or to study() - are infinities or NaNs?
As regards input/output counts, if a earlier process calls returned fewer values than you passed in, then there must be some buffered internally, and then it is highly likely that a later call will return more than you pass in. Rubber Band doesn't suspend its frame-by-frame overlap-add even when the ratio is 1.0, you always need to have the sort of pull-model or buffering in place that is alluded to in https://breakfastquay.com/rubberband/integration.html . I understand (addressing John here again) that you are doing this work for an existing commercial product, so drop me a note if the publishers would like some consultancy time here.
Comment by ~breakfastquay on ~breakfastquay/rubberband
updating rubberband here to v1.9.1
I'd recommend 1.9.2.
do you happen to know which of its header files contains the above function
I think FFTW only has one header (
fftw3.h
). I believe it is generated by some configure script for the platform though, so installing one from elsewhere might be risky.
Comment by ~breakfastquay on ~breakfastquay/rubberband
John - Yes, Rubber Band is built using MSVC at every commit via CI. In addition to the Meson MSVC target, there is a Visual Studio project file for the static library in
otherbuilds/rubberband-library.vcxproj
. (That is its location from v1.9.1 onwards - previously it was in the top level directory of the Rubber Band repo.)
loadWisdom
andsaveWisdom
are defined elsewhere inFFT.cpp
, and (depending on build flags) they call out to the FFTW functionsfftw_import_wisdom_from_file
andfftwf_export_wisdom_to_file
. They are used only when building with FFTW support and (in Rubber Band v1.9.1 and later) only when the symbolUSE_FFTW_WISDOM
is defined.I would normally recommend configuring Rubber Band for a Windows product using the built-in FFT (for simplicity) or IPP (for performance) rather than FFTW. However, the built-in FFT was only added in v1.9.2 and IPP is not usable in a GPL application. Once again, I would recommend updating to a newer version - ideally to v2.x if you can accept that the output might not be identical (see the release notes for that version for details), but v1.9.2 is output-compatible with v1.8 as well as being many years and revisions more recent.
Comment by ~breakfastquay on ~breakfastquay/rubberband
Rubber Band does everything using floats, so these two questions have essentially the same answer - when it asks for (say) 1024 frames of input, it means (1024 * the number of channels) floats, conventionally in range -1 to 1.
Comment by ~breakfastquay on ~breakfastquay/rubberband
Rubber Band uses overlap-add analysis-resynthesis internally, and it does so even when the ratio is set to 1.0 (so as to handle situations where the ratio subsequently changes "live"), so the number of samples it can return is constrained by the fill state of the internal buffers.
In general it can't be assumed that you can pass a number of samples at input and see the same number (or a number that is related simply by the stretch ratio) at the output. It's always necessary to call
available()
and be prepared to provide more input, if you want to see a certain number of samples at output. See this documentation (the "integration notes" linked from the Rubber Band site) for more information. I've just updated that page to clarify the situation further, I hope, so let me know if it is still unclear.
REPORTED
RESOLVED FIXEDComment by ~breakfastquay on ~breakfastquay/rubberband
Added a check (in commit:f9a50353f998) for
inputIncrement < 1
and to increase the input and output increments and window size accordingly.We should still check & at least document a maximum stretch factor anyway, as the windowing doesn't work correctly for such extreme values - a factor of 640 works well but 6400 still does not, this fix notwithstanding.
Comment by ~breakfastquay on ~breakfastquay/rubberband
Probably best thing to do next is dig down in libsamplerate, see if I can find a small misbehaving case, and fix or seek help upstream there.
Now that libsamplerate has a BSD-style licence, it seems reasonable to suggest that anyone wanting dynamic pitch changing should use the libsamplerate resampler rather than any of the alternatives.