I experienced big struggles with the AAFFilter.bundle v2.0.14.1.
Here’s my configuration : Nuendo 6.0.5 running on a Mac Pro Octo ML 10.8.4.
Here’s the diagnostic :
When exporting an AAF, it would only export non-embedded WITHOUT handles. Non-embedded is the only way to keep original clipnames though.
When exporting embedded, it would crash most of the time, leading to a proper stop of Nuendo, whereas it usually works with non-embedded (file is less than 4go).
Non-embedded would lead to some missing clips.
Small crossfades (40ms) would not export properly, leading to truncated files.
For some reason, most of the fades in/out wouldn’t export properly.
Small edits such as mouth noises or pencil edits wouldn’t apply, occuring some small clips generation (and digital clicks because of the truncated files).
Here’s a (not to say the only) solution I found :
Export XML
Import in Nuendo 5.1.1 (AAFFilter.bundle v2.0.10.1)
Export from this version with non-embedded audio or references.
Though, try to consider this solution as a massive pain in the neck (3 steps instead of 1), and a total waste of time…
Couldn’t it be possible to roll-back to this working version and try to improve the spec sheet with the developpers ? Because v2.0.14.1 is totally inefficient and useless in any professional workflow…
It’s a real shame though, conformation was so much easier with your 2011 release.
Just to let you know (v2.0.10.1) from Nuendo to Protools 10 :
Names = OK
Tracknames = OK
Clipgains = OK
Volume Automation = OK (perfectly matches with clipgains in addition)
Simple crossfades / fades = OK
Things I haven’t tried yet (will continue tomorrow) :
Stereo / Mono separation
Panners
offline plugins / realtime transpose
…
For once, problems are NOT coming from Protools, as I already tried to import the AAF on a new nuendo session.
If you could correct this issue for your next official update, it would be so nice. I have an ATMOS editing coming for September, and I would really like to convince the production to work partly on Nuendo. Though, I can’t take any of these risks if the software works this way…
I feel that Nuendo users have been patient for quite a while on this critical issue that I consider a show stopper for an audio post app.
I had suggested going back to the old 5.1 import/export filter when 5.5 was released. I have even sent them AAFs as a proof that their new filter does not work in many cases.
After years of waiting we get a bunch of new and very cool new features and a shiniy new mixer. The core of audio post work (import/export) remains broken and is pretty much completely useless unless you use 5.1.
This has been reported over and over again and it’s simply beyond my imagination why Steinberg does not at least roll back to the 5.1 filter version that has its problems as well, but at least works most of the time.
The reason I get so angry is that this problem forces me to either stay in 5.1 or constantly switch apps when a client asks for a new aaf to be imported.
Don’t start suggesting third party windows only workarounds. I strongly feel that import / export is a basic feature that I demand from my DAW of choice.
I am very frustrated about this issue and the time it takes to solve or at least temporarily improve the situation.
We’ve been telling you guys NOT to add new features until the old one works and you keep NOT listening.
AAF/OMF import is THE most important feature in an audio-post app, especially since we in the US all have to integrate with PT at some point.
HOW THE HECK can you manage to BREAK functionality in updates? v2.0.14.1. works less well compared to v2.0.10.1. How is this possible???
So now that we’ve been complaining about this FOR YEARS you’ve finally decided to put together some group or whatever to continuously update the filter(s)… later this year. So it’ll be at least more than half a year before you bring out an update to the filter, and this after having rewritten the entire app (again).
I can’t believe you guys don’t get this, but what use is it to me to look at horizontal faders in a new Control Room GUI when getting errors on AAF import/export? Why would you spend development resources on that crap and not AAF? Do you now understand the hierarchy of the importance between these two?
New Control Room GUI nobody likes and asked for? Not so important.
Being able to import/export media so we actually have something to listen to in that ugly CR? Pretty much essential.
Sorry for the additional rant, but this is getting REALLY tiresome. Get your stuff together already!
Got a new AAF from FCP today: AAF Import Error 8012006A
Absolutely no problems opening this AAF in Pro Tools.
This is the third project this year where I am not forced to use pro tools by the production company (due to studio switches, mixing stage, etc). But it is also the third project where the AAF-Import just do not work! So in the end Steinberg forces me to use Pro Tools! I could not do any project in Nuendo in 2013 so far (apart from some TV-Mixes on final stems coming from PT)!
Hi Ollie, no, I do not have 5.1 installed. I only have a 5.5 and 6 installation.
But I converted the session to Nuendo yesterday: Opened the AAF without any hassle in PT and then used the new AAT-version (with ptx-support) to create a steinberg xml. That worked. Even the clip gain now transfered correctly!
So I’m finally ready to try my first complete N6-project now…
thanks for the reports. The AAF team is ready to receive corrupt projects for in-depth analysis.
We will set up a FTP server soon for project exchange.
If you’re able to share AAF projects with us for issue analysis, you’re very welcome to upload
them alongside a description of the problem.
In general, please note that there is no “one” solution to AAF-related compatibility-problems. In many
cases it depends on the DAW/video software that has generated the file.
We will publish more information on help & upload very soon.
It does, like been explained before.
Depending on with which version of Mediacomposer the AAF is made, it imports correct in either an ealier version of the Nuendo AAF compenent or a later version.
Sorry, but that doesn’t make sense to me. Please explain the logic behind it. I would think that if you manage to write code so that an .aaf made in, say 2011, opens fine in Nuendo 5.x, that same .aaf from 2011 would open fine in Nuendo 6.x. Because I would think that if you change the code in Nuendo it would be for the better, to increase compatibility.
So I’m sure we’re all ears as to how this makes sense, technically.
Well, the new code must have broken the compatibility with old AAFs.
While I understand that technically bad things can happen when you work on your code, I don’t understand how you can claim to be in the audio post market and leave such a BASIC problem that is known unfixed for 2 years.
I mean you force users to either stay in 5.1 (like some colleagues of mine do since they simply don’t feel like putting up with the hassle) or go though tedious version switching all the time.
Don’t get me wrong, I love Nuendo’s bells and whistles and use many of them on a daily basis, but the AAF situation makes me really mad now. We’re half a year in from a major version update and NOTHING has changed. It’s just plain ridiculous.
Fredo is right. It will never be possible to guarantee 100% compatibility if the format is not defined by an independent commitee to the detail level. And with regards to AAF, it is not. However, with regards to Nuendo - as I have stated yesterday - we’re happy to receive corrupt projects for issue analysis.
More information will be available within this week.