#21 RubberBand misunderstanding 3 months ago

Comment by ~breakfastquay on ~breakfastquay/rubberband

All past releases are at https://breakfastquay.com/files/releases/

#18 Assertion in MovingMedian::drop 3 months ago

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?

#18 Assertion in MovingMedian::drop 3 months ago

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.

#21 RubberBand misunderstanding 3 months ago

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.

#21 RubberBand misunderstanding 3 months ago

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 and saveWisdom are defined elsewhere in FFT.cpp, and (depending on build flags) they call out to the FFTW functions fftw_import_wisdom_from_file and fftwf_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 symbol USE_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.

#21 RubberBand misunderstanding 4 months ago

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.

#21 RubberBand misunderstanding 4 months ago

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.

#2 Unbounded memory usage and non-termination with certain tempo maps 1 year, 9 months ago

on ~breakfastquay/rubberband

REPORTED RESOLVED FIXED

#5 Time ratio should be constrained, out-of-range ratios can cause division-by-zero 1 year, 9 months ago

Comment 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.

#6 Audible clicks when changing pitch-shift factor 1 year, 9 months ago

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.