Since when we record audio it is “printed” a certain amount of time after we play it, based on the Input buffer latency, it seems like it would make sense to drag the printed audio earlier in time by that amount. Is there such an option in Cubase 6? I’ve looked, but wasn’t able to identify it .
For example, a 256 buffer at 44.1KHz gives a 5 or 6 msec Input delay. So if overdubbing with audio to an existing track, the audio will be placed on its track at least 5-6 msec late. For as close to sample accuracy as possible, wouldn’t it be right to drag the newly recorded audio track earlier by that 5-6 msec?
Taking this further, when overdubbing to audio, we don’t hear the existing audio until 5-6 msec after it appears on the track, so we’re actually playing our notes late. Would it be also helpful to have an “Overdub” option, that would automatically drag the newly recorded track earlier by a combination of the Input latency PLUS the Output latency?
Thanks for any help with this - open to forthcoming comments that might say I am missing a big part of the picture - wouldn’t be the first time!
How do we actually know what is going on under the hood/bonnet? Is it shifting early by one buffer only? Or both the input and output buffer?
I suppose it doesn’t matter in the end - there is always some track shifting that needs to be done anyway (in my projects ). Still, it’d be nice to know what Cubase (vs other DAWs) does.
This is very interesting topic. I don’t know the answer.
On the other hand, I can’t imagine a practical and realistic applications in any case. I think that human error and inaccuracy is much larger than Buffer Size has.
Check me on this please, but I believe a clear answer to the original question can be found in what we know already:
If we play audio out a hardware output, and record it directly back into a hardware input: we find the two tracks line up within a few samples of each other. If Cubase printed the recorded track exactly when it received it, the recorded track would be delayed by at least a combination of the input and output latency (more than a 10 msec delay with a 256 sample buffer @ 44.1 KHz).
Since the recorded track is not delayed that much(the delay is only in the order of samples), I think that means Cubase has shifted the recorded track earlier by a total of the Cubase-calculated [A/D + Output Buffer + D/A + Input Buffer] - and it did this automatically.
Cubase knows what the input latency is and it knows what the output latency is, thus it can compensate, any error will be due to delays outside the reported latency figures and outside Cubases control.
But (I think, especially with what Mr. Split had to say) we don’t have to move the tracks manually - Cubase does it for us! (except for the “invisible” delay that Jose was describing in the other thread Steinberg Loop Back test - how do I use it? - Cubase - Steinberg Forums , and which is able to be compensated for in Devices/Device Set Up/Advanced/Record shift ).
I think this is almost true. Cubase doesn’t shift things to an earlier position, but starts playback later, so we play along to a sound that actually took place earlier. Semantics, maybe, but since we have a thread of umpteen pages about MIDI being earlier, I think this should be said
Not that it’s a huge thing, but I think I come to a different conclusion. When I route audio out a hardware output, then record it as it is looped directly back into a hardware input … then look at the audio on the tracks - Cubase has physically placed the recorded track to within a few samples of the original source audio (using the ruler at the top). From this I think I conclude that the recorded audio was actually shifted early by Cubase (otherwise it would be about 10-11 msec after the source audio in my system).
But is there another way to interpret that observation that doesn’t include Cubase shifting any tracks?
You’re right, it may not be important, and if there’s no definite answer it’s not such a big deal, but if it’s something that can be understood without too much hassle from the info we have available now, I’m up for that!
Sorry but your different conclusion is the wrong one…Arjan’s explanation is correct.
Cubase knows the latency figure so it delays the playback of the monitored signal by that amount compared to the timeline & therefore anything you record while listening to the delayed playback is placed correctly in the timeline. There is no shifting of the recordings…the shift is of all of the already playing back tracks.
Actually, both Alexis and Arjan are correct. Remember, as Alexis points out, there is also a delay on the input side from the Input Buffer and the A/D converters, AND technically from any DSP that may be present in your interface (but this is of negligible amount - only a few samples). This means that Cubase has to move the audio signal being recorded and shift it back in time in order for it to be correctly placed on the timeline.
On the playback side, all that’s happening is that Cubase starts playback late by the amount of latency (buffer size) set in the Device Setup window. IOW, you hit playback, the computer starts processing the information first by the amount of time given by the buffer, then you hear it being played back. If you have heavy plugins inserted in the project, your playback will start even later based on how much Cubase has to delay things in order to keep everything in sync, which is done via Plugin Delay Compensation. In the end, what you hear is a delayed signal, which is why it is recommended to record with the lowest buffer size possible.
Hmmmnn…now I’m more confused…why would Cubase choose to delay playback & also advance recorded tracks after recording…wouldn’t just adding the 2 delays together & delaying playback by that amount do the same thing?
And regarding a recommendation to record at low buffers, of course this is important if you are attempting to monitor via cubase…but if we assume direct monitoring then surely the result is the same with any buffer size (assuming correct reporting across the range of buffer sizes)?
You have to keep in mind that the latency on Input is not the same as the latency on Output due to hidden buffers, as well as the difference in speed between the A/D and D/A conversions. For this reason, latency on the playback side is larger and thus why recorded tracks are moved back in time in Cubase. I remember there were times where tracks would end up being placed earlier in time when using WDM drivers in Sonar. I don’t remember exactly what caused this to happen, but apparently one could record ahead in time .
And regarding a recommendation to record at low buffers, of course this is important if you are attempting to monitor via cubase…but if we assume direct monitoring then surely the result is the same with any buffer size (assuming correct reporting across the range of buffer sizes)?
This is something I do not know since I never use direct monitoring. If you can, just try it out and see what happens. Set the latency high in Cubase, so you can clearly see if there is a delay, and record something using direct monitoring. Please, let us know your results if you decide to do this.
You have to keep in mind that the latency on Input is not the same as the latency on Output due to hidden buffers,
OK but I think by this you mean those hidden delays outside of Cubase control as discussed in the other thread that we can compensate ourselves using a loopback test & the record shift adjuster?
So not strictly anything we can expect Cubase to compensate…excepting where we have told it to.
Sorry not trying to be argumentative, have enjoyed the discussion…I’m just trying to get the best possible grasp on this. Not sure quite why I’m so interested in something so mundane
This is something I do not know since I never use direct monitoring. If you can, just try it out and see what happens. Set the latency high in Cubase, so you can clearly see if there is a delay, and record something using direct monitoring. Please, let us know your results if you decide to do this.
With direct monitoring, placement of recorded audio is still perfect at the highest latency my system will run & this is Cubase’ compensation doing exactly what it should.
Even with software monitoring at high latency I believe the record compensation must still work correctly…it’s what’s presented to it that is wrong as the monitored playback delay is now throwing your singing/playing.
I can also remember many years ago suffering the recordings placing early problem…& the confused question of one of my bandmates…“how on earth can it record me before I’ve played??”
.
) by clever programming.
). Still, it’d be nice to know what Cubase (vs other DAWs) does.
.