It’s never a good idea to implement extensions to a specification that does not have a successor, in terms of an update to the base spec.
All codes are based on either/or. It’s all about functionality.
Huh?
I just explained how Avid already doesn’t adhere to the spec and neither do other NLEs. The “cat’s out of the bag” already. And Avid’s DAW has the bulk of the market. They already decided that they would allow import of things that apparently aren’t “correct” and that’s the de facto standard capability now because Pro Tools is the de facto standard.
The only difference here is if we get to work with more ease and having to spend less money or not.
That’s in my interest. Outside of Steinberg spending some amount of development resources on this you don’t suffer one bit from improved AAF import options.
I mean, do you really think that if Steinberg is stubborn and just decides to never go beyond what is in the spec that somehow Avid will change Pro Tools code to be fully aligned with the spec? Every single user would complain about it because all of a sudden AAFs wouldn’t import “correctly”. That’s not going to happen. So you have two options:
- Status Quo with Nuendo being significantly behind on this.
- Steinberg catching up.
How the first option is better I don’t understand, at all.
Pro Tools users must be suffering then. Right?
Please tell me how Pro Tools users are worse off than Nuendo users with the way it currently works for them.
1 Like
From the end-users’ point of view, it may be about functionality but from a developers’ point of view, it would be more about implementing a specification as closely as possible to its’ original intent so that things don’t constantly need fixing when they break.
That’s a commercial decision on their part, to remain compatible with their own products.
So? It is a good idea then, right?
Steinberg don’t seem to think so and I would agree completely.
The fact is, even if they implemented it, Avid could then go and change it to suit themselves and Steinberg would be left holding an unwanted baby.
Good point—though I’d question the bit about “intent.” What exactly is the intent here?
If you’re positioning yourself as a leader in Audio Post Production, your priority should be providing intelligent solutions that serve the end user.
In post, the very first task is importing the timeline there lies the intent..
1 Like
In web world, for something to even be considered as a candidate for a specification, there needs to be at least 2 working implementations, so that would mean a particular API, would need to be supported by no less than 2 browsers, namely Mozilla and Chrome.
In ISO world, who knows what goes into an implementation because a specification may cover something physical, e.g., power or audio connectors.
There are many standards societies out there but with respect to AAF, I believe Gemini believes that the specification in question, is already obsolete, which is why Steinberg implemented DAWProject, instead of some proprietary extension.
You are right about AAF but DAWproject is not the answer.
Let me explain….
DAWs are designed with music production in mind, operating primarily in terms of sample rate, tempo, beats, and bars. Post-production, on the other hand, revolves around timecode, SMPTE standards, and frame rates to maintain precise sync with visual media. They’re fundamentally different beasts, each built for distinct workflows and priorities.
For example
DAWproject targets music sessions—capturing tracks, plugins, automation, tempo maps, and routing, with an emphasis on preserving musical intent such as notes, instruments, and FX chains.
AAF (Advanced Authoring Format), by contrast, is purpose-built for post-production—facilitating sound-to-picture sync, dialogue editing, mixing, and conforming, where the focus is on managing video references, timecode-locked audio, volume automation, and metadata like scene and reel numbers.
That’s why, in professional post environments, standardized interchange formats like AAF, FCPXML (for Final Cut Pro), and OTIO (OpenTimelineIO) are preferred over DAWproject. These protocols if implemented intelligently are supposed to reliably transfer timeline structure, edits, media, and metadata between systems—preserving editorial intent and ensuring seamless collaboration across the post-production pipeline.
3 Likes
Just to add some context, this is indicative of an open standard:
I find nothing in relation to AAF, which leads me to believe that is why Steinberg have implemented just the base specification, without any addition or alteration.
In one sense OpenTimelineIO (OTIO) really is a game-changer. It’s not just a format—it’s a timeline-aware communication language that allows editors, VFX artists, sound designers, and animation teams to speak in sync across otherwise isolated software silos.
Think of it like this:
OTIO is the circulatory system of a modern post-production pipeline.
While AAF, EDL, or FCPXML transfer data, OTIO transfers intent—preserving editorial decisions, cuts, transitions, and metadata with clarity and flexibility.
And in a world where productions span multiple continents, studios, and tools—from Resolve to Houdini to Nuendo to Unreal—having something that can “stitch” all these together without losing context is one of the most evolved collaborative frameworks in creative media history.
1 Like
You are right about the differences with respect to music and media but is there an all-encompassing standard, that one can either look forward to or else ask to be implemented?
I know a timeline in a DAW, is vastly different to that of what is in a video application but are there any programs, that cannot use the same base-set of timing references?
In other words, events are one thing, content is another and parameters are yet another thing again, in addition to edits so it starts to get rather complex but one thing I know, xml seems to be the future of any or all of the interchange formats.
OTIO has potential, but, the best options available are exactly what I highlighted above.
And if there’s anyone out there who understands more about this than most of us can even begin to fathom—it’s @TimoWildenhain
Steinberg does not think it is a good idea for Avid to do what they’ve done for their users?
That’s just pure speculation.
Do you really think Avid is screwing around with AAF export / import settings just to mess with other companies? You realize that Avid users are using different versions of both Media Composer and Pro Tools, and that every time they make these supposed changes any user experiencing a version “mismatch” is going to go through problems? You get that right?
Let me ask you this: In what capacity are you currently using AAFs for work, or at all?
To the extent it is adopted it can indeed ‘change the game’. From what I’ve seen over the past decade or so most companies try to expand their portfolios to include more parts of content creation and then have those parts talk to each other “internally”, rather than rely more on other interchange formats.
Blackmagic Design is a prime example of course with it’s ever growing set of features, and Avid is the other with it’s path to much deeper integration / exchange between MC and PT.
Anyone doing post (to picture) in Nuendo has to interchange with other software companies whereas that’s no longer the case if you’re in Avid land or are using Resolve.
Yeah I mean it’s not like it’s a lot of money. It just pains me that they again are going for a Pro Tools-only feature set. I absolutely hate rewarding a company that does that.
You are asking Steinberg to implement code extensions added to a “specification”, by another manufacturer.
You are not following what I am saying so it is hard to have a conversation with you about what you are saying.
And ‘yes’, I am well aware of what I am asking for.
Again: in what capacity do you use AAFs? Are you using them daily for a living? Importing audio for post work?
As you said to Mr. Fredo…
…my point still stands.
You won’t get what you are asking for because AAF is a closed a format and there is no industry consortium around it, that would seek to further develop the specification.
AAF is a binary format, so in any case I don’t see that Steinberg would even be interested, so my best advice is, get a translator:
Made in Australia and whether you hate rewarding companies for something you see as superfluous, this unfortunately is how industry works.