AAF import problem timecode mismatch

Hi,

I have been supplied with an AAF file and the source video files and I am having trouble getting the AAF to conform.

If I start with a new project and set under Project Settings/General Options 'Use Timecode Embedded in Source clip' I get errors such as

Clip 'C0011_Sc2_6_side from passenger' in track V1 at timecode 01:00:37:09, with reel name 'C0011_Sc2_6_side from passenger' and filename 'C0011_Sc2_6_side from passenger.MP4':
Mismatch between specified target timecodes [00:00:00:00 00:03:25:23) and located file timecodes [13:04:09:22 13:07:35:22)

If I start with a new project and set under Project Settings/General Options 'Use Timecode From the source clip frame count' I get the same errors.


If I start a new project and import the media first I get a message "the clips have a different frame rate than the project settings". The clips I've noticed are 29.97. The default project is set to 23.976. If I set it to the frame rate of the clips when I import the AFF I get "Question" the selected conform rate (30fps) is different from the native rate of the timeline (24fps) Are you sure you want to continue?" If I choose yes the timline appears with clips in it but the in's and outs are all wrong.


If I do the above but keep the project settings at 23.976 the imported AAF still has the wrong i/o's. The same occurs whether I have "use embedded timecode' or "use frame count".


Any suggestions?


Also if you have any suggestions on how I can see the edl information the AFF has in it (i.e. the source in's and out's it is looking for). For example if I look int the source window at a particular clip I see it's in and out marked on the timeline portion with a source number up top on left but on right it has little filled squares.

Are your source clips from a Sony dslr ? That clip name makes me think they are.
I seem to recall there are some “clip link” (sort of importing) workflows in avid where the timecode in the source will be ignored and substituted with (random) timecode. This has something to do with where Sony stores the timecode in the file. This could be the cause of the timecode mismatch you report.
Could the editor send you an edl from the timeline?
I’ve been using a round trip workflow with avid and resolve using Sony XAVC s codecs from a A7s camera, and it been consistently correct. I rewrap the Sony mp4 file to a .mov wrapper with “Edit Ready” and then “ link” in avid with the QuickTime plugin.
Let us know what you find.

Thanks for your reply.

The first AAF sent to me referred to mxf files and they appear to be consolidated media output by AVID. I then requested that they send me an AAF that referred to the camera source files (MP4's) which they did. After much hacking at it I discovered that the AAF was still using the numbers derived from the edit with the MXF's (which weren't proxies made from the original camera files but rather just sections from the camera files transcoded). I have requested an AAF that actually refers to the codes in the original camera files. We shall see what arrives next and whether the 'alt' timecodes you mentioned rear their head in the next iteration.


Why do you rewrap the files as .mov? Shouldn't it work fine just by pulling up the original files?

Why do you rewrap?
For a long time avid did not support xavc s in a .mp4 wrapper without buying a”nablet” plug-in, whereas if you rewraped to .mov it worked. (You have to copy them from the Sd card anyway ,so you may as well rewrap them in that copy)
Later avid added support for xavc s with its own generic plug-in, but many users have complained that on long clips, the transcode fails. So I have just stuck to what was working for me.
But I did read a lot of bad reports around timecode, something like - Sony was writing timecode into the Metadata field not the timecode field, So! the avid saw no code and just made it up!

Ask your editor to look at the timecode of a specific clip outside of avid and compare it to the timecode inside avid.

Just tried the avid generic plug-in and it gives a completely different timecode compared to the .mov process outlined above