8.04cs2 WhoKnowsWTFWillHappen-ency bug

[MikeLip]

I would like to report that I am experiencing 44 (Edit: originally I said 28) samples late when recording using 8.04cs2 with Win7x64. (hwb64/LLM;48k). Sandra is below.

8.03cs2 (on Win32) is sample accurate - not even 1 sample out.

Edit: Testing on Pro Tools 9 gave 44 samples latency also. Same driver, I believe. Thanks Avid for your attention to this.

Mike.

[miketeachesclass]

I am also experiencing late audio in the timeline. This varies from 2 samples at the low end to slightly larger than the buffer size on the high end. Also, the behavior changed after closing a session and re-opening it.

[guitardom]

just an fyi,

if you are truly trying to post results to avid, buffer sizes and sample rates MUST be included in your post. as well as your test method. copying the procedures and doing them as such, especially as spkgtr has shown in the other thread on this issue is the best way. there are many variables to this problem and the only way your info is usable is if it is complete. using headphones to mics, tab to transient results and such are not acceptable by any means.

regardless i find having to type this due to the problem at hand is pretty pathetic, bad business practice as well as ethics on avids part.

[miketeachesclass]

Originally Posted by guitardom

just an fyi,

if you are truly trying to post results to avid, buffer sizes and sample rates MUST be included in your post. as well as your test method. copying the procedures and doing them as such, especially as spkgtr has shown in the other thread on this issue is the best way. there are many variables to this problem and the only way your info is usable is if it is complete. using headphones to mics, tab to transient results and such are not acceptable by any means.

regardless i find having to type this due to the problem at hand is pretty pathetic, bad business practice as well as ethics on avids part.

Agreed. I've got specifics and images, I just have to wait until I'm home to upload.

[MikeLip]

Originally Posted by guitardom

especially as spkgtr has shown in the other thread on this issue is the best way.using headphones to mics, tab to transient results and such are not acceptable by any means.

TtT is not reliable? Oh I'm sorry (and I never use that word).

Can you link to spkgtr method? (I'm hoping I'm wrong)

I did this:
* create a session with 1 click track, and 2 mono audio tracks
* bus the output of the click to the first audio track, arm the track and record it for 8 bars or so.
* disarm the track.
* mute the click track
* make sure you can hear the recorded click on playback
* set the output of the first track to one of the analog outs
* set the input of the second track to one of the analog ins
* patch a cable from the output you chose to the input you chose.
* Arm the second audio track
* record.

48k; hwb64/LLM.
'click' audio track: Tab To Transients to first click gives 1/2/000 = 23994
LoopBack track: TtT first click 1/2/001 = 24022

= 28 samples late

Same result with hwb1024/LLM.

Above is Win7x64 with x64 driver.
I did the same test on 8.03cs2 (on a Win32 pc, same 002) and it was zero samples out from the click. Pefect.

If I am doing this wrong, please let me know.
Mike.

[guitardom]

your method for testing is great. the problem is getting your exact results from ttt. go back to the new thread for the 8.04 cs2 and look at pics from spkgtr a few pages in and on the last page or so i type out a method and can copy it here if you want. but you should look at spkgtrs pics also. i do explain a bit about ttt, generic, yes, but its there.

[MikeLip]

I understand TtT is just an algorithm. I'll hunt for the thread, and I'll also go fire up the pc for a Sandra (i think its uninstalled atm). Cheers, I'll be back.
Mike.

[spkguitar]

"Wrong" is really a strong word. I wouldn't say that Tab to Transient is the "wrong" way to measure, but I will say that it is inaccurate and I will stand by that.

The reason why we use a click as the recorded material is that it produces a very obvious transient on the waveform. If that transient is off by even a little bit between the two tracks, zooming in to sample level will show that difference very obviously. The waveform peaks (and actually all of the other parts of the waveform) should line up perfectly (or at least that is what one would expect if using the term "sample accurate").
Setting the grid to a single sample allows you to select between the transient ("peak" in my example) points of the offset waveforms and get the difference in samples displayed in the counter as "Length". (no mind math necessary).

Here is my method for the MBox 2 Mini:

• create a new session
• create a click track
• create a send on the click track to bus 1
• set the output of the click track to output 1
• create 2 mono audio tracks
• set the input of the first mono audio track to bus 1
• set the output of the first mono audio track to output 2 (to prevent feedback)
• set the input of the second audio track to input 1
• set the output of the second audio track to output 2 (again, to prevent feedback)
• plug a cable from the physical output 1 of the Mini to the line input of input 1
• record arm both tracks
• record for a few bars
• zoom in to sample level of a particular click transient (I always choose the fourth, but never the first; you can shoose whichever one you want)
• with the grid set to a single sample, select between matching peaks in the waveform
• view the difference as "Length" in the counter

Testing for the other interfaces will be similar, you just might choose different I/O (I always chose 7 when doing this test when I had the 002R).

And here are my results:

• in a 48k session, at a buffer of 64, track 2 is 14 samples earlier than track 1
• in a 48k session, at a buffer of 64, track 2 is 1 sample later than track 1
• in a 48k session, at a buffer of 64, track 2 is 1 sample later than track 1
• in a 48k session, at a buffer of 64, track 2 is 1 sample later than track 1
• in a 48k session, at a buffer of 64, track 2 is 1 samples later than track 1

• in a 44.1k session, at a buffer of 64, track 2 is 4 samples earlier than track 1
• in a 44.1k session, at a buffer of 64, track 2 is 13 samples later than track 1
• in a 44.1k session, at a buffer of 64, track 2 is 26 samples later than track 1
• in a 44.1k session, at a buffer of 64, track 2 is 26 samples later than track 1
• in a 44.1k session, at a buffer of 64, track 2 is 26 samples later than track 1

[guitardom]

Originally Posted by spkguitar

"Wrong" is really a strong word. I wouldn't say that Tab to Transient is the "wrong" way to measure, but I will say that it is inaccurate and I will stand by that.

thanks for doing all that. there are WAY to many variables and ways people are doing this and coming up with to many numbers. on my ipod so hard to copy and paste and such!

i say wrong, you say inaccurate, avid says "Huh?? what you talking about"

[MikeLip]

I think this is your post:

"zooming in and analyzing the waveform start is the ONLY way to properly detect how far you are off. then typically zoom all the way in and start nudging the new recorded track back in samples till you get it lined up as well as you possibly can or hilight the difference between waveform starts and have your display reading samples as shawn has. running through anything other than a line input can and will distort your waveform and possibly alter your results. actually even line inputs will slightly dirty up the signal.
AGAIN TAB TO TRANSIENT IS NOT THE PROPER WAY TO CHECK THE ALIGMENT OF YOUR WAVEFORMS IN THE TIMELINE. "

And then spkguitar:

Page 6: http://duc.digidesign.com/showthread...=284391&page=6

Spk is getting "in a 44.1k session, at a buffer of 64, track 2 is 26 samples later than track 1".

I have been using TtT for the numbers. Yes agree visual is best, I'll look to provide that (with a new Sandra), but in the meantime I think Spk's post shows the problem very well.

Mike.