Dirac Timestretching anyone?

[joer]

Surely it is possible to time stretch (lengthen) on-the-fly by passing on stretched sampledata on to the next output sample blocks as needed. This would obviousely mean an overlap of input - output much like a delay line - duh!

on-the-fly is more descriptive than realtime I think!

[JCJR]

Surely it is possible to time stretch (lengthen) on-the-fly by passing on stretched sampledata on to the next output sample blocks as needed. This would obviousely mean an overlap of input - output much like a delay line - duh!

on-the-fly is more descriptive than realtime I think!

Apologies if I'm misunderstanding what you describe. In a plugin schema which requires input and output buffers to be identical-sized, and a host that doesn't know to 'coddle' a stretching plugin, a plugin can stretch however much it pleases in the longer direction, as long as it has virtually unlimited internal buffering space. For instance, with a 2X stretch, 44.1 K samplerate, float stereo samples, the plugin would have to cache extra data at a rate of about 20 megs per minute of play time.

If the plugin wants to shrink duration, it will inevitably fall behind and have to 'silent gap' pieces of buffers. If you could set up a special case, where the plugin somehow knows it is supposed to run for 10 minutes, shrinking duration by half, it could cache something on the order of 200 megs of audio (returning silence to the host), before beginning to output duration-shrunk data.

If building the thing into a program rather than a generic same-buffer-in-and-out plugin scheme, its not that big a deal. For instance, in a DirectShow playback filter graph, the end-of-the-chain render buffer can 'pull' data from upstream plugins. So if you wire a DirectShow render graph:

disk-read source plugin -> stretch plugin -> playback render plugin

Requests from the render plugin determine the rate of data sucked thru the pipe, and everything can work fine. If the stretch plugin doubles the duration, data is just sucked out of the disk read plugin at half the normal rate.

=====

I haven't yet tried the Dirac DLL, but Dirac uses a callback to help modulate the 'uneven' data flow. According to the docs, you get the Dirac DLL running, and then if it needs extra data, it requests via the callback.

=====

I once made a stretch/pitch/samplerate convert object that works thusly--

First you init the object with desired input/output samplerates, duration, and pitch parameters (which in many cases would just be NoStretch and NoPitchChange).

If the input buffer must remain same-sized, you ask the object how big the output buffer will be, worst case, to satisfy that assortment of params.

If the output buffer must remain same-sized (ferinstance, driving ASIO), you ask the object how big the input buffer will be, worst case, to satisfy the combination of in/out samplerate, pitch shift, and duration.

In the final setup step, you tell the object how big the input and output buffers will be. The object then creates internal caches big enough to never fail under the given set of parameters.

Maybe that is over-complex, but it allows pretty transparent 'push' mode operation after it is setup.

There are two 'push' calls into the object (simplified)--

Convert(InOutBuffer, size);

GetOverflow(OutBuffer, size);

For instance, in a render callback or disk-processing loop, first the handler calls GetOverflow(). If the object has cached enough data from previous conversions that it can satisfy the output buffsize from cache, it returns a buffer's worth of data from the cache and returns TRUE.

Otherwise, GetOverflow() returns FALSE, and the program knows to render a buffer of new data and pass it to the object with Convert().

Any extra data generated from the Convert() call (bigger than the requested output buffer size), gets cached to the object's overflow buffer.

So if you were stretching 2X, approx half the output data would get supplied by GetOverflow(), and the other half from Convert().

OTOH, if just stretching 1.1X, perhaps only one-tenth of the data would come from the GetOverflow() call.

=====

There are probably better ways to skin the cat, but those are a couple of ways to do it.

[birrbits]

ok I still see a problem with this realtime stretching (other than looking into the future, or dealing w the bufffer sizing) My problem with the notion is this
Lets say you are using a microphone and speaking into this mystical realtime stretcher.
Lets say that you start to say something at time 'A' which ends at time 'B', but is stretched to end at time 'F'
meanwhile you say something at time 'C' which ends at time 'D' but is stretched to end at time 'G'
etc...etc...
anyone see a problem with the events that are ALL overlapping at time 'F'?

Is the only solution a 'gated' sample length? or am I being braindead?

[JCJR]

Hi birrbits

All my messages were about 'realtime' or 'on the fly' stretching audio that was already recorded to a disk file. Low-latency realtime stretch on live input, seems intractible in the current universe (GRIN). Maybe that feature will be added in a future upgrade...

[birrbits]

ahh gotcha, fyi (i think this has already been said) 'realtime' and 'on the fly' generally arent interpreted as meaning 'from a stored file'

[blümchen]

Oh please! Please not all that again!

[joer]

With an "on-the-fly" time stretch would it not be possible to fade the stretched output and maybe use progressively lower sample rates and bit depths to save buffer sizes, I dont think that you would have to complete every part of the stretch to have some kind of very interesting new delay line type effect?

all the best delay lines degrade horribly on recurrance.

just a thought!

[blümchen]

The kind of time stretching you are talking about is not the DIRAC algorithm.
Dirac obviously uses an interconnected combination of TDHS and FFT, specialized for achieving highest audio quality.

[joer]

OK..
I don't think I actually mentioned any particular algorithm, I was just commenting on some of the ideas that came up within this thread on DIRAC and timestretch! Like certain people saying on the fly timestretch is a physical impossibilty. I must admit that time compress would be hard but there are some interesting ideas on that in this thread too.

I'd be interested to know why ,in your opinion, DIRAC would be so unsuitable for a timestretch delay line? I understand that it is actually quite versatile in terms of cpu load versus audio quality etc etc.

[JCJR]

ahh gotcha, fyi (i think this has already been said) 'realtime' and 'on the fly' generally arent interpreted as meaning 'from a stored file'

Please explain--

Lets say you have an audio file-player program that doesn't even have an audio input or recording function. The program has one big knob for tempo, and another big knob for pitch. During playback, it responds practically instantly in realtime when you yank the pitch or tempo knobs. The program doesn't require you to stop and then process a new disk file.

If that is not 'realtime', what would you prefer that it be called? How is this hypothetical program's behavior any less 'realtime' than the 'instant' response you get when turning the varispeed knob on an analog tape recorder, or if you twirl your finger on a turntable to change a vinyl record's speed?

All three examples seem realtime experiences to me. You certainly don't have to wait to hear a result.

Mission-critical systems more important than music sequencing, have gradations in the definition of 'realtime'. 'Hard realtime' systems have less latency and jitter than typical Winders or Mac systems.

[birrbits]

ahh see, thats 'realtime controls'
as opposed to a 'realtime effect'

[JCJR]

Duh, how many angels can dance on the head of a pin, anyway? Its realtime, and its an effect. What diff does it make if the effect is acting on a disk file rather than live input?

OK, when you playthru a softsynth sampler with yer MIDI keyboard, do you claim it is not a realtime process, simply because the basis samples are disk files rather than live input?

[joer]

It's to do with parallel, timed input and output samples not disc or live!
surely this a straight forward concept!

[birrbits]

there are many definitions

http://www.google.com/search?hl=en&lr=& ... :Real-Time

My intent wasnt to hijack a thread about what is & what is not realtime, I just wanted to understand exactly what JCJR was looking for...

[Borogove]

Its realtime, and its an effect. What diff does it make if the effect is acting on a disk file rather than live input?

If it's on disk, it can read ahead (effectively 'into the future') to accomodate speed-up, or it can read more slowly without risk of running out of RAM to accomodate slow-down.