Grim wrote:I wouldn't expect any bounce with elastic to SOUND correct..and I would also expect different algos to sound perfectly correct (and null) But I also think the warped track with elastic algo didn't sound correct. Again the only way to prove or disprove this is to record this track while playing back Cubase....not using any internal bounce or export.
I think you're right. Unfortunately I was not able to record the warped track out of Cubase on an external device - don't have the hardware to do that properly, as I will be unable to eliminate all additional noise, level changes, and achieve perfect synchronisation in order to carry out null testing, anyway. So that's out of the question. But I think that from the following results I got you can draw the following conclusions:
a) audiowarp with the standard - drums algorithm is fine (in terms of timing) and works as intended
b) audiowarp with elastique is screwed up, inconsistent, and the problems are INDEED heard during playback. It WILL NOT bounce as you expect it to, because, as you've mentioned:
Grim wrote:Note also that the elastic algo also seems to change what it plays with looping or depending where you start playback from making null testing against the live warped track impossible
I don't know if this fact is MORE or LESS horrendous than what I've already thought
But you can judge for yourself - and please do let me know if you think I'm still misinterpreting anything.
I apologise for another long post in advance, but what follows is quite an extensive test, so I couldn't make it any shorter if I wanted to show the results.
1) For testing purposes I'll use a quantized snare track, because with it I'll also easily be able to demonstrate what I mean by "artifacts" caused by the "Standard - Drums" algorithm.
This is how the quantized snare track looks:
Here is how it sounds with Elastique - Time algorithm: http://www.sur.si/testis/1-1_(elastique-time).mp3
Here is how it sounds with Standard - Drums algorithm: http://www.sur.si/testis/1-2_(standard-drums).mp3
Note the audible artifacts in the "Standard - Drums" algorithm version (pay attention to the snare's "ring").
Any timing problems introduced during exportation should also be present in these mp3s, obviously, because I had to export them to show them to you... But let's proceed with the reverse phase test to check that out.
2) First let's eliminate the possibility that I can't carry out a reverse phase test - hey, it's always possible
- Made sure there were no effects and any plugins whatsoever present in the chain - no inserts, no sends, no master FX, no nothing. So we only have the dry quantized snare mike track that you can hear under 1).
- Duplicated the quantized track, reversed the phase on the second (duplicated) track. Here's what we get:
This is how it looks:
Here is how it sounds: http://www.sur.si/testis/2_(phase_reverse).mp3
So I suppose what this proves is that I can carry out a reverse phase test, yay
3) Now let's concentrate on the timing issue. First I tried to determine if there are differences between the QUANTIZED SNARE and the BOUNCED QUANTIZED SNARE, using ELASTIQUE - TIME algorithm.
- bounced the second (phase reversed duplicated) track using elastique - time algorithm and replaced the second (phase reversed track) with the bounced track.
This is how it looks:
Here is how it sounds: http://www.sur.si/testis/3_(phase_reverse_quantized&elastique).mp3
Ideally we should now be unable to hear anything, as the quantized and bounced quantized tracks should cancel each other out. But they don't - you can clearly hear that, although the differences are extremely minor. That's because we have an additional problem here: if I listen to the result in Cubase, it is, of course, different from what you hear, because what YOU are hearing in the mp3 is actually a comparison with between TWO EXPORTED tracks - as soon as I export it, the original (quantized) snare also gets exported. I assure you I can hear more obvious differences between the two tracks when I play them from Cubase, but right now I don't have an external device to record the playback directly.
But I should be careful with interpretation here - somewhat counterintuitively, regardless of the fact that I can HEAR the playback is different in Cubase than the bounce, this test doesn't actually prove that exportation - in case of elastique - doesn't result in consistent exports: the exportation might always result in identical waves... But even if they're identical, they'll just CONTAIN IDENTICAL UNFORSEEABLE CHANGES from what you SEE on the screen or even hear - because the QUANTIZED TRACK that you're comparing the BOUNCED TRACK to always sounds a little different! This test certainly proves THAT, look here: let's try a real-time export of the same two tracks: http://www.sur.si/testis/3_(phase_reverse_quantized&elastique-REAL-TIME_EXPORT).mp3
Now, despite the fact that "real-time export" should be absolutely precise, I suppose, that sounds even WORSE instead of better for some reason - sounds like Cubase loses increasing amounts of synchronisation here. But it certainly sounds different from the other export, so regardless of WHEN in the process the differences are introduced, there is NO WAY you can trust the results you get from bouncing a track audiowarped with the elastique algorithm. In both cases (both mp3s) there are obviously CONSIDERABLE errors introduced every time you play or bounce the track warped with elastique, it seems.
Furthermore, what is even more horrifying, if you start the export somewhere in the middle, you get this:
- this is the region I exported:
- normal export: http://www.sur.si/testis/3-2_(phase_reverse_quantized&elastique).mp3
- real-time export: http://www.sur.si/testis/3-2_(phase_reverse_quantized&elastique-REAL-TIME_EXPORT).mp3
What the F*UCK? Can we even imagine all the implications of this?
Indeed, in Cubase, if I start the playback BEFORE the two tracks occur, the errors seem to be RELATIVELY minor, though much more audible than what you hear in the above mp3s (if I wanted to demonstrate it properly, I'd have to record it with an external device, which I didn't have at the time of the testing. Besides, it doesn't matter much, you can hear the errors anyway). But if you start the playback somewhere in the middle, you can hear the snare track almost normally, which means the two tracks are completely unaligned. Now imagine having drums recorded on 14 tracks, quantizing them, and then bouncing - how many unforeseen "errors" - or "changes", if you will - does that result in? Or what happens if the tracks start outside of the region you're exporting?
4) Now let's test the timing issue in case of STANDARD - DRUMS algorithm.
- bounced the second (phase reversed duplicated) track using standard - drums algorithm.
The results LOOK a tiny bit different:
But they obviously sound the same, because the reverse phase test results in silence. Well, that's another problem - why in the hell do the waves look as if they're not perfectly aligned when they obviously are? This doesn't do anything to reassure me that Cubase knows exactly what it's doing
Here is an export of a random section: http://www.sur.si/testis/4_(phase_reverse_quantized&standard).mp3
This also proves that the Standard - Drums algorithm works correctly and consistently, regardless of where you start exporting. Thankfully!
However, the problem is that the Standard - Drums algorithm introduces audible artifacts (demonstrated under point 1), so I hate using it!!! Hence the proverbial "between a rock and a hard place" situation. As far as I'm concerned, using the elastique algorithm should have the same consistent and predictable results! Otherwise I don't really know why it's even there, if you never know what it'll do - as it is now, it's a bit like a "randomize" button, for crying out loud (OK, I'm exaggerating, but still, c'mon!).
5) That leaves the last thing I wanted to do: compare the two bounces (exports using two different algorithms) to check how different they sound.
- bounced the quantized snare track using elastique - time algorithm.
- bounced the quantized snare track using standard - drums algorithm.
- imported both tracks, aligned them to bar, reversed the phase on one of them.
This is how it looks:
Here is how it sounds: http://www.sur.si/testis/5_(phase_reverse_elastique&standard).mp3
Obviously the two bounces are COMPLETELY DIFFERENT (they LOOK different and SOUND different).
Since in point 4 we've already proved that the "Standard - Drums" algorithm works precisely (in terms of time) and consistently, this comparison provides a further proof that the "Elastique - Time" algorithm is horrendously imprecise. The errors seem to be introduced during playback (but changing each time you play the track and also depending on WHERE you start playing the track)... Then for all I know another set of changes may be introduced during exportation (hmmm, I suppose exporting the phase-reversed comparison between a previously exported and a quantized track, like in example 2, even proves that - because, if you look at it that way, that is actually a comparison between TWO EXPORTED tracks - one you reexport and the other you export for the first time, but they should be the same, so exportation should result in silence but it doesn't
)... Bah, this is completely messed up and so confusing I seem to be developing a headache
Anyway, there's no way you can predict what exactly you'll get when you export anything edited with elastique algorithm, and that's the worst possible thing in my book.
What I want to do is be able to quantize multitrack drum recordings consistently with audiowarp and produce high-quality results. This should, by all means, be something I can do with Cubase 7.5, and that's what they've also advertised since they introduced audiowarp quantization years ago. Now, what my test proves beyond any doubt is the following:
a) I can't use the Elastique - Time algorithm, because the results are completely unpredictable and WILL result in temporally imprecise exports/bounces. WHEN those imprecisions happen is not important, because the exports/bounces WILL sound differently from what I hear in Cubase while I work (though from what I've seen the tracks may even sound slightly different every time I listen to them, and the very thought of that is so annoying it makes my head spin).
b) While using the Standard - Drums algorithm ensures temporally precise and completely reliable and predictable results, it also introduces very audible artifacts, which is once again extremely undesirable. Yes, I can live with it for now, because the artifacts are usually not audible in a full mix, especially the genres I usually work in (heavy prog, heavy electronic music, rock, guitar-based blues, and so on). But I'm sure I would be totally unable to get away with using the standard drums algorithm in case of extremely dynamic acoustic music or, perish the thought, something that would involve parts with only drums and/or percussion, because in that case the artifacts would certainly be apparent.
I don't even want to imagine all the implications of what I've certainly proved here, especially in cases of extremely precise electronic music etc.
The fact that Cubase 7.5 is unable to deliver completely precise exports with all algorithms is completely unacceptable in my book. I understand that some algorithms are more demanding than the others, but come on: my CPU use when I edit drums is completely negligible regardless of the algorithm used... And at least the results should be totally precise with REAL-TIME EXPORT in ANY AND ALL CASES, which I've just proven they are NOT BY A LONG SHOT!
And what p*sses me off even more is that Steinberg hasn't addressed this problem for years, and in 7.5 this is still broken. Hell, they haven't even ACKNOWLEDGED properly that the problem exists!
I'd love to hear someone else's thoughts on this, but the above "novelette" is such an epic read I don't think anybody will bother... And until Steinberg doesn't give a damn the situation will remain the same regardless of how much testing I do and how I do it. I can just get a bumper sticker saying "Elastique algorithm sucks donkey balls" and get it over with