Is committing EA impossible to do accurately?

[Orrin]

I can't figure out a way to commit a track with Elastic Audio.

I've tried:

1. None - Disable Elastic Audio
2. Rendered Processing
3. Route track to new audio track and record in real time
4. Commit (offline and in real time)
5. Bounce (offline and in real time)

In all of the above cases, notes in the new audio clip are delayed by around 10 milliseconds.

But the delay isn't consistently that same amount. Some notes are a little less delayed than than others, which means I can't just nudge the whole thing earlier to compensate.

I've searched this topic exhaustively and it seems that a lot of people have this problem. Some say that if you record in real time that you will get an exact copy of the original, but that's not working for me. I've tried it with Delay Compensation both on and off, plugins active or all deactivated (for the entire session), etc. Every time, the new audio is delayed.

Does anyone have any other ideas I can try? Or is it not possible to get a sample-accurate copy of the EA track with the adjustments committed? I guess I can just roll with the EA on there for this project, but what if I need to send a committed version to a collaborator in the future? Also, isn't the audio being delayed anyway if I bounce down the session to a stereo mix?

[albee1952]

Why not simply turn EA off on the track and choose COMMIT from the pop-up? That has worked for me for the past year or more(but I almost always use X-Form for timing edits)

[Orrin]

I've tried that--it's labeled 1. in my list, if I understand you correctly.

It ends up with delayed audio just like the other choices.

[albee1952]

So if you turn EA off and commit, the audio moves on the track? I've never seen that here. Say I move some warp markers to a grid line and commit. The audio stays ion the grid here. Routing or bouncing to a new track can net some audio offset for a few reasons;
A bug in PT(seen this myself)
Latency caused by plugins(especially on the master track)
Latency caused by a large buffer setting(which PT should compensate for).
These reasons are why I generally just turn EA off and commit where it is

[Orrin]

Yep, it moves even when I turn off and commit. Please see the screenshots I've attached. I duplicated the track and turned EA off to commit the bottom one. Neither track has plugins on it.

As I noted in my original post, I've tried all these options with and without Delay Compensation on. I've also tried them all with zero plugins in the session--are you saying that I should be getting almost 500 samples of delay @ 44.1 kHz on a routed and recorded track even with absolutely no plugins in the entire session? I know that PT adds a small latency when routing, around seven samples or so from what I've heard, but this goes far beyond that.

I've tried the commit at both a 64-sample and 512-sample H/W buffer size, makes no difference in the size of the delay.

So I guess the only possibility is a bug, then?

[Orrin]

Here's a test I did on the same track, but without EA (I committed it to get rid of it).

The top track was routed to the bottom track and recorded. Might be hard to see from this image, but there is about a 30 sample delay. I assume this is the bus routing delay in Pro Tools, and is small enough to be neglible in terms of musical timing.

So to me, this test proves that there is something wrong with the way Elastic Audio works, since I am not getting a significant delay in the same session with the same track if EA is not part of the equation.

Anyone have a line to an Avid engineer that could shed some light on this?