Elastic Audio Commits and Bounces are out of time

[ralphonz]

Hi everyone,

So I've come across what appears to be a catastrophic, show-stopper of a bug with elastic audio.

It seems that "sometimes" for no reason that I can find, various warp modes won't render, bounce or commit in time.

Yesterday I realised that some drums I'd warped in ElastiquePro mode had gone nuts when they were committed. Indeed there is no pattern to what is output by either committing, bouncing or recording to another track other than it is not the same as the actual warped track and many hits are out of time. I tried other warp modes and the only one that rendered correctly was Rhythmic.

So I found (in the same session) the same thing happening with the bass track. For that none of the modes except rhythmic would output correctly either, however, rhythmic sounds awful on the bass...

Before I go through the lengthly process of putting together evidence and testing everything in multiple projects etc I would like to know if anyone else has had this issue or is it a known bug?

[midnightrambler]

Elastique Pro definitely had issues (e.g. https://duc.avid.com/showpost.php?p=2669221&postcount=6). I thought these were ironed out but I haven't really used it since I got my fingers seriously burnt with it last year.

Personally I can't think of any issues with real-time processing vs rendered/committed for the other algorithms.

[ralphonz]

Further, yesterday I found timing issues when committing melodyne too. Completely different when committed or bounced, but at least melodyne is okay when recorded back in, though the recording still doesn't null with the original melodyne track so the result is still different from what I'm hearing at least it's in time when recorded rather than committed. Also there was a strange blip in a vocal track when committing or rendering melodyne which isn't there in a recorded version or on playback of the edited melodyne track.

[ralphonz]

I'm kind of surprised that no one else has commented on this?

Has anyone out there compared real-time with rendered elastic audio processing?

I've posted the following on another thread, but it was started in 2018 so I'm adding it here too.

I've spent weeks making edits to an album before mixing, only to find that what I was hearing is not what I get.

It basically seems to boil down to the fact that there is HUGE (in my book) difference between real-time and rendered processing.

Committing, bouncing or rendering tracks with real-time EA gives totally random results. Committing (bouncing or rendering) tracks with EA switched to rendered processing gives a consistent output though.

In real-time, what you hear will change depending on where you play the session from. You can test this by recording your warped track to a new track via a bus. Invert the phase on the new track and it will only null with the real time processing when the session is played from the exact point that you recorded from.

Now let's look at the difference between real-time and rendered processing. Duplicate a warped track and set one to real time EA and the other to rendered processing. Now inspect the difference in the wave forms. You can see that some transients are in drastically different places with timing differences between about 4 and 20ms most of the time, sometimes even worse - this is the real issue.

This is illustrated in my attached screenshot -the top bass track is the rendered processing and the bottom one the real-time processing.

Null tests prove that this is not a visual issue but is actually an audio processing issue.

Whenever you work in real time mode you cannot trust what you're seeing or hearing as it vary's a hell of a lot from the actual rendered result. This is worse when dealing with very transient material.

This does not occur if using the Rhythmic algorithm, but occurs with every other one.

Switching to analysis view in rendered processing mode illustrates the problem further as it is impossible to line up the markers with the waveform, given how much the waveform jumps around when you actually click down with the mouse button/trackpad. When you click down you are briefly shown the wave form in real-time mode, you line up the marker with the start of a hit but as soon as you let go (and are shown the waveform in rendered mode) the marker is nowhere near the transient! I fail to see how this is in any way usable for anything other than one or two corrections per song, given how long it takes to get an accurate rendered result using this "trial-and-error" method of moving analysis and warp markers around.

According to my research on this issue (on the DUC, gearspace and YouTube) this has been driving people mad for around 7 years! However, many things I looked at had not performed null tests or tried rendered processing to investigate the issue further, but simply became frustrated that they could not accurately render their warped tracks.

[Sarkara]

yes having this issue as well. noticed it using elastique pro. Then tried polyphonic and that seemed to at least get the transients pinned to where they should be but the rest of the note looks overstretched compared to the uncommited version. That being said i can get them to null in the poly algo so it seems to be graphical issue. Elastique pro and monophonic dont null at all. So theyre legit messed up. Anyone else having this issue?

[weezul]

Had this problem with elastique since the first ever day it came out. Absolute joke. Such a shame because it does sound good. Unless you commit it.

[Wireline]

Do you have these problems when bouncing to a new track in real time? I generally do this so I can verify what’s what in real time instead of relying on off line things. Once satisfied, I simply disable the elastique or whatever track, hide it, and move on..

[ralphonz]

Originally Posted by Wireline

Do you have these problems when bouncing to a new track in real time? I generally do this so I can verify what’s what in real time instead of relying on off line things. Once satisfied, I simply disable the elastique or whatever track, hide it, and move on..

Yes, as I put in my original post:

In real-time, what you hear will change depending on where you play the session from. You can test this by recording your warped track to a new track via a bus. Invert the phase on the new track and it will only null with the real time processing when the session is played from the exact point that you recorded from.


Bouncing in real time seems to have the same result as this.

[ralphonz]

Originally Posted by Sarkara

yes having this issue as well. noticed it using elastique pro. Then tried polyphonic and that seemed to at least get the transients pinned to where they should be but the rest of the note looks overstretched compared to the uncommited version. That being said i can get them to null in the poly algo so it seems to be graphical issue. Elastique pro and monophonic dont null at all. So theyre legit messed up. Anyone else having this issue?

I'll try poly again...

[ralphonz]

Originally Posted by Sarkara

yes having this issue as well. noticed it using elastique pro. Then tried polyphonic and that seemed to at least get the transients pinned to where they should be but the rest of the note looks overstretched compared to the uncommited version. That being said i can get them to null in the poly algo so it seems to be graphical issue. Elastique pro and monophonic dont null at all. So theyre legit messed up. Anyone else having this issue?

Confirmed! Rendered or Committed Polyphonic warping nulls with the realtime processing so that's a relief.

With Polyphonic the visual waveforms are different vs the rendered version, but crucially they're only different for the tails of the notes/hits. The transients and markers all line up - looks like the first few cycles after every marker are visually the same on the real time as the rendered version. This is good news because there's no timing errors, even if the phase appears different.