When I select to open an aaf file into a new project the starting time code will be that of the starting time code of the aaf file.
When I open my template and import the aaf into it the following appears to happen:
Template project starts at timecode 00:58:30:00
AAF file timecode start is 00:59:58:00
Open template or other project with earlier time code than AAF
Select File - Import - AAF
Select “No” when asked to “create new project?”
Select “all tracks”
Select “yes” to extract all media
Result:
The media imports and you can actually see it line up first at its start position relative to the start of the nuendo project and then move to the actual aaf timecode start position.
Tracks 1&2 plays back at the original import location, which was towards the beginning of the timeline, despite the visual representation (clips) having been relocated, and despite there being NOTHING on the timeline where they’re playing back
Tracks 5&6 plays back at the actual aaf timecode location (start 00:59:58:00).
\
Select the imported aaf tracks and select all media on them.
Copy to a later place on the timeline where nothing currently exists.
Go back to the aaf timecode location where the tracks look like they should start.
Imported AAF into template. It placed the 2-beep it contained at the start of my template (00:58:30:00) which is NOT where it was put in the AAF, for sure.
Imported exactly the same AAF into this project a second time. Now the 2-beep ends up at the new beginning of my timeline, 00:47:55:12!
These aafs that I just tried are old and imported fine in older Nuendo.
I totally understand the difficulty of keeping up with Avid’s products and others, but I have absolutely zero understanding when an earlier aaf ceases to import correctly in a newer version of the software. I just don’t see how you could develop the software in such a way.
One would think development and beta testing have an arsenal of aafs archived so they can just go through them one by one making sure they work… I guess not…
Some open up fine if you start a new project. But here’s the annoying part:
You either then have to import your own template tracks into that new project, or you open up your template in a separate project, and copy over the aaf/omf tracks. But if you switch between projects (activate different ones) your Direct Routing turns off all outputs except one. So you have to go back to the mix window after activating and turning on all the outputs that were switched off.
Can’t say I see the point in redesigning the GUI of Control Room when aaf/omf import that USED TO work isn’t working, and Direct Routing isn’t staying routed…
After three weeks in PT, I did a TV-Mix in N yesterday, and was quite happy to be back.
Today I got delivered a new AAF for a documentary movie.
AAF import in N failes, it generates many empty events, some a there, some a missing.
Same AAF opened in PT: Everything is fine.
So back on PT again…
I went through a lot of back-and-forth with an editor who works part time at the Avid factory, using their latest versions. It took a long while to come up with a good workflow.
Apparently Avid renames the files when generating an AAF, appending an 8 to 12 character hex string that isn’t consistent across a project, and isn’t consistent from export to export. If Nuendo doesn’t see that precise string in the pool or the folder it’s loading from, it assumes the clip is missing. (I’m guessing ProTools has an option to ignore that string. It’s inserted between the filename and the extension, separated by dots.)
Until Steiny comes up with a similar function, or somebody writes a utility to do a grep-like delete across the filenames in a directory, the only way to make things work is to have the editor ship you all new audio files with each new export, making sure they’re the files that were generated during the export.
Yuch. Another way Avid/ProTools has messed with a working standard, to make it hard for anybody else to use it.
as mentioned in the other thread, we’re in the process of setting up a dedicated team for AAF-related error analysis and further development of the import/export filter. Of course we have noticed that there’re many different issues related to AAF.
Once the new team is ready to start working on AAF, we’ll be able to analyse defective AAF projects and will also provide AAF support on a regular basis. We’re confident to have this working group set up by mid of this year.
good to hear from you. Yes, we definitely need some material for checking. This will be part of the regular’s work of the team. However, it we’re still in the process of setting up the whole workflow.
Allow me to come back to you once we’re ready for checking.
Mid-year is June. Then they’ll get material and analyze it which will take weeks. Formulate a plan and program? More weeks. If I were a betting man I’d say the fruits of their labour will be seen last quarter at the earliest.
Please tell me that you have an update with AAF improvements before then (?) !
And while you’re at it I’m sure I’m not the only one eager to learn when the next update is coming. I would normally not ask for one, but seeing that the last one didn’t install properly (NEK problem) and contained brand new bugs (!) and seeing how people find OLD versions of Nuendo importing AAFs it would be swell if you could muster an updated update.
Being able to import AAFs is basically putting the horse before the cart. Nuendo is a post tool. One would think this is a priority.
“AAF” is a quite complex topic, especially if you need to react on things that have been changed in other applications. That’s why the team will constantly work on improvements, reflected in each update as of then.
I will not make any promises regarding timeframes, but this topic will get a high priority.
I would agree with others that it’s highly unfortunate that the initial N6 did not include improvements, but it’s good to hear that you are seriously committed to improvement in this part of Nuendo.
