At extreme rate adjustments, rubberband is counting samples inaccurately

[Owen Williams]

I have a track that is slow, around 87bpm, and another that is around 104bpm. If I turn on master sync and treat the 104bpm track as master, I should be able to click and drag and have both tracks be locked together. This works with the linear stretcher, but when I turn keylock on the 87bpm track they no longer stay in sync. This is probably because rubberband is not properly advancing the track the right number of samples. Given the large rate delta needed to match the tracks, is it reasonable to expect rubberband to handle this case?

[Phillip Whelan (pwhelan)]

According to the homepage librubberband should be able to do sample exact time stretching: http://breakfastquay.com/rubberband/why.html.

  "Rubber Band is designed to satisfy the need for a sanely licensed time-stretching library that sounds good enough for general musical use and also meets the many other requirements that make it useful in practical applications.... These include: Sample-exact time-stretching;"

It's right there on the webpage. I also read in their code that their algorithm is designed specifically for that. It might be worth checking all the parameters we are setting for it.

[Owen Williams (ywwg)]

From the .h file:

/**
     * Tell the stretcher exactly how many input samples it will
     * receive. This is only useful in Offline mode, when it allows
     * the stretcher to ensure that the number of output samples is
     * exactly correct. In RealTime mode no such guarantee is
     * possible and this value is ignored.
     */
    void setExpectedInputDuration(size_t samples);

Maybe we should keep track of the amount of error and try to correct for it in subsequent calls to the scaler?

[Owen Williams (ywwg)]

Interestingly the problem is worse in reverse.

[Owen Williams (ywwg)]

Hm, it's very weird, because rubberband falls back to linear stretching at high speeds (which makes sense), so you'd expect problems with sync in linear mode too. But no, I only get issues with sync when keylock is enabled, even when it's falling back to linear.

[Owen Williams (ywwg)]

I plotted rate and position information when doing this, and it looks like on the master deck the rate change is instantaneous, whereas on the slave deck the rate change ramps from the old value to the new. This causes a de-sync at the moment of rate change.

There is still a lot of drift in master sync when I hold down FF or REW with keylock on, though.

[Owen Williams (ywwg)]

Ah, this is probably because when we FF or REW, the scaler changes, and that resets the scaler, and that erases previous rate information so there's no ramp (instantaneous rate change). But on the slave side, nothing has changed so there is a ramp. A way to solve this might be to not clear out the scalers on change, or manually set the old rate after clearing.

[Owen Williams (ywwg)]

I don't think this should block 1.12.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/7327