Bouncing AudioSnap Clips Changes Note Positions!

[marcL]

At the moment I am working a lot with AudioSnap. I like it really!

But one thing makes me wonder, when I bounce some audio clips to another track, then the note start positions change a little bit (range -10/+10)! Is this normal? And why?

[David Baay]

Rendering  Audiosnap stretching  (either in place or bouncing to another track) will often move transients a bit, depending on the nature of the audio, and which  stretching algorithm you're using.  This is a function of the algorithm, and should be the same in any DAA that uses the same algorithm. I've had at least one case where Elastique really messed with the timing of a single transient; changes of a few ticks should not be a problem in most cases. 

[marcL]

3 hours ago, David Baay said:

changes of a few ticks should not be a problem in most cases.

Although I think I am bad in rhythmics, I can hear the difference whether audio starts 5 ticks later or sooner (960 ticks per quarter). That's why I am a little bit irritated by this. On the other hand if I perceive my "bad" playing and see its inaccuracy, I totally agree with you! ?

[David Baay]

5 ticks at 125bpm is 2.5 milliseconds. it's a rare  bird who can hear, much less perform, with that level of precision.

[John Bradley]

I'm seeing the same thing. Rendering my AudioSnap'ed tracks using Elastique Pro occasionally glitches and shifts a transient by a most-definitely noticable amount.

See the screenshot. Top track is 'live', second one is rendered. For whatever reason, that first marked transient has been shifted nearly an 8th late, and second one has been shifted nearly a 16th late. The third one (and subsequent ones) are back in sync again.

Happens fairly frequently, and requires a fair bit of surgery after the fact. In my current test case, 14 bars were significantly garbled in a 150 bar (5 minute) guitar track.

Using 'Bounce to Track', with the Fast Bounce and 64-bit engines selected, none of the other checkboxes checked, channel format Mono.

It's deterministic. Doing the bounce again (from the live source track) results in an identical set of errors, in the same places. Exact same errors if I bounce using Elastique Efficient instead.

Bouncing with Radius Mix Advanced worked correctly - no glaring errors.

On a hunch, I went back to using Elastique Pro, but splitting up the track into multiple clips. (The track had been one single clip, after flattening the comp.) Split the track every 12 bars. Considerably fewer glaring errors, but still a couple. Splitting the problem areas up even further (1 bar clips) fixed it further, but never got it quite right.

For now, I'm just going to use Radius Mix Advanced instead, but hopefully this can be fixed!

 

 

[John Bradley]

Just installed 2020.04 build 179. Same problem.

[marcL]

I was not using 'Elastique Pro' as 'Offline Render' method, because IMO 'Radius xxx' has much better results. But also with 'Radius Solo' I have deviations of the original AudioSnap positions, but not so drastic as yours!