Audio not in sync

[shivermetimbers]

Arrgghhhh,

 

I did this to one of those kung fu movies (where the voice and mouth are out of sync) and after the adjustments the voices were in sync with the mouth movements and it kinda ruined the whole movie...

 

 

[ski]

Deep breath... hold it... hold it... hold it... let go...

 

Aaaaaahhhhhhh......

 

hey ski ...

 

Could I do this in mono??

 

Yes, but...

 

I was thinking that I could just record a mono midi track, and then just boune mono and import that to the arrange window [snip]

 

Bouncing audio and then bringing it back into the arrange window doesn't result in a recording that includes the amount of delay introduced by your interface/blah blah blah. The only way you can get your recording delay setting set properly is to do a loopback test.

 

Hope that makes sense. If not, post back.

 

@Shivermetimbers, LOL!!

[darkecho]

I mean that I did this process and the resulting audio is aligned at the most equal-phase position possible when I move the anchor around. I flip the phase and shift the anchor and it only gets louder either direction I go, as in, I have no delay in the system!

 

I don't know what I am doing wrong. I can never quite get the sound to cancel completely no matter what I do.

[Ploki]

hey.. just one question.

i did a loopback on S/PDIF, and what i recorded was EARLIER in time than the original!

i had to move it BAKCWARDS to get complete cancelation, i did the MAX zoom in the arrange, and it was about 8 samples IN FRONT. i turned off PDC for "all", turned of software monitoring

buffer size 128

:S i dont get it

 

should i try the analog ports? i mean, it makes no sense that without recording delay compensation even enabled i get audio recorder EARLIER than it even is played

[m-m-m]

I was thinking that I could just record a mono midi track, and then just boune mono and import that to the arrange window [snip]

 

Bouncing audio and then bringing it back into the arrange window doesn't result in a recording that includes the amount of delay introduced by your interface/blah blah blah. The only way you can get your recording delay setting set properly is to do a loopback test.

I'm not 100% sure, but I think that you misunderstood the part that you quoted above.

What I meant was to bounce a midi region to create an audio region for use in the loopback (as the original source that gets fed into the input of my interface and then loopedback). I was thinking Klopfgeist (sp?) ... nice clean transients!

 

 

Loopback, loopback, loopback, loopback .... if you say it enough the word looses all meaning.

[Ploki]

pardon me, i was doing the first check 6AM in the morning...

i must have screwed something up or mixed the tracks..

 

8 msec @ 88200 Hz via S/PDIF :S

thats a bit much isnt it.

and then i have to change the settings everytime i work at different sample rate?

anyone listed automatic delay compensation under new features suggestions?

 

anyway, i dont have two balanced patch cables on me right now, but, is the delay compensation the same with the Analong i/o? spdif doesnt make any conversion and analog io does...

[leahbasskitten]

i'm actually kinda shocked i understood most of this, but i do have an interesting angle that would help me if i understood...

 

so, instead of a mic, i'm direct in with a... lets say a bass. There is no room for delay like a cowbell being across the room. now there is latency caused more likely by the audio device, maybe some plugins. i know that i use ski's patent pending Human Delay Compensation technology.

 

crap, i think i answered my own question, but i've gone this far.... i was going to say, then am i recording the latency i hear, or what it actually what i was playing. BUT, the latency would be caused by the device, what i heard is what is being laid down.

 

well, let me ask another question (i'm sure the answer is the obvious). lets say its software causing this delay such as a plugin, or maybe logic itself. now what i hear from monitoring logic even if its just some amp sim, what i'm hearing is different then what i'm playing, and what i'm hearing is also different from logic is scribbling down.

 

is there away around this? i mean, i can't play a naked guitar sound in the middle of a rock song, it just takes away from the groove. do people have their low latency guitar patches, and then spruce it up later?

[ski]

I mean that I did this process and the resulting audio is aligned at the most equal-phase position possible when I move the anchor around.

 

Are you basing this on the visual display you're seeing in the arrange window, zoomed in all the way so that you can compare the waveform display of the two different tracks (original and looped-back)? If not, how are you determining this? (See #2 below).

 

I flip the phase and shift the anchor and it only gets louder either direction I go, as in, I have no delay in the system!

 

I don't know what I am doing wrong. I can never quite get the sound to cancel completely no matter what I do.

 

Maybe... just maybe... based on what you're saying, it's possible that your recording delay setting is already at an ideal setting. But then again, maybe not... Not being able to get it cancel completely means one or two things:

 

1) there's a level (or tonal) discrepancy between original and looped-back recording

 

2) you've got your waveforms aligned to a point that isn't at the right place and the nature of the signal is such that you're able to get partial cancellation anyway.

 

Regarding #1, one way to determine this is to normalize both the original and looped-back recordings. See if you get cancellation afterwards...

 

Regarding #2, post a screenshot of your arrange page showing the first cycle of the waveform on both your original and looped-back tracks.

[ski]

hey.. just one question.

i did a loopback on S/PDIF, and what i recorded was EARLIER in time than the original!

i had to move it BAKCWARDS to get complete cancelation, i did the MAX zoom in the arrange, and it was about 8 samples IN FRONT. i turned off PDC for "all", turned of software monitoring

buffer size 128

:S i dont get it

 

should i try the analog ports? i mean, it makes no sense that without recording delay compensation even enabled i get audio recorder EARLIER than it even is played

 

On some systems the looped-back signal will indeed be earlier. I recall this being the case with certain RME audio systems, though I don't recall which ones. So it's not unheard of that your recording delay will have to be a positive number rather than a negative number.

 

I also wouldn't be surprised if the SPDIF loopback exhibits a different loopback latency than an analog loopback. That's because a SPDIF loopback doesn't require time-consuming A/D and D/A conversion.

 

Keeping in mind the ol' mantra of "never say never"... I don't think there'd be too much reason to loopback digital signals (like SPDIF out--->SPDIF in), though it's worth investigating how much recording delay there is in the event you did have to do lots of that kind of thing. But anyway, probably the more common reason for having a properly calibrated recording delay setting is to compensate for the latency introduced into the positioning of analog signals once they're converted to digital, i.e., anything analog that's coming into your audio interface and getting converted to digital audio.

[Ploki]

thanks for the reply

just figured out i only need one cable anyway, since i have symmetrical 8 in/outs, so there is really no reason to record stereo, otherwise everthing would go to hell for every added input, and if THAT happens, well, as far as im concerned, i can throw this away!.

 

i did it on S/PDIF to get sample accurate loopback (i actually cancelled out everything completely, i guess that works A OK.

 

yeah sorry, i actually read your whole post but had too little time on my hands to reply

 

will calibrate analong asap.. if only AudioFW would crash every 35minutes...

[darkecho]

I mean that I did this process and the resulting audio is aligned at the most equal-phase position possible when I move the anchor around.

 

Are you basing this on the visual display you're seeing in the arrange window, zoomed in all the way so that you can compare the waveform display of the two different tracks (original and looped-back)? If not, how are you determining this? (See #2 below).

 

I flip the phase and shift the anchor and it only gets louder either direction I go, as in, I have no delay in the system!

 

I don't know what I am doing wrong. I can never quite get the sound to cancel completely no matter what I do.

 

Maybe... just maybe... based on what you're saying, it's possible that your recording delay setting is already at an ideal setting. But then again, maybe not... Not being able to get it cancel completely means one or two things:

 

1) there's a level (or tonal) discrepancy between original and looped-back recording

 

2) you've got your waveforms aligned to a point that isn't at the right place and the nature of the signal is such that you're able to get partial cancellation anyway.

 

Regarding #1, one way to determine this is to normalize both the original and looped-back recordings. See if you get cancellation afterwards...

 

Regarding #2, post a screenshot of your arrange page showing the first cycle of the waveform on both your original and looped-back tracks.

 

I was using the sample editor to move the anchor point of the second audio track around. You mean I should zoom in all the way in the Arrange view on both tracks and change the increments to samples in THAT view? I will try that.

 

I checked my preferences and the recording delay is at 0ms.

[darkecho]

I did the experiment again using the arrangewindow and got the same results..

 

it wasnt completely cancelled out, definately lots of phase cancellation going on but not entirely.

 

any move a sample to the left or right gets louder. I guess my recording delay is 0?

[torsig1967]

Strange as it may seem, neither buffer size settings (nor process buffer range settings) affect the recording delay calculation. In fact, after reading your post I did some tests to double-check this and I can confirm this is the case. At least on my system it is.

 

I can confirm this to be true on my system too (Motu Traveler).

 

There's an alternative to the phase cancelation procedure that I find even easier. Using audio with transient sounds pan the original audio channel to L and the recorded audio channel to R - bounce and then measure the delay in sample edit. The transient makes the measurement easy in the waveform. (Sorry don't have time to write the full manual for this...)

[Philip Williams]

Hey Guys Im new here. Thanks for all of the information.

[ski]

I did the experiment again using the arrangewindow and got the same results..

 

it wasnt completely cancelled out, definately lots of phase cancellation going on but not entirely.

 

any move a sample to the left or right gets louder. I guess my recording delay is 0?

 

darkecho,

 

Sorry to take so long to get back to you. I'm still at a loss as to why you're not able to get perfect phase cancellation. But if you're getting close to null that might be good enough. By the sounds of it you might only be a few samples off, and no one's going to notice that.

[darkecho]

Thanks, I am going to try this test again now that the 8.0.2 update has come out.

Who knows, maybe something changed. At least the recording delay shows milliseconds now =).

[amnestic]

 

4. Use patch cables to connect outputs 1&2 of your audio interface to inputs 1/2

 

 

Ski, am I able to achieve this with a Tascam US-122 A/I?

 

My outputs are either a headphone jack, or the two Line Outs that are RCA (as seen in this image), while my ins are all 1/4" or XLR, as seen in this image.

 

What would I need to do to be able to test the recording delay setting?

 

 

EDIT: Or maybe I should stick to the Direct Monitor on the Tascam (I just prefer to record vocals while hearing a bit of verb, is all)?

 

http://www.tascam.com/i-68-17-64-0-994B22DE.jpg

[amnestic]

I just wanted to add, separately from my post above, that the more I get into Logic, the more I realize that the program is a lot like life itself. That is, the closer you think you get to understanding it, the more complicated things become, as more questions start to spring up.

 

Now, I totally agree that the joy of life is the act of struggle and search for answers, and that nothing comes easy, and that hard work pays off, and so on, and so forth.

 

But when you just want to sit down and write a song, experiment with different sounds, and not have anything ruin your flow of creativity (i.e. worries about latency, core overloads, etc.)... Man, what ever happened to that?

 

In any case, I'll just keep on keepin' on. End rant. 8)

[fader8]

But when you just want to sit down and write a song, experiment with different sounds, and not have anything ruin your flow of creativity (i.e. worries about latency, core overloads, etc.)... Man, what ever happened to that?

 

In any case, I'll just keep on keepin' on. End rant. 8)

That's not really a rant, more of a valid observation. The answer is a compromise though. If you invest some time in setting up some good usable templates, it can go a long way toward preserving the spontaneity and making life easier too.

 

It's a good pastime to get you through those blockage periods too!

[leko]

I just have to say to you all, thank you for this post. It is very helpful.

 

One question, is there a way to get this to work for an aggregate audio device? when you set one of those up (the cheap way, not using a timeclock), are you subject to the different drivers of the different hardware?

 

I have not had a chance to try this yet so it may be a moot point. Just a thought I had about my current setup: M-audio fasttrack, and zoom guitar pedal usb input (it is tube though, so some day I may get saucy and experiment with a mic through it, I may be sorely disappointed but who knows).

 

I know this is quite less than ideal, but my firewire device Kicked the bucket so, that is what I have until the bankroll flows.

[ski]

am I able to achieve this...

 

I don't see why not. Do your test between the RCA and 1/4" jacks. Use an RCA to 1/4" cable, two 1/4" cables with RCA adapters on one end, or dual RCA cables with 1/4" adapters on one end.

 

I looked over the specs of the unit (thanks for providing a link, BTW, very helpful ) and I see that your inputs can be set to either line or guitar level. Set them to line level.

 

Next, I see there are gain pots on each input. You'll want to try and calibrate them so that the level of the signal you're playing out of Logic comes back in to Logic at the same level. (Post back if you want details).

 

What would I need to do to be able to test the recording delay setting?

 

Any material that has some kind of percussive nature to it. Anything with a beat, hard rhythmic guitar part, etc. So as much as I love Enya, I wouldn't recommend her music for this test.

 

EDIT: Or maybe I should stick to the Direct Monitor on the Tascam (I just prefer to record vocals while hearing a bit of verb, is all)?

 

OK, Direct Monitoring and recording latency are two different animals. The reason you want to set the recording delay is so whatever you record ends up being in time. It's kind of like this... Here's a metronome click:

 

|_______|_______|_______|_______

 

Now let's say that you record yourself clicking two drum sticks together, and your timing is so good that you play perfectly in time with that click. What you should see is this:

 

metronome

|_______|_______|_______|_______

 

drum sticks

|_______|_______|_______|_______

 

Note how the peaks are perfectly aligned. That's how the waveforms should look. But all this A/D and interface driver latency will likely end up making your recording late:

 

metronome

|_______|_______|_______|_______

 

drum sticks

     |_______|_______|_______|_______

 

 

It's not because you played out of time -- it's because the recorded data ends up being placed later against the click than it should be because nothing is compensating for the delay inherent in A/D conversion etc. So as far as Logic is concerned, the audio data arrives on time, but in reality it's late against the click. Here's that same picture again:

 

metronome

|_______|_______|_______|_______

 

drum sticks

____|_______|_______|_______|_______

 

This time I highlighted the amount of latency in blue. Let's say that's 5 samples. Somehow Logic needs to know that it "costs" 5 samples worth of time for signal to arrive into Logic from the interface. That's what the recording delay parameter is for. If you set this to -5 samples, Logic knows that when it receives audio that it should place it 5 samples early. The result is this...

 

metronome

|_______|_______|_______|_______

 

drum sticks

|_______|_______|_______|_______

 

...just as it should be!!

 

 

Now, the idea of Direct Monitoring is a whole other ball of wax. Direct Monitoring is a feature where your live input to the audio interface is fed directly back to your headphones (or whatever) via hardware. This is old school, in a sense, but it makes the most sense. You sing something and you hear it instantly -- "live" -- just like the old days before these crazy kids came by with their whatzits and hoozits and newfangled computers and screwed everything up... . With Direct Monitoring, the signal never has to go into Logic and then back out in order for you to hear it (and that's what software monitoring is all about). With software monitoring, you don't hear the signal 100% live --- there's always a bit of a delay, even if it's small. With Direct Monitoring there is no delay.

[amnestic]

Ski, thank you so much for your reply. Very, very helpful. Especially the diagrams!

 

Now, a few things:

 

Next, I see there are gain pots on each input. You'll want to try and calibrate them so that the level of the signal you're playing out of Logic comes back in to Logic at the same level. (Post back if you want details).

 

Yes, please do send me some info on how to properly calibrate. I'm sorry to waste more of your time.

 

Secondly: So, if some people out there never adjust their recording delay setting, they will always find their recordings out of time with the click, even with Low Latency Mode and Plug-In Delay Compensation, and all that jazz? That's quite surprising to me, actually!

 

With Direct Monitoring, the signal never has to go into Logic and then back out in order for you to hear it "live". BTW, that's what software monitoring is all about.

 

Oh, so even though you're not hearing any latency with DM, Logic is still recording the signal a few ticks off? Now I understand. However, I thought Software Monitoring was separate from Direct Monitoring, in the fact that I can still hear the plug-ins on the channel strip while recording with SM on. I thought that SM might create more latency because it's all based around the signal going into Logic and Logic sending the signal back out into my headphones. Am I wrong with this understanding?

 

I really appreciate you taking the time, ski. Oh, and before I forget: thanks in advance.

 

(You knew you'd open up a new can of worms with that thread, right? )

[ski]

amnestic,

 

Ah, but you are sooooooooo welcome! (in advance, of course).

 

(reply forthcoming...)

8)

[ski]

glad that all made sense!

 

To calibrate your inputs:

 

(software monitoring needs to be off for this -- very important)

 

• add a stereo track to Logic on track 1 (Audio 1), preferably something that's dynamic and has good percussive peaks, level = 0dB

• route it to output 1/2, level = 0dB

• patch your interface's outputs back into the inputs

• set up track 2 (Audio 2) to record inputs 1/2 and hit the REC button on that track

• play it down and compare the meters between Audio 1 and Audio 2. Adjust the input controls on your interface until the levels match as closely as possible

 

Secondly: So, if some people out there never adjust their recording delay setting, they will always find their recordings out of time with the click, even with Low Latency Mode and Plug-In Delay Compensation, and all that jazz? That's quite surprising to me, actually!

 

The recording delay is a separate issue from everything else. Yes, I'm convinced that there are lots and lots of people out there who aren't aware that the recording delay setting needs to be calibrated on their systems. It's true that some systems don't require this. As Eric Bradley reported in one of his posts, he did a loopback test with his RME gear and found that he could keep his recording delay at 0 samples. But this is definitely not the case with lots of other interfaces out there. Mine is set to -27 samples, as is one of my writing partner's system (same interface, same digital board, only he's running DP).

 

So on any system where the recording delay isn't fine at a setting of zero, anyone who hasn't done this calibration will likely be hearing back their recorded audio late. Sometimes it'll only be a few samples. Other times it'll be up in 10's to 100's of milliseconds range. But throwing off a groove by even 10 milliseconds can kill it to death and beyond.

 

With Direct Monitoring, the signal never has to go into Logic and then back out in order for you to hear it "live". BTW, that's what software monitoring is all about.

 

Oh, so even though you're not hearing any latency with DM, Logic is still recording the signal a few ticks off?

 

Yes. Exactly.

 

I thought Software Monitoring was separate from Direct Monitoring, in the fact that I can still hear the plug-ins on the channel strip while recording with SM on. I thought that SM might create more latency because it's all based around the signal going into Logic and Logic sending the signal back out into my headphones. Am I wrong with this understanding?

 

No, you have it exactly right! The thing about using Direct Monitoring is that you won't hear your input processed through any plugins.

 

Oh, and thanks in advance for any thanks in advance that you might offer in any future posts at any point in the near or distant future.

[amnestic]

This is awesome! Very helpful, ski. And it slowly pushes those "overwhelmed" feelings away. Thank you!

 

To think about someone coming into Logic right now, I cannot even begin to understand how much they have to learn before they can use this program effectively. From Plug-in Delay Compensation, to Low Latency Monitor, to Recording Delay Compensation.... Phew! And I bet I'm not even close to properly adjusting my settings in order to record without hassles. In two weeks time, I'll find out that I still need to calibrate the Logic Flux Capacitor to 88 ticks, so that my recording doesn't get sucked into a black-hole of crappiness. And then in a month's time, I will find out that I have to set my buffer settings to 1.21 Gigawatts, so that I can avoid core overloads.

 

Sometimes it's all a bit too much.

 

In any case, I will get the proper cables/adapters tomorrow, give your instructions a go, and I will let you know my success rate, on a scale between 1 and 10. Heh, heh.

 

I thought Software Monitoring was separate from Direct Monitoring, in the fact that I can still hear the plug-ins on the channel strip while recording with SM on. I thought that SM might create more latency because it's all based around the signal going into Logic and Logic sending the signal back out into my headphones. Am I wrong with this understanding?

 

No, you have it exactly right! The thing about using Direct Monitoring is that you won't hear your input processed through any plugins.

 

Just to clear it up for myself: So, am I correct in assuming that Software Monitoring does create some latency between the audio in Logic, and the sound that you hear coming through your phones? Hence, Direct Monitoring would be the least latency inducing method of hearing the signal while tracking vocals, for example?

 

(Although, of course, you won't be able to hear the reverb plug-in, for instance, that you will be using in the channel strip-- which, for some reason, is something I don't like doing, as I really like to hear my own voice a little wet rather than 100% dry, but maybe that's just me...)

 

I am thanking you with advances.

[Ploki]

i forgot, can someone please remind me,

how do you calculate buffersize into sample latency

[eqjacob]

Intriguing process for getting to an exact number for recording delay. I'm going to try it tonight.

 

Here's an interesting twist - in the Tascam US-1641 manual, it gives values for delay for both 44.1kHz recording and 96kHz.

They are listed as:

 

≤.63ms (ADC) ≤.44ms (DAC) at 44.1kHz

≤.29ms (ADC) ≤.20ms (DAC) at 96kHz

 

(if they don't show up, there's "less-than-or-equal-to" symbols before each of the ms values.)

 

Would the first value, second value, or potentially both numbers combined lead to a good starting point? My line of thinking would be that only the first value would be needed as a starting point, but I'm still pretty new to this depth of technical information.

[fader8]

Just a suggestion for a test signal. I've used this for measuring all kinds of delay parameters, especially when setting up external samplers, effects . . .

 

Insert a Test Oscillator on an instrument track. Set it to Needle Pulse. Bounce a couple of beats to a new file.

 

In the Sample Editor, delete all the pulses except for one. Now you have a nearly perfect little tick. Load it up on a track!

 

It's super handy for pinging an external effects chain, then measuring the delta in samples in the sample editor after bouncing through it.

[ski]

i forgot, can someone please remind me,

how do you calculate buffersize into sample latency

 

Buffer size has no bearing on the recording delay value.

 

Intriguing process for getting to an exact number for recording delay. I'm going to try it tonight.

 

Here's an interesting twist - in the Tascam US-1641 manual, it gives values for delay for both 44.1kHz recording and 96kHz.

They are listed as:

 

?.63ms (ADC) ?.44ms (DAC) at 44.1kHz

?.29ms (ADC) ?.20ms (DAC) at 96kHz

 

(if they don't show up, there's "less-than-or-equal-to" symbols before each of the ms values.)

 

Would the first value, second value, or potentially both numbers combined lead to a good starting point? My line of thinking would be that only the first value would be needed as a starting point, but I'm still pretty new to this depth of technical information.

 

Ah! this is good stuff!

 

Let's see how the numbers translate:

 

@ 44.1K, one sample lasts approx. 0.0227 milliseconds

 

Doing the math on the analog recording spec (ADC), .63 milliseconds (per the spec) divided by .0227 = approximately 28 samples.

 

Doing the math on the digital to analog spec (DAC), .44 milliseconds (per the spec) divided by .0227 = approximately 19 samples.

 

Per this DAC spec, what it shows is that there's an inherent 19 samples (less than .5 millisecond) of inevitable delay from the time Logic outputs audio data to the audio interface to when the audio interface actually outputs it as an analog signal. This isn't something we've looked at in this thread yet, but probably worth talking about at some point. Still, it's a very good spec -- half a millisecond!

 

My feeling, based on the fact that I've only been up for a while, not even down to the end of my first cup of coffee and brain feels like it's in second gear, is that your total round trip latency will be around 47 samples. At 44.1K that's only a teensy bit over 1 millisecond, and equivalent to the delay you've have playing any MIDI instrument from a controller. It's an amount that's truly negligible for most applications. And if memory serves, it's a better spec than the Apogee Symphony system at 44.1K. In other words, on paper, the Tascam's specs are really excellent.

 

Is it worth going through the trouble of doing the recording delay calibration for so few samples? I'd say "yes". You can't always go by the manufacturer's printed specs. Besides, for years the Logic manual has stated that it's not necessary to even calibrate the recording delay parameter! So you can't always believe everything you read.

 

eqjacob, if you do go through the test, please post back with your results.

Edited May 29, 2008 by ski

[perversity]

I'm wondering, with the advanced integration of Apogee products with Logic is it possible that the recording delay is somehow pre-calculated, and that's why people using duets can't get a complete cancellation. Any thoughts ski?