BUG: Match alternates out of Sync to AAF

[mfranken]

Originally Posted by SBP

The work around for us was not too arduous. [no re-rendering of files] -once we had it sorted .

Thanks Bruno. Good to know.

[audioinsight]

This is an issue which has been around as long as there have been EDLs coming out of a Media Composer & stuff being re-conformed on ANY DAW. The reason why I need another 2 days in the budget after a conform- before I can begin editing- to manually move every conformed region.

To my dismay, I have found that many of my colleagues have their head in the sand about this- with most saying that there is not enough time on a project to sample accurately re-align every clip by hand to the AAF/OMF- and that less than a frame of sync falls within some kind of magical 'threshold of acceptance' to most viewers. Or worse, many seem to think that using a tool like Titan's, "Fix Sync" - can "auto-magically" fix this problem (not true IMO as track assignments change- as well as which channels in the AAF). Others say that the clappers are never really properly in sync anyway if done by an assistant editor- so what difference does it make- as it is their job as a dialogue editor to put stuff in sync.

It is as Mark has said, that the Avid is accurate down to 2 fields every frame- whereas Pro Tools is sample accurate. So what happens when the Avid imports / digitises any media where recording did not begin on the round frame edge, it will round off & shift the timecode start- such that the file then starts on the closest round frame to where the recording began- thereby offsetting the actual timecode for every single bit of location sound compared to the rushes. Hencve then why the exported EDL has incorrect source time codes- or at least sample shifted.

Frank- I think the silence buffer in your example is a red herring here. Try another export from MC with different settings. Is this the original AAF Avid media without any handle length? That could be the Avid's way of doing a special sample accurate export- like PT does. I avoid truncated (man) handled media at all costs- always get a linked to AAF. I am just checking a couple of projects now, & there is no silence- file starts match on the waveforms. What differs is their embedded TC start.

I first brought this issue up with Avid well over 5 years ago. It is actually an extremely heated topic. The reason being, is that the solution suggests improving the audio engine inside of the Avid, such that it could edit down to the sample level. This would then potentially allow for more picture editors to do the work of audio editors. Hence why the conversation normally falls dead. Avid dont need to, & do we really want them to? It's something we have always dealt with (or not as it were). I'm not saying for one moment I agree with this- just saying what the general consensus seems to be.

I am currently trying to nail down some kind of definitive MC behaviour as regards the rounding off- so that maybe we can account for it automatically, with say Mark's Ediload software when creating the conform tracks. Like a threshold for when it moves audio left or right, & what the maximum sample offset is. If we know this behaviour, then maybe, just maybe, we can find a clever algorithm that phase aligns after the conform- to make sure that the AAF & conform are 100% sample accurate- without actually having to check the AAF track.

Or the other interim solution, seems to be to get every make of location sound recorder to only start recording on the round second. Although that does seem like a rather tall order. I am sure no-one cares if the recorder starts at the sample edge or on the round frame- but the Avid then wouldn't mess the timecodes up.

Either way, it's nice to see some other folk caring about this issue, & looking for a way to correct this horrid mess in the workflow.

I suspect FCP does it too. But FCP exports are beyond pathetic anyway- with the only option being embedded & truncated media on AAFs. Again though, to my constant surprise, this seems to be how so many dialogue editors ask for their exports. Near impossible to sync some waveforms if not clear peaks in the region or handles.

Hope that clears things up. The PT manual does actually point this out too on the chapter about working with field recorder media- although it breezes over the reason why it happens (naturally).

And before anyone mentions the good old days of DAT- it was EXACTLY the same then too..

Horrific, innit?

Mike Wabro

[Frank Kruse]

Originally Posted by audioinsight

This is an issue which has been around as long as there have been EDLs coming out of a Media Composer & stuff being re-conformed on ANY DAW. The reason why I need another 2 days in the budget after a conform- before I can begin editing- to manually move every conformed region.

To my dismay, I have found that many of my colleagues have their head in the sand about this- with most saying that there is not enough time on a project to sample accurately re-align every clip by hand to the AAF/OMF- and that less than a frame of sync falls within some kind of magical 'threshold of acceptance' to most viewers. Or worse, many seem to think that using a tool like Titan's, "Fix Sync" - can "auto-magically" fix this problem (not true IMO as track assignments change- as well as which channels in the AAF). Others say that the clappers are never really properly in sync anyway if done by an assistant editor- so what difference does it make- as it is their job as a dialogue editor to put stuff in sync.

It is as Mark has said, that the Avid is accurate down to 2 fields every frame- whereas Pro Tools is sample accurate. So what happens when the Avid imports / digitises any media where recording did not begin on the round frame edge, it will round off & shift the timecode start- such that the file then starts on the closest round frame to where the recording began- thereby offsetting the actual timecode for every single bit of location sound compared to the rushes. Hencve then why the exported EDL has incorrect source time codes- or at least sample shifted.

Frank- I think the silence buffer in your example is a red herring here. Try another export from MC with different settings. Is this the original AAF Avid media without any handle length? That could be the Avid's way of doing a special sample accurate export- like PT does. I avoid truncated (man) handled media at all costs- always get a linked to AAF. I am just checking a couple of projects now, & there is no silence- file starts match on the waveforms. What differs is their embedded TC start.

I first brought this issue up with Avid well over 5 years ago. It is actually an extremely heated topic. The reason being, is that the solution suggests improving the audio engine inside of the Avid, such that it could edit down to the sample level. This would then potentially allow for more picture editors to do the work of audio editors. Hence why the conversation normally falls dead. Avid dont need to, & do we really want them to? It's something we have always dealt with (or not as it were). I'm not saying for one moment I agree with this- just saying what the general consensus seems to be.

I am currently trying to nail down some kind of definitive MC behaviour as regards the rounding off- so that maybe we can account for it automatically, with say Mark's Ediload software when creating the conform tracks. Like a threshold for when it moves audio left or right, & what the maximum sample offset is. If we know this behaviour, then maybe, just maybe, we can find a clever algorithm that phase aligns after the conform- to make sure that the AAF & conform are 100% sample accurate- without actually having to check the AAF track.

Or the other interim solution, seems to be to get every make of location sound recorder to only start recording on the round second. Although that does seem like a rather tall order. I am sure no-one cares if the recorder starts at the sample edge or on the round frame- but the Avid then wouldn't mess the timecodes up.

Either way, it's nice to see some other folk caring about this issue, & looking for a way to correct this horrid mess in the workflow.

I suspect FCP does it too. But FCP exports are beyond pathetic anyway- with the only option being embedded & truncated media on AAFs. Again though, to my constant surprise, this seems to be how so many dialogue editors ask for their exports. Near impossible to sync some waveforms if not clear peaks in the region or handles.

Hope that clears things up. The PT manual does actually point this out too on the chapter about working with field recorder media- although it breezes over the reason why it happens (naturally).

And before anyone mentions the good old days of DAT- it was EXACTLY the same then too..

Horrific, innit?

Mike Wabro

Mike,

re-read my first posting to get your questions re: export settings answered.

I think this doesn't compare at all to the days of DAT because:

1) we don't "digitize" anymore. and the hand-syncing in the old days was because of slight clocking differences and accuracy of interlocking machines via RS422 during linear transfers. Back then maintaining sync down to fractions of frames were technical impossible. These times are long over. A file is a file is a file and it's copied and there's no linear transfer in the workflow in discussion.

2) This only happens with files created on Devas. Films recorded on SD, Aaton are bang-on down to the sample.

3) this is not about export errors. We are talking about a fully referenced workflow linking to original AVID media and then BWAV media.

I think Mark pretty much nailed the issue and I think Zaxcom should do something to their firmware.

Here's a response from one of the location sound forums:

I remember many deva/fusion users asking for files that start and stop with a 00 frame timestamp to Howy on the old yahoo devalist.

The answer from Howy was this : I was able to do this in the ZFR and TRX but when I went to do it in the Deva the pre-record feature got in the way of being able to choose exactly when you go into record. I would have to totally rewrite the pre-record mechanism to implement that feature. -howy

So from what I understand it seemed Zaxcom left it like it was, because the risk of rewriting the code was probably too high and probably new bugs could appear. Ths sad thing is that they also left it that way for the Nomad.

("Howy" is the programmer of the Deva firmware, btw.)

Mike, as you said poor dialog-editors have been quietly hand-syncing these errors for years because they simply assumed that things are still as they were in the DAT-days. But IMO, with tape-less workflow this doesn't have to be taken for granted at all and workflows involving other machines clearly proves this.
I think the AVID is actually pretty clever adding that zero-audio to work-around the Deva issue. Only problem is it assumes that the files at least start on full frames. I don't think anyone at AVID was aware of the fact that this particular machine starts it's files anywhere between frames. This makes no sense at all for a machine to record audio for film. This can cause all sorts of other additional issues when interlocking multiple machines via TC too.

Personally I will put more days into the auto-conform budget on films based on devas from now on. Now that it's clear what causes it.

Frank.

[audioinsight]

OK Frank,

I think there are 2 separate issues here.

I have re-read your first line. You suggest that this Deva isssue is the reason for all location sound mismatches to AAF. Whilst I do not disagree that there is something funky going on with the Deva workflow, the greater problem is relevant to ALL recorders that can record start on non-round timecodes- not just Deva. I am in essence agreeing with Mark- so you can't really agree with him, yet disagree with me.

AFAIC this problem lies with the Media Composer's inability to handle audio properly. It affects any & all AAF/ISO workflows. The true fix would be Avid not off-setting any timecodes ever- by allowing it the sample accurate. The workaround is either:

1) finding a way to 100% accurately undo what the Avid has done- eg via potential additional functionality in software like Ediload.
or
2) making every single sound recorder manufacturer- make all files recorded start on a round frame, & making sure that all recordists are aware of this & update firmwares as necessary. I cannot see that being a very quick fix- I would give that years before it settles & everyone is on the latest.
3) just let us all continue wasting our time fixing something that could clearly be done better & more efficiently than by hand.

Best,

Mike

[Frank Kruse]

Originally Posted by audioinsight

OK Frank,

I think there are 2 separate issues here.

I have re-read your first line. You suggest that this Deva isssue is the reason for all location sound mismatches to AAF.

Thing is: I haven't encountered any other tc-capable location machine yet that behaves like this. Maybe there are some but from the most common ones (Deva, Cantar, SD744, 788) only the deva files cause this particular issue. Maybe the ancient PD6 or the HHB of the Nagras do this as well, but I can't verify because I have never come across a project that was recorded on these machines.

I'm not implying that ALL sync issues come down to a deva involved. I'm saying that if there's a deva involved in the workflow you can be sure to encounter sync issues when using expand to track or other functions the field recorder workflow. And I'm not talking about FCP and any other NLE.

I'm talking about the workflow I posted in my first posting.

So apart from that I agree with what you say. Since the deva is one of the most used machines on set it makes the issue even worse because there's a TON of projects that involves these machines. It's not some exotic exception.

It makes perfect sense for a picture related audio recorder to sync file beginnings and ends on full frames regarding their samples after midnight stamp because interlock between machines, cameras is always frame-based. Never sample based. It's all based on TC and frames are the smallest grid in that world.

Hope this makes sense.

Wether it's quicker to make the MC sample-based or fixing this on the Zaxcom side I don't know. If the fix is similar to implementing bins in PT I'd rather make a bet on Zaxcom doing it ;-D

Frank.

[Frank Kruse]

Here's some news regarding this matter (well, sort of).

Since this discussion has spread across other forums incl. the Zaxcom forum Howy from Zaxcom has been in contact with Jeff Lomicka from AVID regarding a possible fix for this. AVID said it would be a difficult one for them to implement since AVID works frame-based.
I hope that this won't end up in a couple of years of pointing fingers at each other and then nothing will change.

In the meantime I have received test footage that was shot for an upcoming huge project. Actually a camera test with TC-slates in frame shooting with different cameras to test sync. Audio recorded on a Deva.

Exact same workflow as described in the OP of this thread. Result: exactly the same phenomenon. The footage pretty clearly proves that this boils down to a Deva being used as the recorder.

If someone from AVID reads this I'm happy to inquire with production regarding my NDA to send out the footage. It only shows a buch of clapper-loaders in a studio so no content of the actual film is contained. I can provide all the details. AVID MC version used and whatnot.

I think it's worth to advocate on booth fronts (AVID and Zaxcom) from editors and recordists to get rid of this issue as it's causing lots of work in post and is completely unnecessary, IMO.

Frank.

[Frank Kruse]

Update:

I heard that Zaxcom is working on changing their FW. Great news.

Frank.

[dieffe]

The Nagra VI has this problem too, see attachment.

Only the Sound Devices and the Cantar recorders close the recording on frame "edges".

[alexbooy]

I have checked my Sonosax SXR4. I have imported SXR4 tracks with Spot to original TC and the file doesn't start/end at frame bounderies. see attachment.
Alex

[Frank Kruse]

Thanks for the update guys. Luckily these machines are rather rare. At least in my hemisphere. YMMV.

Wouldn't hurt to notify Nagra and Sonosax about this if you are an owner of their gear.

Frank.