Re: [LAD] Time-Stretch

I would strongly suggest looking at Rubberband:
http://breakfastquay.com/rubberband/why.html

<http://breakfastquay.com/rubberband/why.html>However, it is unclear what
you want: audio time-stretching, or audio resampling. Resampling will get
you the "slowed down record" or "sped up record" effect, where the pitch is
affected along with the time. However, if you want to manipulate the pitch
and time separately, then you need time-stretching. If you're not sure what
you want, I would still suggest librubberband, because it can do all of the
above, plus allow you to manipulate the parameters in real time.

Jeremy

On Sun, Jan 2, 2011 at 2:51 PM, Harry Van Haaren <harryhaaren@email-addr-hiddenwrote:

> Hey all,
>
> I'm looking for an open-source time-stretching library, suitable for RT
> work.
> I've googled and come up with the following list, which I can't choose
> from:
>
> -Soundtouch : http://www.surina.net/soundtouch/index.html
> -ClearScale / DspDimension: http://www.clearscale.org/
> -SecretRabbitCode / libsamplerate : http://www.mega-nerd.com/SRC/
> -LibResample : https://ccrma.stanford.edu/~jos/resample/
> -MFFM timescale: http://mffmtimescale.sourceforge.net/
> -LibZita-Resampler:
> http://www.kokkinizita.net/linuxaudio/zita-resampler/resampler.html
>
> I'm attepmting to write a sample player, that will time-stretch long loops
> to stay in sync
> with JACK transport.
>
> I've deduced this is what I need to do:
> - Calculate the amount of samples I need to change the buffer length by
> - Take the buffer, resample it to a larger / smaller amount of samples.
> - Playback the samples as I normally would, except that there's more, and
> hence the audio will stay in sync.
>
> Design choices:
> 1. should I re-sample the whole buffer, and then playback from that buffer?
> this approach might cause a lot of CPU strain once the rate changes, as the
> *whole* buffer would
> be re-sampled at the same time. Once done, the CPU has no strain from
> resampling.
>
> 2. Resample "nframes" amount of samples from the buffer, and play them
> back?
> Less sudden CPU overhead, more constant CPU usage.
>
> The other problem I'm faced with is that some libraries mention that they
> do *not* support "dynamically variable resampling ratios".
> Would I need this? I think I do, as to get the beat "on-time" sometimes I'd
> need to add 200 samples, while in other cases 210 samples
> might suit better...
>
> I'm aware that Ardour uses SoundTouch, but I'm not sure is that the best
> lib for real-time use.
> Mixxx is using LibSamplerate AFAIK, and does so quite well, but might not
> be as suitable as Soundtouch..
>
> http://www.surina.net/soundtouch/faq.html#sample_processing
> These kind of paragraphs are what stop me from just choosing one and going
> with it...
>
> Choices, Advice, Laughter, Help, etc all welcome! :-)
> Cheers, -Harry
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
>

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Mon Jan 3 00:15:06 2011