Audio engine bug - Consolidate not as per manual.

[kb420]

http://www.youtube.com/watch?v=K8E_zMLCRNg

[Khazul]

Always on the lookout for good perc noises - chopped and mashed crickets next

[Tone Deft]

Not a squeak (bug report sent along with link to this thread).

Anyway - doesn't really matter - not stuck on it, now know not to waste time again trying to use this feature, and TBH I always knew it was off anyway, though the differences I've come across before (obviously not using a groove I guess) were barely audible even in isolation.

in the spirit of their White Paper on Live I'd like to know what's going on just so I know the tool better. even if there's a workaround (people hate that, I don't mind, I just want to know.)

still haven't done my own tests but just hit play on a two week vacation, the time is there now.

[Khazul]

in the spirit of their White Paper on Live I'd like to know what's going on just so I know the tool better. even if there's a workaround (people hate that, I don't mind, I just want to know.)

still haven't done my own tests but just hit play on a two week vacation, the time is there now.

In the spirit of the white paper - consolidate ? pre-fx bounce when a groove is applied (audible difference can be huge). Also commit groove + consolate ? pre-fx bounce either (audible difference is subtle).

? means may not produce indentical audio data - ie its not allways transparently equivalent to the grooved and warped clip and so may not null.

I think the white paper should just say - if you like what you hear - bounce it before you touch anything! - Which allways used to be the way to do things before daws and digital editors etc.


Lets just hope the same code isnt also used by the export audio/video function...

Which would explain why noone heard a thing from ableton - they had a big oh shit moment and have since gone to hide in south america...

[mr.ergonomics]

pls send [email protected] a mail too. otherwise we can't be sure that they are register that. also interesting if they could comment this behaviour.

[kb420]

pls send [email protected] a mail too. otherwise we can't be sure that they are register that. also interesting if they could comment this behaviour.

Khazul said he sent in a report in the opening post.

Report sent though probably in a black hole, posting here so other are at least aware and so know to use z manual bounce when appropriate.

He said he hasn't heard anything, and Ableton certainly hasn't participated in this thread.

[Khazul]

(Edit - It turns out the following might actually be a result of warp timing being a bit random which I discovered after posting this).

This issue seems to be present to a varying degree on all the applicable tracks when using the 'Export Audio/Video' feature.

I removed all fx off the tracks, exported to AIFF 32 bit, loaded them in, duped the corresponding original track, stuck a utility on to reverse phase, set track gain to 0 so they should sum to at least very close to cancelling (some difference about 30+ dB down would even be ok, but no - its glaring). End result sounded just like the isolated test I had done posted in this thread.

So by now Im started to wonder about all the little times I've done bounces (ie route a track to an audio track and record) and though something wasn't quite right running though parallel fx chains etc, but never bothered to investigate (always assuming such a bounce would always be perfect - you would think?).

So, I add another audio track to bounce the grooved and warped clips one by one thinking it would get me the clips I want - I still isn't an exact copy of what I hear. The difference is much smaller, but still wrong.

So, Im lucky enough to have a really good RME audio interface that can do a digital loopback easily - bounced the warped clip through that (disabled fx on the track and set it to ext out on an unused UFX channel pair) and recorded it back into Live on another audio track. That finally is a verifiable exact copy of the grooved and warped clip as I hear it.


Is it possible that what you hear normally is a preview warp mode and consolidate and export both do a high quality job (though actually they sounded terrible and time shifted slightly) - so I guess not.
But what is being record by an internal bounce then? That is neither the same as the export or consolidate and isn't what you hear either.

Either way - it seems that if you want an exact copy of what you can hear when mixing after warping some clips and applying a groove - you need to actually bounce the audio via an external digital loopback - soundflower might do on a mac (can it loop?), any audio interface with 24 bit digital in and out - just connect in to out and with RME, then enable loopback for a channel pair in total mix.

Not much else to say really....

[Khazul]

I'll post an updated project tomorrow when I added more example cases into it and cross referenced some more of the bounces to work if they are actually bad, or whether its just warping being random.

In the mean time, it also seems that warping (with groove?) is not reproducibly sample accurate relative to music time (or worse tracks in general arnt), but depends upon where you start playback. Ie - start play from one place, and some of the example will null. Play from another location and they will not. I believe this explains why the export and internal bounce didn't null in post above, but the RME bounce did - just because of me setting a loop around the RME bounce so play started from the right place to get a cancellation.

Unfortunately, the usual case of say starting playback from start of the track doesn't appear to cancel (though might if the clip also starts at the track start), only when I do a 1/2 bar loop in the arrange view does it actually cancel - not good. (not so bad if it was the other way around).

[broc]

Either way - it seems that if you want an exact copy of what you can hear when mixing after warping some clips and applying a groove - you need to actually bounce the audio via an external digital loopback - soundflower might do on a mac (can it loop?), any audio interface with 24 bit digital in and out - just connect in to out and with RME, then enable loopback for a channel pair in total mix.

In my experience soundflower works well for loopback, or you can also use JACK (Mac and Windows).

[hoffman2k]

Is it possible that what you hear normally is a preview warp mode and consolidate and export both do a high quality job (though actually they sounded terrible and time shifted slightly) - so I guess not.
But what is being record by an internal bounce then? That is neither the same as the export or consolidate and isn't what you hear either.

You know when you load a sample that is 130Bpm, Live will sometimes think its actually 129.99Bpm?
That is a 0.01 difference between the sound being warped or not, depending on the warping mode.
But that 0.01 is rounded, so the difference might very well be 0.00501, you just can't see it with Live's Segment BPM section.
So even when a 130Bpm sample shows up as 130Bpm in the Segment Bpm section, how do you know Live is not seeing it as 130.001Bpm?

I suppose the real question is: If you don't manually type in a BPM for each sample, how can you know for sure that warping isn't a factor?

I'm not sure this even relates to your problems, but since you're doing some intensive testing it might be a variable to consider.

[smaucher]

Is it possible that what you hear normally is a preview warp mode and consolidate and export both do a high quality job (though actually they sounded terrible and time shifted slightly) - so I guess not.
But what is being record by an internal bounce then? That is neither the same as the export or consolidate and isn't what you hear either.

You know when you load a sample that is 130Bpm, Live will sometimes think its actually 129.99Bpm?
That is a 0.01 difference between the sound being warped or not, depending on the warping mode.
But that 0.01 is rounded, so the difference might very well be 0.00501, you just can't see it with Live's Segment BPM section.
So even when a 130Bpm sample shows up as 130Bpm in the Segment Bpm section, how do you know Live is not seeing it as 130.001Bpm?

I suppose the real question is: If you don't manually type in a BPM for each sample, how can you know for sure that warping isn't a factor?

I'm not sure this even relates to your problems, but since you're doing some intensive testing it might be a variable to consider.

so why don't you just turn off warping then to see if this has an effect?

[Hermanus]

I've learnt to avoid consolidate for big FX'd and warped clips.

EVEN synth can be ruined by the frozen once you consolidate, then something sounds not right.
When I want straight copy, I record post FX to another track.

I know it's a workaround ... an 'ease of mind' way

[hoffman2k]

Is it possible that what you hear normally is a preview warp mode and consolidate and export both do a high quality job (though actually they sounded terrible and time shifted slightly) - so I guess not.
But what is being record by an internal bounce then? That is neither the same as the export or consolidate and isn't what you hear either.

You know when you load a sample that is 130Bpm, Live will sometimes think its actually 129.99Bpm?
That is a 0.01 difference between the sound being warped or not, depending on the warping mode.
But that 0.01 is rounded, so the difference might very well be 0.00501, you just can't see it with Live's Segment BPM section.
So even when a 130Bpm sample shows up as 130Bpm in the Segment Bpm section, how do you know Live is not seeing it as 130.001Bpm?

I suppose the real question is: If you don't manually type in a BPM for each sample, how can you know for sure that warping isn't a factor?

I'm not sure this even relates to your problems, but since you're doing some intensive testing it might be a variable to consider.

so why don't you just turn off warping then to see if this has an effect?

I'm having no warping issues. Just thinking out loud about the analysis of samples.

[[stm]]

Hi,

I bookmarked this thread and will forward this. We will then try to see if there might be something going on that should not be.

Please be sure to send your reports to [email protected] as well, which is the dedicated inbox of the tech support team, while [email protected] is mainly used by our developers. If you have, then I am sure it is being handled already, but it might take a little while.

Cheers!
Stas.

[Khazul]

Is it possible that what you hear normally is a preview warp mode and consolidate and export both do a high quality job (though actually they sounded terrible and time shifted slightly) - so I guess not.
But what is being record by an internal bounce then? That is neither the same as the export or consolidate and isn't what you hear either.

You know when you load a sample that is 130Bpm, Live will sometimes think its actually 129.99Bpm?
That is a 0.01 difference between the sound being warped or not, depending on the warping mode.
But that 0.01 is rounded, so the difference might very well be 0.00501, you just can't see it with Live's Segment BPM section.
So even when a 130Bpm sample shows up as 130Bpm in the Segment Bpm section, how do you know Live is not seeing it as 130.001Bpm?

I suppose the real question is: If you don't manually type in a BPM for each sample, how can you know for sure that warping isn't a factor?

I'm not sure this even relates to your problems, but since you're doing some intensive testing it might be a variable to consider.

There is a fundamental truth in a claimed sample accurate music production system if were ignore time history effects (delays, reverbs, filters EQs etc).
Given playback from a specific point in time at a specific quality level, the resulting sample value at that point should always be the same regardless of where playback starts from.

If that is not true, then you cant bounce predictably from an *arbitrary point in playback*, or export predictably. It means there are possibly two or more effectively different algorithms for picking a sample from a specific music time. I can see how this happens - one function's job it to determine a sample position from a music time (a complex job with warping, grooves etc). Another algorithm arrives at a sample point corresponding to a specific music time by virtue of incrementing through an audio buffer because playback started from an earlier point in time.

Ideally, both methods should arrive at the same source material sample at the same time - they don't. Within the limitations of integrating functions in processing (ie processing that needs a sample history), they should arrive at the same resulting sample value as well, or at least very close to the same value such that the difference will be inaudible at a normal working listening level.

In another thread, it has been pointed out that many DAWs are not actually sample accurate according to music time except at certain tempos that are a safe ratio to the underlying sample rate (In practical terms, this means a beat or a bar is an exact number of samples). So part of the inconsistent results I get is most likely down to that. I am doing these tests at 128 BPM. In order eliminate that at any sample rate, I need to do them at 120BPM for eg as at 120BPM and 44.1K sample rate, each beat consists of exactly 22050 samples. At 128BPM, a neither a beat nor a bar is an exact number of samples.

This explains some of the variation according to playback position that threw me for a while. However, I hardly ever work at 120BPM, so I don't really care how it behaves there.

All this is kind of going OT with respect to the original problem - just taken me a while to see exactly what is going on an understand so I can deal with it correctly when bouncing etc.

I understand that sometimes these differences are really tiny (As Mr Henke will no doubt point out eventually). When you listen to the isolated results without comparison, then there is no audible difference except in the blatant consolidate cases. However, if you have spent the past hour or more making the transients in your warped clips sit perfectly along side the transients in other material then these tiny errors may audibly change the resulting mixed audio. It just depends what you are doing, what kind of material you are working with. In my case, what made me revisit this after the original issue was after internal bouncing, the resulting mix just seemed 'dull' for want of a better word and didn't sound any better in cubase or logic either (before anyone brings that up )

Going back to your point, it actually does not matter whether your clip tempo was originally set to 130, 129.999 or whatever or what your play tempo is. As soon as you warp the thing or apply a groove that results in sample positions changing to fractional ratios to the playback tempo (ie fractional sample positions) then variation according to playback position will kick in due to the (at least) two different ways of associating a sample with a specific playback position.

I hope that makes sense - perhaps it only makes sense to programmers who have dealt with this kind of problem space.

I hope that stuff like this makes it into the Live white paper. At least Ableton have made an attempt to dig into their engine and make some concrete statements. Either way - now I understand this behaviour, I don't consider it a bug directly, more an FYI for users who care and for whatever reason need to establish working practices to avoid such issues.

However I also hope that Ableton give more thought to such issues and adjust the code such that they could make the following three statements true:

1. Operations such as export, bounce, calibrated external bounce and consolidate will all be guaranteed produce identical results to the original heard sound when playback or bounce starts from 1.1.1 at any tempo. (This currently does not appear to be true).

2. At any point in playback un-warped audio at the project sample rate will consistently relate the same specific samples in any other un-warped clip in another track regardless of tempo. (This currently does not appear to be true either).

3. At any looped playback position, the playback of source audio should be identical on a second and subsequent passes of the loop to that on the first pass. (This isn't true either currently).

Personally I consider these three items to the be underlying bugs in addition to the groove + warp consolidate issue because at the moment they get in the way of allowing users who care to work carefully and consistently.

I have to wonder if some of this is what lies behind the ghostly audio quality issues that some people complain about (3phase for eg who I know does not appear to be particularly careful about how he does stuff in Live - surprising as coming from a much older hardware background you tend to be more careful). Logic suffers from the sample accuracy issue (I don't know about cubase), but as far as I can tell, logic is at least consistent, but to be fair I have not done such deep testing of it. Just like live, I (possibly naively) assumed it would at least be consistent from music playback position 1.1.1.