Stretcher Breaks at Ratios below 0.25

[BOBONA]

Hi. This seems to be a glitch of some sort, where setting a pitch shifting ratio below 0.25 causes extreme audio glitches. This doesn't seem to be a limitation of the algorithm, as I'm able to get around the problem with a little hack, adjusting the input sample rate and speed ratio accordingly to get the intended result.

Also with more extreme ratios, maxInputFrameCount() seems to underestimate the correct number. I didn't test the exact cutoff, and just added a check in my code.

[kupix]

Hi Bobona, thanks for the report.

Did you run with the asserts/self checks enabled? That might help to narrow things down. Supported pitch shift is 2 octaves but this is a limit to simplify memory allocations, not a fundamental hard limit. The library can certainly be enhanced to support more extreme pitch shifting.

[BOBONA]

Do I have to specifically enable asserts? I know the asserts I write catch... I'm not very experienced with C++ and am using the library with JUCE. When you say supported pitch shift is 2 octaves, does that mean it's not expected to work below that, or that there's no guarantee?

On Thu, May 30, 2024 at 4:22 AM John Funnell @.***> wrote:

Hi Bobona, thanks for the report.

Did you run with the asserts/self checks enabled? That might help to narrow things down. Supported pitch shift is 2 octaves but this is a limit to simplify memory allocations, not a fundamental hard limit. The library can certainly be enhanced to support more extreme pitch shifting.

— Reply to this email directly, view it on GitHub https://github.com/kupix/bungee/issues/4#issuecomment-2139133866, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF7FVGLEPGJ5FCU53LS3TU3ZE3VUPAVCNFSM6AAAAABIMD3MS2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZZGEZTGOBWGY . You are receiving this because you authored the thread.Message ID: @.***>

[kupix]

Bungee can be built with or without self tests. See this line:

https://github.com/kupix/bungee/blob/efcea7f68aa50ddf36d669903562a3fe41aad639/CMakeLists.txt#L33

Also see where the 2 octave maximum is set and search this variable to see how it's used.

https://github.com/kupix/bungee/blob/efcea7f68aa50ddf36d669903562a3fe41aad639/src/Timing.cpp#L20

If maxInputFrameCount() underestimates, it would be useful to know how to replicate this and also perhaps how to fix it!

[BOBONA]

Well, it's happening because of the resampling hack I'm doing to get ratios below maxPitchOctaves. So, I'm assuming you didn't account for people setting input / output sample rate below 0.5? Or maybe there's an assert for that I'm not getting.

Edit: NVM, it clearly does take that into account...

Just to be clear what I'm doing here:

if (initialRatio < 0.25f)
{
    pitchRatio = 0.25f;
    resamplingHack = 0.25f / initialRatio;
}
else
{
    resamplingHack = 1.f;
}

bungee = std::make_unique<Bungee::Stretcher<Bungee::Basic>>(Bungee::SampleRates{ int(bufferSampleRate / resamplingHack), applicationSampleRate }, buffer->getNumChannels());

[kupix]

So is everything working now?

[BOBONA]

I think the only issue then was that I was going lower than the maxPitchOctaves variable. I'm gonna keep using my little hack cause it seems to work fine and I'd rather not mess with stuff on my end. If there isn't already, there ought to be an assert for that, since I didn't realize there was a pitch limit until you said so. Or I might not have built with asserts properly, I'm pretty inexperienced with using C++ libraries.