Feature request: time-stretching when changing playback rate

[GoogleCodeExporter]

In other words, modify the playback rate without changing the track's pitch. 
This will make it easier to make sure that the track is in sync and make sure 
that the chart matches what is actually played in the track.

Original issue reported on code.google.com by quarns...@gmail.com on 20 Jun 2013 at 2:29

[GoogleCodeExporter]

This kind of thing has been requested before, but I don't know how to 
accomplish it.  It apparently involves fourier transforms.

Original comment by raynebc on 20 Jun 2013 at 5:09

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

There's some documentation and source code at 
http://www.dspdimension.com/admin/time-pitch-overview/, 
http://www.dspdimension.com/admin/pitch-shifting-using-the-ft/.

I hacked together a quick test using the "smbPitchShift" function from that 
source code as attached. It kinda works, but the resulting audio is clicky. I'm 
not familiar enough with the maths and theory behind pitch shifting/time 
stretching and fft's to know exactly what the cause is.

It could also be that the function is meant to be called once for a full sample 
rather than for a small mixing buffer (and thus the clicks are a result of a 
partially time stretched buffer).

Original comment by quarns...@gmail.com on 20 Jun 2013 at 5:40

Attachments:

• scale.patch

[GoogleCodeExporter]

There's a library for this: http://breakfastquay.com/rubberband/

Original comment by otaz...@gmail.com on 18 Oct 2013 at 9:04

[GoogleCodeExporter]

quarnster's example seems to use its own time fourier implementation whereas 
EOF has FFTW at its disposal.  I wonder if it can be utilized to get better 
results?

Rubberband is worth looking into, but if anybody can try to throw it into EOF's 
mixing code to get it working, it'd be a great start.  If it becomes absolutely 
necessary, EOF could probably just use the command line rubberband utility to 
generate a PCM audio file to use for time stretched playback, but that would 
slow things down significantly compared to being able to stretch in realtime.

Original comment by raynebc on 18 Oct 2013 at 9:57

[GoogleCodeExporter]

I've done some experimenting with octave shifting without any specific DSP 
domain knowledge and my advice is that you really want to use something that 
works rather than reinventing the wheel.  rubberband-cli in realtime mode kicks 
my implementation in the ass.

I don't know about EOF architecture but in the worst case you can recode whole 
track at once when speed setting changes (because you have whole track at your 
disposal), play that instead and slow down the UI.

Original comment by otaz...@gmail.com on 19 Oct 2013 at 5:48

[GoogleCodeExporter]

Be sure to checkout realtime mode, it won't take longer than the actual track 
so you can recode in the background, don't use CLI.

Original comment by otaz...@gmail.com on 19 Oct 2013 at 5:55

[GoogleCodeExporter]

I'll probably just use the Rubber Band library.

Original comment by xander4j...@yahoo.com on 23 Oct 2013 at 4:04

[GoogleCodeExporter]

Original comment by xander4j...@yahoo.com on 24 Oct 2013 at 8:35

• Changed state: Started

[GoogleCodeExporter]

I have this basically working now. I am wondering if we should just switch to 
time stretching altogether, getting rid of the old playback rate method. I 
can't think of any reason to leave the old method in place.

Original comment by xander4j...@yahoo.com on 28 Oct 2013 at 7:49

[GoogleCodeExporter]

Having it just use the time stretching code would probably be fine if there's 
no significant overhead when playing at 100% speed.

Original comment by raynebc on 28 Oct 2013 at 7:57

[GoogleCodeExporter]

This has been implemented. The Playback Rate menu now has a Time Stretch option 
which is now the default. When time stretching is enabled, the audio will be 
time stretched instead of slowed down.

Original comment by xander4j...@yahoo.com on 13 Nov 2013 at 5:01

• Changed state: Fixed

[GoogleCodeExporter]

A while ago you mentioned moving the rubberband initialization to whenever an 
OGG file was loaded instead of first playback, was that still worth pursuing?

Original comment by raynebc on 13 Nov 2013 at 5:12

[GoogleCodeExporter]

I started working on it, but there was some issue with it that made me change 
my mind. I haven't had any issues with the current implementation, it was just 
really slow to initialize when I was testing in a VM.

Original comment by xander4j...@yahoo.com on 16 Nov 2013 at 12:51