Take a drum loop several bars long and use an elastique setting to fit it to the project tempo - this will be chosen by default in C6 I think.
Loop it and playback.
Chop it up a bit - moves hits around to re-arrange the groove, copy a single snare hit throughout the pattern etc.
You soon run into disk read errors (you can see it on the little processor / disk read meters) and the audio glitches and stops playing back correctly.
Switch the stretching algorithm back to an old V5 version and it suddenly plays back ok again.
This is on a single track - the disk should be able to handle dozens (if not hundreds) of tracks doing in this, so why do you get read errors and playback glitches?
(First, let me just get over the shock of finding that the audio kept dropping out… even when Musical Mode was deactivated… before I realized it was because I have a demo version of Izotope Ozone 4, which drops out from time to time… if I’d had no version of Ozone at all, I wouldn’t have had that scare! )
Anyways… nothing untoward happening here. Are you seeing overloads on the Performance meter?
(also, probably worth verifying… does it still happen for you with the Ozone plugin bypassed?)
Sorry - you can get rid of Ozone - it’s left from the full session - I deleted everything else as it isn’t needed.
Move your playback cursor to bar 67 - you can see the disk meter spiking just by having the cursor stationary on that bar!!! That’s definitely screwy and a bug.
Now play bar 67 of the bottom ‘Bass Faulty’ track - you’ll hear the glitches.
Now play bar 71 of the top ‘Bass OK’ track - glitches aren’t there.
It’s exactly the same audio, except it hasn’t been cut and moved. If you delete the 4 blue bars and shift the red section back, it will be exactly the same as the track below and the glitching will happen.
This is simply an example which shows the issue. I realise its just a little bit at the end of a big file. However, If you’re chopping up loops and moving the audio around, everything can be perfectly ok, then bam - you start getting the glitches everywhere.
I opened the project and it’s true that at the end of the file (bar 67) the last note (bass slide) sounds bad and there it’s a big disk activity. However when I get rid of the Loop function, the last note sounds good and the disk activity doesn’t appear.
Edit: I’ve realized that if you leave the cursor in the slide note (stopped), the disk activity goes crazy! until I turn down loop mode.
As you say - it’s a weird one to get your head around, but when you do, it’s clear that there is something seriously wrong going on here, and my posted session proves there definitely is a reproducible issue.
Can we get this reproduced your end Steiny and added to the ‘to be fixed list’?
Both will obviously produce a new audio file thats not using realtime timestretching so there won’t be any problems, and the resultant file doesn’t contain any artefacts.
This however is to be expected - the glitching is coming from disk reading overloads, not a fault in the timestretched audio.
When you get to the effected part of the audio, Cubase suddenly goes mental accessing the HD - the HD meters start flashing madly. This happens even when when you aren’t playing back - simply having the playback cursor line parked over the effected region causes the HD meters to spike.
He’s right, this only happens when you have the loop mode on the transport engaged - it stops when you turn loop mode off.
You can see from this screenshot that the playback cursor is parked on bar 67. Playback is stopped, but loop mode is on. The disk meters in the top left hand corner are spiking even though Cubase isn’t doing anything.
(it is indeed possible that when I first replied, saying I couldn’t see a problem, that Cycle was not switched on). Anyways, the problem is there with Cycle “on”, and is o.k. with Cycle “off”.
More…
This is happening only in a very specific circumstance (which of course is this one! )…
(first, am I right in thinking that, in your .cpr, even though Musical Mode is “on” for that clip, it is playing at its original tempo… 130 BPM… anyways? The problem goes away when Musical Mode is switched off.)
It is only happening if the Cycle start point is also a point where the file is no longer being read sequentially (i.e. your edit point). As an experiment try this…
Move the Left Locator, so that it is no longer at that edit point (doesn’t matter if you move it earlier or later). The Disk overload goes away.
With the Left Locator back at its original position, move the Right Locator. The problem doesn’t go away.
I’m away from the studio at the mo so can’t check this.
The audio is as you say at 130 - same as the session tempo. Musical mode is on because I’m using free warping to tighten up the performance. You should be able to see all the warp markers in the audio.
My original encounter with this problem though was with a drum loop that was both stretched (to fit the project tempo) and chopped.
It seems that the crucial factor is that the Left Locator (in Cycle Play) is also an edit point. Does that also fit your first scenario (the drum loop)?
Actually I now think the problem is just looping when you’ve audio files using elastique.
I was just knocking up a quick bit of music this morning for a tv commercial. The 5 audio tracks in it needed to be speeded up slightly, so I just turned on musical mode and upped the tempo - no warping within the files, and no chopped audio parts. As soon as I turned on looping, I was getting glitches from disk read errors.
)
)
)…