Elastic Audio flakiness (timing, nulls, etc.)

[yeloocevad]

I've been noticing some pretty disturbing flakiness in elastic audio... anyone else? I'm doing heavy edits and my consolidations are not coming back full null against just bussing the track and recording it. And it's inconsistent from region to region. And I've also noticed differences when "commiting" with different algos... like working on the track in poly, and then commiting with Xform results in a track with audible glitches and remnants. Also, relative timing between events can be drastically changed. To make matters worse, even with just commiting with poly mode, when compared against the original track sometimes there can be a slight timing shift. This is not just a waveform display issue, it doesn't null sometimes. Am I the only one?

Early on, I did a null against the orginal track and it came back correct (with a small sample edit)... but now that my sessions are getting more complex, I'm noticing slight timing inconsitencies, glitches, etc. when I consolidate at the end of a fully edited session. PT 7.4cs1, 10.4.10, dual 1.8 G5, PTHD3 4 gigs ram, ADC on, auto-fades off.

My workaround for now is to bus and record the tracks separately... seems the most stable, but it's a PITA.

[Steve MacMillan]

I just corrected some complex multi-channel drums at 96k. I used the technique where I manually placed Analysis markers across the entire group for all kicks, snares, & toms. I quantized in Rhythmic mode and it sounded very nice. Solid and punchy. But when I tried to render the timing changed (the audio got faster) and a bunch of junk appeared at the very end of the regions (a combination of some drum audio from who knows where, and some white noise). There was definitely something seriously buggy going on.

Also, while I was manually placing Analysis markers, I duped the kick track. When I duped the track, I lost all of my carefully edited Analysis markers on the kick. The rest of the drum group, maintained the edited markers, but the act of duping the track was like hitting reset on the Elastic Properties window. Not great.

STeve

[yeloocevad]

Yeah, that's exactly what I'm getting. Especially the "faster" audio bit when rendering... things being shifted forward in time. I seriously love it as a tool, but man, they gotta fix that!!!!

[yeloocevad]

Also high sample rate here (88K)... and I've noticed pops and ticks and weird remnant regions appearing like you mention, especially if you use the warp markers to nix out an audio event... like pulling a tail from a previous hit over another following grace note, to add full sustain until the next hit. Sound fine while editing, zero crossings must be cool, but render... and you get ticks and or remnants.

[PaulV]

Hi there,

A couple points:

I've also noticed differences when "commiting" with different algos...

This is going to be expected; remember that timestretching is an inexact science, and different algorithms use different techniques to do their magic. Usually this involves tradeoffs between timing accuracy and timbral accuracy, with each algorithm favoring some more than others. Monophonic and X-Form favor timbral accuracy, but therefore can have timing divergence. Rhythmic and Polyphonic have very good timing accuracy, but can change the timbre of the sound. (And of course Varispeed has perfect timing and timbral accuracy, but it changes the pitch.) This is mentioned in the Read Me.

I'm doing heavy edits and my consolidations are not coming back full null against just bussing the track and recording it.

This is also going to be expected to some degree with dense edits and consolidating. On Elastic Audio enabled tracks, Pro Tools adds small "microfades" between edits to deal with the fact that the timestretching algorithms' behavior is to some degree non-deterministic (except Varispeed). Audio phase cannot be guaranteed between edits of time-stretched audio, even if the original material is "in phase" at the edit. These microfades are not written into the consolidated audio (in the same way that auto-fades are not written into consolidated audio). Similarly, these are not written into the audio when you choose to Commit the track, and disabling Elastic Audio on the track disables microfades.

So if you notice glitches at edits after committing an Elastic Audio track that weren't there before, adding a short (5-10ms) batch fade over the affected area should aleviate the problem.

...even with just commiting with poly mode, when compared against the original track sometimes there can be a slight timing shift.

Here's another point to consider that may be a factor in what you're seeing: because of the aforementioned nondeterminism in the algorithms, with a track using realtime processing, you may get slightly different output depending on where in the stretched audio you start playback. So if you've selected a portion of a region with warping in it and start playback (or bus recording), you'll get slightly different output than if you start before the beginning of the region. If this is an issue, using Rendered Processing will give output most like committing.

I hope this helps clarify.

[yeloocevad]

Well that's not really the problem... when I bus, i start the bussing from *before* the elastic audio regions. And then, certain warped regions are coming back out of sync in the null, and some are fine. Stretches of 4 bars or so will be hundreds of samples off.

Also, when going from polyphonic to xform... I can understand slight timing shifts, but I'm getting remnants that last a 16th note or so.... or random notes being placed a 16th note earlier or later in relation to surrounding notes. So, if Xform doesn't do "real-time" rendering and needs to re-render the whole track everytime you make a move... AND it totally messes with the timing as a "commit" function... what good is it???

The only solution for me is to bus the audio and record it. Why protools can't come up with the same result upon "commit" doesn't make sense to me. I'll send some screenshots after I get to the end of my current project, I'm on deadline right now...

I started noticing the problems when I spent a day or two editing an entire track, hit "commit" and the whole feel of the track was shot. Everything felt slightly out of time, tons of clicks and ticks, just inconsistent compared to what I heard while editing. It just doesn't seem like elastic audio is ready for primetime yet, even though is just about the coolest thing Digi ever included in an upgrade. It needs some work to get it completely usable.

[yeloocevad]

Also, a batch fade after committing will not remove the ticks I'm talking about, they're not between regions, they're within the regions where audio was tightened toghether in an elastic edit.

[gives]

I just corrected some complex multi-channel drums at 96k. I used the technique where I manually placed Analysis markers across the entire group for all kicks, snares, & toms. I quantized in Rhythmic mode and it sounded very nice. Solid and punchy. But when I tried to render the timing changed (the audio got faster) and a bunch of junk appeared at the very end of the regions (a combination of some drum audio from who knows where, and some white noise). There was definitely something seriously buggy going on.

Also, while I was manually placing Analysis markers, I duped the kick track. When I duped the track, I lost all of my carefully edited Analysis markers on the kick. The rest of the drum group, maintained the edited markers, but the act of duping the track was like hitting reset on the Elastic Properties window. Not great.

STeve

HI Steve,


Just curious.. Anyone using Auto Saved Sessions? I always have those handy and make sure I save right before I do a new and different move like what you are all describing. I have been thru this stuff enough to not want to create more work for myself.
I have mine at about every 3 minutes for safety.

Regards, Greg

[Steve MacMillan]

HI Steve,


Just curious.. Anyone using Auto Saved Sessions? I always have those handy and make sure I save right before I do a new and different move like what you are all describing. I have been thru this stuff enough to not want to create more work for myself.
I have mine at about every 3 minutes for safety.

Regards, Greg

You are so right. I actually set mine to once a minute, 99 times. I hate to try to remember everything I've done for the last five minutes after a long reboot, but I can always remember the last 60 seconds.

STeve

[PaulV]

Well that's not really the problem ...

Hi yeloocevad,

OK, perhaps there's something else going on with your session. If you don't mind sending me the offending track (or tracks) before they're committed to [email protected], we can have a look at it. You can use one of the large-file sending services; e-mail me if you don't have access.