Jump to content
DCMG

Recorded Tracks Are Offset / Not in Correct Position

Recommended Posts

Random issue but happens enough, thought I would ask if this happens to anyone else.

Typical circumstance:

Loop Record Mode> run 4-5 passes> stop transport to find all passes are not in correct position (always early to where they should be).  Luckily I usually am looping to a grid so it's easy to see the new misaligned passes are easily moved by 1/4, measure or whatever and all is well.

Subsequent passes all land in correct position; not unusual for the problem to NOT present itself again for days or a week.

Note: I did have this happen with a manual start (non looping mode) the other day, so it's not just a loop record issue.

No pattern detected yet, and no other timing anomalies with my setup observed ( UA Apollo w/ Presonus  192 providing Optical ins and clock)

TIA.

 

Share this post


Link to post
Share on other sites

I’ve seen this when looping and punching in. It was “fixed” back in the Sonar days. I’ve never had issues with ASIO drivers and looping. I have a project for testing to be sure everything is in sync; haven’t tested the latest update yet. I’ve had one project that was problematic in CbB. It was an old project that was started back in X2 or 3. I saved it as a . mid file and imported the audio tracks; haven’t had any more issues. 

tom

Share this post


Link to post
Share on other sites

Thanks for the input. Don't recall this issue in SONAR; seems like a recent ( last 2 updates?)

Will do more testing this week, but it's pretty random so far....

Share this post


Link to post
Share on other sites

We've been having a very similar issue intermittently for nearly a year. Recordings of new clips are either offset by 2 seconds (i.e. they are late by 2 seconds), or the last 2 seconds of the clip are cut off. It's been reported, but Cakewalk have been unable to reproduce or fix. As we can't determine in what circumstances it occurs (it seems entirely random) , it's very hard to reproduce: hence why it's been so hard to diagnose.

In our case when we examine the WAV audio file which is associated with the clip it either has 2 seconds of silence at the beginning, or the final 2 seconds of audio is there but not referenced by the clip.

We are using a count-in of 4 beats and a tempo of 120 bpm (=2 seconds), so we thought it was related to count-in or snap, but no luck so far. Snap on or off makes no difference.

Would be really interested to see how your WAV audio files associated with the out-of-sync clips look.

(We're using Allen & Heath Qu24 ASIO driver with Cakewalk 2020.08, but it's been happening in lots of earlier releases)

Share this post


Link to post
Share on other sites
17 hours ago, Roger Jeynes said:

We've been having a very similar issue intermittently for nearly a year. Recordings of new clips are either offset by 2 seconds (i.e. they are late by 2 seconds), or the last 2 seconds of the clip are cut off. It's been reported, but Cakewalk have been unable to reproduce or fix. As we can't determine in what circumstances it occurs (it seems entirely random) , it's very hard to reproduce: hence why it's been so hard to diagnose.

In our case when we examine the WAV audio file which is associated with the clip it either has 2 seconds of silence at the beginning, or the final 2 seconds of audio is there but not referenced by the clip.

We are using a count-in of 4 beats and a tempo of 120 bpm (=2 seconds), so we thought it was related to count-in or snap, but no luck so far. Snap on or off makes no difference.

Would be really interested to see how your WAV audio files associated with the out-of-sync clips look.

(We're using Allen & Heath Qu24 ASIO driver with Cakewalk 2020.08, but it's been happening in lots of earlier releases)

Did some testing last night, couldn't get it to happen (or course)

My only clue is I've never had it happen LATE in a session; always right off the bat, then subsequent takes are good once I observe the issue, stop transport and begin a new set of takes ( buffering, length of time program/OS/computer has been on? )

I've started doing a test run of 2-3 looped takes when I've got a client present. I don't tell them why I'm doing it, but I'm checking to make sure it's behaving. Shouldn't have to do that type of stuff to trust your system ( which BTW is a fast CPU, good RAM and all SSDs so no issue there)

Will keep digging.

 

Share this post


Link to post
Share on other sites

It tends to happen earlier in sessions, but not always. However it has never happened on successive takes.  We also wondered if was to do with flushing the buffers, because we sometimes get a (random) audible 'tail' on rewind and re-start - although not at the same time as with this out of sync problem.

We've tried increasing ASIO buffer sizes and increasing latency, and increasing the Cakewalk File System buffer size, but it seems to make no difference. Got a very powerful i7-9700K, lots of memory and M2 SSD, We've also changed the PC last December, and it has persisted across 2 completely different PCs, so  I'd be really surprised if it's a  PC hardware issue.

Freed at Cakewalk has asked us to try and reproduce the problem using a different interface (we have an old MOTU), but of course we haven't been able to because we can't use this for real work - which is when it tends to happen, of course! I'm encouraged that you're using a different audio interface, which possibly takes the spotlight away from Allen & Heath driver.

We're going to try changing this setting in the Config file (just for something to do)

image.png.8f95f57e827edc4a0f0694597a07460a.png

 

Share this post


Link to post
Share on other sites

Just trying some other things to see if we can isolate or clear this problem:

Wondering  what this setting in the config file does, and whether it might be relevant:

image.png.7970cc63a9d8438c514c1f8d5619f45a.png

Ours is set to 'true' in the config file.

 

We also have other ASIO drivers installed, but not normally active, for other audio interfaces. I noticed that the 'Record Latency Adjustment' setting always resets itself to the first driver in the list, no matter which one we select. (Although 1328 samples is a lot shorter than a 2 second delay)

image.png.9c13403e9a5671b6c9e5798915404307.pngimage.png.14088c55e159d195298f13890cb7988e.png

 

 

Share this post


Link to post
Share on other sites

It happens so infrequently you might be waiting days or a week before the changed settings would show if they worked. I'll keep at it too.  Strange elusive issue....

 

Edited by DCMG

Share this post


Link to post
Share on other sites

You really need to get rid of that generic ASIO driver, that definitely causes problems for me so I found the .dll and nuked it. ( it will be in a Steinberg folder)  It gets installed with Steinberg stuff like Wave Lab or Cubase. 

  • Thanks 2
  • Great Idea 1

Share this post


Link to post
Share on other sites

New occurrence yesterday, when the new overdub clip was out of sync by a huge margin (20 seconds!) and the leading part of the new clip truncated by this amount. During recording, the waveform was drawn perfectly  normally. Finding it really hard to go on covering this up with the customers

image.thumb.png.27d20c7db48a87fb325db0fba7028960.png

Edited by Roger Jeynes

Share this post


Link to post
Share on other sites
On 9/11/2020 at 11:00 AM, Roger Jeynes said:

New occurrence yesterday, when the new overdub clip was out of sync by a huge margin (20 seconds!) and the leading part of the new clip truncated by this amount. During recording, the waveform was drawn perfectly  normally. Finding it really hard to go on covering this up with the customers

Interesting note that the waveform preview is always in correct position, suggesting alignment is correct at moment of capture, then offset upon transport reset. Same always true here as well. I'm going to update all my system info along with typical plugins used so we can identify any commonalities. Regarding the suggestion about generic drivers, I only have the UA Apollo Twin USB drivers present and still have this issue. No conflicting ASIO drivers present.

 

Share this post


Link to post
Share on other sites

Great, The offset is calculated by Cakewalk and it needs correct information which can only be supplied by the ASIO driver. This is why you will see timing offset errors like this in all the other driver modes. 

Have you tried a loopback test? 

Take a midi drum track,  just a kick or snare will do, Freeze it to audio. 

Now patch the output of your interface back to an input and set up a new audio track to record this input. 

Turn OFF input ech for that new track. 

Record the loopback,  and then zoom way in to see if the transients match up. 

If you do this with a 3-5 minute track, you can check at the end of the song to see if it drifts off time. 

 

Share this post


Link to post
Share on other sites
19 hours ago, John Vere said:

Great, The offset is calculated by Cakewalk and it needs correct information which can only be supplied by the ASIO driver. This is why you will see timing offset errors like this in all the other driver modes. 

Have you tried a loopback test? 

Take a midi drum track,  just a kick or snare will do, Freeze it to audio. 

Now patch the output of your interface back to an input and set up a new audio track to record this input. 

Turn OFF input ech for that new track. 

Record the loopback,  and then zoom way in to see if the transients match up. 

If you do this with a 3-5 minute track, you can check at the end of the song to see if it drifts off time. 

 

Thanks, John - really appreciate your interest in this.

A loop-back test shows what I think we might expect: a constant delay of about 1000 samples, which I guess is just the ASIO driver latency (2 x 512 samples)? We're struggling to understand how or why this sometimes causes a huge slip (from 2 to 20 seconds) in the timing and content of a recorded clip, when the waveform is being written normally and at the correct time during recording. (I should add that we haven't seen one in the last 2 days, so your interest is paying off!)

image.png.77e16ee43c5f2168ff94663a4277ce2b.png

Share this post


Link to post
Share on other sites

Well I tested a few different interfaces and everyone of them was bang on if I used ASIO mode. You have something going wrong if your ASIO driver is not syncing up with Cakewalk. You might want to try a different interface. 

 

806862182_Scarlettoffsetcopy.thumb.jpg.d611a1f3fa0d08467b0b00afcf1142cf.jpg

 

Here was a Behringer USB interface that used a generic Codex 

1145638222_USBaudiodeviceoffsetcopy.jpg.57ecdaa2b9c1859294c01b335605e007.jpg

 

Here is a Crappy Sound Blaster card but with ASIO it seems to be OK.  Notice WDM mode which always seemed to be early in my tests. 

 

1136491374_SBASIOandWDM.thumb.jpg.a564993437b39225d124aa83c33f4c0d.jpg

 

 

Share this post


Link to post
Share on other sites

Yeah, I'm not seeing round trip latency issues offset by 128 samples or something. These are  wholesale "off by 10 seconds" issues.

Then the next immediate round of recording (literally seconds later) ...everything fine.

Odd issue. Yesterday happened mid session, which I haven't encountered. It's a tough one to explain to clients ( when we already labor under the "why not ProTools?" dogma 😆

Share this post


Link to post
Share on other sites

The device in the "Record Latency Adjustment" must match the device you're using for record/playback, else all the timing will be off.

Uninstall the Steinberg "Generic Low Latency ASIO driver" if you can - it causes no end of issues, and isn't required (even for Cubase) if you've got an interface that has a native ASIO driver.

  • Thanks 1

Share this post


Link to post
Share on other sites

I think there's some confusion here as the OP's  claimed he does not have any other drivers listed. , the screen shot was from Roger who is also having an issue and definitely needs to nuke the Steinberg driver.  

The OP is using a complicated set up with 2 interfaces involve. To test I would go direct from the Apollo via USB and see if the problem persists. 

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×
×
  • Create New...