Variable rate phase vocoding

phase_vocoder currently accepts a single scalar parameter controlling the rate of time dilation. In principle, it shouldn’t be difficult to either vectorize this, or support a slice+rate parameterization so that different time regions can be accelerated by different rates.

[dpwe]

Once you get to variable rates, you have to make sure you are clear about how the time base is defined, because now the input and output time bases have a nonlinear relationship. What you really want is the mapping from output timebase to input timebase, since it’s not infeasible to want reversals and loops (non-monotonic relationship). If you accept a vector of per-input-window time scale, then effectively you’re specifying how much time each fixed-size input window will occupy in the output, and it’s hard to predict how long the output will be.

I think accepting a vector of (input time, output time) (defining a piecewise-linear relationship) tuples is a nice, neutral description. You could then programmatically figure out the slope (time scaling) and time center required from the input signal for each output frame.

On Sun, Feb 19, 2017 at 10:35 AM, Brian McFee [e-mail] wrote:

phase_vocoder currently accepts a single scalar parameter controlling the rate of time dilation. In principle, it shouldn’t be difficult to either vectorize this, or support a slice+rate parameterization so that different time regions can be accelerated by different rates.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/librosa/librosa/issues/517, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhs0bGWDe2DTuev2CxECb-OiuU404-kks5reGE-gaJpZM4MFfoW .

[bmcfee]

Give me time until the end of the year. 😃

🛎️