With thanks to the original author Michael Maroussas for allowing us to re-publish this discussion from his blog Sonicskepsi, it seems that there is a strange issue with Media Composer moving audio around, so over to Michael….
Expanding tracks in Pro Tools was like the holy grail to us dialogue editors when it came along. No more messing about with EDLs and basically having to rebuild the picture editor’s sound arrangement. When conforming from EDLs, it could take you the best part of a week just to get your session to match what was in the corresponding OMF. So, the possibility of simply ‘expanding’ a linked AAF to create a perfect copy of the Media Composer audio tracks but with all the separate mic channels reinstated as well was very exciting indeed.
Many a time it works perfectly, but too often the expand seems to work - all the mic channels appear - but there’ll be a fractional and inconsistent discrepancy in sync. For a while, no-one that I knew could figure out why Pro Tools does this - we humble sound editors tend to presume things like this must be our or our tools’ fault :)
So then you have to either use Titan sync fix to correct the discrepancy (which is fine except for sections with no distinguishable transients for the program to recognise and match) or we have to correct the sync manually ourselves, which basically turns an exciting new feature into a creator of dull, laborious, time-wasting extra work.
This was the prospect facing a work colleague of mine recently, so he asked me if I’d see if anybody had any better alternatives to Titan sync fix; it wasn’t working very well for him on this occasion so he was facing the distinct possibility of having to manually sync the session himself. However, before I put the call out, we had one last look at the different clips within the session and compared their original timestamps and suddenly the penny seemed to drop! It’s the MXF files in the linked AAF that are out of sync, not the original WAV files on the tracks expanded from it - Pro Tools is correct, Media Composer is out - so all this time we’ve been ‘fixing sync’ but by matching the AAF or guide track we’ve actually been pulling our sound out of sync!!! At least, this is my opinion…..
All is explained below in this almost verbatim (I’ve corrected ‘twitter speak’ in places to help clarity) transcript of the subsequent chat I had on Twitter with Davide Favargiotti in Rome and Doug Murray in the States. As you’ll see, Davide and Doug are not totally convinced (neither is my work colleague) but to me it seems to be proven by the numbers involved. Decide for yourselves; feel free to shoot holes in my argument if you can - I want my theory thoroughly road tested by you lot before the start of my next job!
MM: Monday morning question for you all: anyone got a clever alt solution to loose sync when expanding tracks in PT other than Titan sync fix?
DF: an intern to fix the sync? :) What recorder did the mixer use? it could be an issue with the recorder. Nagra and zaxcom have this problem.
MM: I wish! It was a Deva, so your theory is still intact. :)
DF: it’s a bug: devas and Nagra don’t close files on frame edges. MC fill the missing audio - this means that pd and aaf media are different. Your media could be out of sync +-1 frame.
MM: so if your theory is correct davide then our expanded tracks are actually in sync and the editor’s aaf is out?
DF: nope. Did he use autosync in MC? If not, the guide and AAF are in sync. If he used auto sync, everything could be off.
MM: dunno yet but I presume auto sync is normally used?
DF: check it: take the same clip from AAF and PD. Go to the end of both files. The AAF has some ‘silent’ bits at the end?
MM: exactly, the front of the aaf file is snapped to nearest frame then the difference at the end is filled with silence. Therefore, MC is manipulating orig audio & so isn’t true sync anymore? The pic hasn’t undergone same shift in MC?
DF: you’re fxxked, mate. :) it’s a good time to get yourself some apprentice or intern :)
MM: :D it’s ok I’ve just used Titan fix sync this time but my argument I’m suggesting is did I really need to fix sync? i.e. are my expanded tracks true sync & the MC AAF is fractionally out of sync?
DF: if the assistant editor manually synced the clip, inside MC everything is in sync. (And all the export too, aaf and gt). (or better…They have the sync that the assistant editor choose).
MM: so we could test this by getting asst ed to manually sync a scene then check it against our expanded tracks.
DF: …If auto sync was used in MC could be slightly out of sync too.
MM: auto sync isn’t what alters the audio file though? That just positions it, if audio file wasn’t altered pt would be the same
DF: nope. Importing audio files into MC alters them, if they aren’t closed on frame edges.
MM: so the case I’m suggesting to you is pt expanded tracks linked to rushes are not out of sync as they & the pic have not been ‘altered’.
DF: the problem is that PT gets the TC from the AAF files. So you’re relying on something that has frame accuracy at most. Check this on the DUC.
MM: going through the duc thread thoroughly, so far I’m with mark franken
DF: So, what’s the correct sync? PT expanded tracks? but doesn’t PT get the TC from the AAF?
MM: exactly, that’s my line of thought. i.e. that the start position of audio in MC is shifted but it’s orig time stamp remains true, so when we expand tracks, rushes are true. If this is correct, the pt expand would have to be agreed (with editor) as the main sync reference for sound. I drew a pic to try to explain what I’m saying better. Feel free to shoot holes in it if I’m missing something.
DF: I’m not sure. It could be. You can’t know for sure how much the file has been moved ahead by MC
MM:True, I don’t know this for sure, but I do know MC is definitely altering the audio file and PT isn’t. I know MC definitely isn’t absolutely sample accurate orig sync but PT might / could be. @Avid, can you confirm if this is the case (…no response came…)
MM: Using info in Wave Agent to prove Pro Tools is in sync, and MC is out? See below:
(Doug Murray gets involved in the chat at this stage)
MM: Do you agree that the PT expanded tracks are more accurate sync than the MC AAF, Doug? & that therefore us dialogue editors shouldn’t be resyncing our expanded tracks to match an out of sync AAF? Have we been following a false God all this time? Are we actually the true Gods of Sync?! :) If so I’m looking forward to my ADR now being up to half a frame more accurate!
DF: I’m not convinced yet of this new god to worship. :) I’d like to know where PT gets the pos ref to expand tracks.
MM: Don’t the orig time stamp diffs between the AAF & WAV file prove the WAV is correct?
DM: If the syncing is done in MC, then the AAF is most accurate. If done elsewhere, then I don’t know.
MM: How so if MC is a frame accurate system dealing with sample accurate data?
DM: If syncing is done in MC with clapboard as the means, then AAF best. If orig time stamp is means then pd best.
DF: yeah, this makes sense to me too…either case aaf and PT are never in sync (with devas and nagras)
MM: Are you saying if editor manually syncs in MC = AAF most accurate sync? & if he uses auto sync in MC = PD in PT most accurate?
DM: Yes. That makes sense to me. TC sample accurate on autosync but AAF sync ref most accurate even if only frame accurate on man.
MM: Hmm, think I disagree - MC is only frame accurate either way? I guess I’m saying I’d prefer auto sync as it changes the MXF timestamp relatively, enabling PT WAV to retain it’s true pos ref. Manual sync doesn’t change the MXF orig timestamp (correct?) so PT WAV will move with it: out of sync to nearest frame. We feel safer that way coz our WAV now matches the AAF, but it (& the AAF) are now both fractionally out of sync. This is all putting aside the additional ambiguities & potential for human error that are possible with manual sync.
DM: Does MC take the 1st whole frame of TC & call it the 1st frame? or the 1st partial frame? i.e. rest amp early or late?
MM: start of clip snaps to start of nearest frame but my understanding is the orig TC stamp stays intact relative to the timeline. Hence why I believe the wav in PT with it’s unaltered orig time stamp retains it’s correct positioning on the timeline.
DM: Nearest? I think it’s consistently early or late. Can’t remember which. MC def restamps code - which is cause of problem!
MM: No I think my example in my 2nd pic I tweeted the other day proves MC snaps audio later too, whichever frame edge is nearest. I agree MC def restamps orig TC, but relatively, so I’m suggesting it’s a good thing for us rather than a problem as such.
So that was their discussion - Michael’s conclusion from all this is that, potentially, we (dialogue editors) shouldn’t be automatically resyncing to AAFs made in Media Composer. Obviously if your audio is out of sync by a few seconds or more then you’ve got a different problem going on but I’d say if your working on a project shot on a Nagra or Deva and the sync is loose by no more than half a frame (early or late) when you expand tracks from an AAF made by Media Composer using autosync then it seems a pretty safe bet to me that the difference in sync is the alteration that Media Composer has made to the sound rushes when loaded in. Media Composer is out of sync, not Pro Tools, so why follow that as true sync when it could be up to half a frame out of sync?
Please feel free to add your two cents - Michael is happy to admit he is wrong if someone else can prove otherwise. We need to get to the bottom of this problem once and for all!
Simon Sherbourne from Avid UK has confirmed that a new preference (“Subframe Alignment to Broadcast Wav Start Time”) is on by default in MC7.04 and MC8 solves this issue. Michael Maroussas you have your answer. The editor needs to use Media Composer 7.04 or v8 to resolve this issue.