Skip to content

Media Composer Shifts Audio Out of Sync: A Discussion

March 11, 2014


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 seem to 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 a couple of weeks ago, so he asked me if I’d tweet to 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 on Twitter, 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 fucked, mate.  🙂  it’s a good time to get yourself some apprentice or intern 🙂

MM:  😀 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:

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 our discussion – my 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 – although I’m talking definitively here, I’m happy to admit I’m wrong if someone else can prove otherwise.  We need to get to the bottom of this problem once and for all!


  1. Dave permalink

    Thank you for this convo. I was linked here by Davide from the duc forum. I am inclined to believe Michael, but since I do not fully understand the dailies process workflow from set to ingest in MC I can not say for certain. This is the first time I have heard about auto sync in MC, so I am not sure what it does exactly, just assuming it is taking the TC metadata and using that for a sync reference. Manual sync in MC still makes no sense to me though, how can they move anything by partial frames if MC is only frame accurate?

    My theory is if the pd timecode is 9:42:13:22 and 1200 samples, that MC will just pull that file to 9:42:13:22 and now all the audio in that clip is 1200 samples early in the AVID. Once it is edited and spit out as AAF, PT puts the edit at the same frame as MC, but the audio is still early by 1200 samples. When FRW is done linking the pd files, the pd clip should be 1200 samples later than the AAF track and thus in actual sample accurate sync as compared to the frame accurate sync of the MC. Your example in red above with the samples since midnight seems to prove this point.

    I need to look at more AAFs to see if I see any pd files being earlier than AAF. I think I have seen it, but I need to verify. If that is the case, then is MC actually altering the TC metadata to a later frame? The ProTools 11 manual suggests that sync may be off by half a frame which would make sense in this scenario, but I know for a fact I have seen clips early by 3/4 of a frame or more, so how does MC decide which frame to move the file to?

    • sonicskepsi permalink

      Hi Dave – thanks for your comment (thx to Davide for posting a link on the DUC too). As far as I’m aware Autosync is what it says on the tin: an automated rushes-syncing program. I think manual sync simply means doing it by hand (& by eye) if either you feel more reassured of avoiding errors if you do it yourself or if there were timecode / metadata issues or errors on set which mean auto sync won’t work so you have no choice but to sync using the clapperboard. The interesting thing is (& this is very unfounded / untested as yet) that it seems when the rushes are synced in MC by hand, they still snap to the nearest frame but then PT pd files will subsequently match when FRW is used in PT. But if auto sync is used then the FRW in PT will throw up a discrepancy between the AAF & the pd wavs. Suggests manually syncing overwrites something completely whereas auto sync-ing retains some original samples or tc reference data. (I repeat this theory is not fact or proven yet – please can someone confirm if this is true or not?)

      I might be wrong Dave but i think if you’re getting discrepancies of more than 1 frame then you must surely be dealing with a different kind of sync issue with those clips. This MC issue is obviously by no means the only thing that can go wrong with the audio on location or in the MC.

      I read through the other latest comments on the DUC which were interesting – however, I’d be really interested if the conversation refocused slightly onto whether we actually need to ‘fix’ sync using Titan anymore if it’s proven that Pro Tools is ignoring the shift that MC is performing on it’s audio & is actually retaining the pd wav’s correct sync. Avid or Zaxcom may fix or change this or that eventually but the most pressing thing right now is that if we can prove confidently enough that MC is out and PT is in then we can stop wasting days of our schedule fixing something that doesn’t need to be fixed. I think i have proved this but i would like to know more absolute facts about how PT references the AAF – I think Frank Kruse said on the DUC that he believes it uses the samples before midnight info – which supports my argument, but it’d be great if Avid could confirm this.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: