AAF support

[msmcleod]

Found this on the Ardour forum, by one of their developers:

https://discourse.ardour.org/t/aaf/87442/2

Most interesting, is the comment from one of the AATranslator developers (which certainly echoes my experience):

https://discourse.ardour.org/t/aaf/87442/8

Pay particular attention to his comment about the fact that every application (whether DAW or NLE) has chosen to interpret the "standard" in their own way, so there's no guarantee that an AAF format will load properly in another application - even from the same vendor it seems!

If you look at the features of OMF & AAF they're almost identical with respect to Pro Audio.  The notable exception being Video Cue Marker support.

I had another play with AAF yesterday  - it doesn't even support stereo WAV files. You not only have to separate them into L & R channels, the WAV files themselves have to be deconstructed and the data & headers stored in different places. To make things worse, the example code they supply to do this is full of bugs and only supports a very narrow set of WAV files. To say I was shocked was an understatement.  To top it off,  you need to use Visual Studio 2012 to build everything as it won't support VS2013, VS2015, VS2017 or VS2019 (which meant digging out one of my old laptops).
 

[Glenn Stanton]

if you look into the "standards" around this, there are many partial attempts over the years and 4-5 which seem to have persisted. it's likely that some software companies probably invested in any number of the partial ones as well as the current "standards" (specifications really) and are also the ones likely to be involved in the committees to create the standards (both for showing their love of the movie industry, and of course to lock out competitors). so it's not surprising that the implementations vary enough to prevent easy re-use across competing products whilst each company is hoping they become the favorite...  somewhat interesting is the choice of Microsoft file format (via COM interface) for the storage blobs (alleging this works seamlessly across Mac and Linux... fully possibly given COM is simply a bit-wise interface specification re-usable  binaries as long as endian direction is taken into account ? )

Edited April 1, 2021 by Glenn Stanton

[John]

All I know is that AAF is far more reliable and easy to use than OMF. So far I have never had a AAF file fail where OMF does often. 

[marcL]

43 minutes ago, pwalpwal said:

hello VST

Hello almost any development standard!

Most are too complicate and often some definitions are being omitted (not defined), because some companies disagree. And then there are the theorists (no, I did not say terrorists, even if it was not completely untrue! ?) who tend to endlessly blow up the specification!

[Josh Wolfer]

On 3/30/2021 at 8:10 PM, Maestro said:

Other DAWs and NLEs are dropping OMF support as it's been deprecated and considered a legacy interchange format for years.

Newer software that never had OMF when it was actually de facto is not going to add it, so lacking AAF support will become increasingly more of a handicap, especially if you [also] work in the film post industry.

This is exactly what I'm running into. Avid media composer doesn't even support OMF at all. So it's not even an option. I had to find a friend with Pro tools to convert this last AAF for me, to OMF. There is a tool to do the conversion, but it's $200. If I'm going to drop that, I'll just use that toward another DAW, like pro tools, which is $300 for a year. I'd rather just stay native to cakewalk, especially for indie gigs where I'm doing all the post sound. It's getting harder and harder to do this though. 

[Glenn Stanton]

so why would you have to drop CbB if you buy into PT? i'd go out on a limb and suggest many people on this forum (and many more not on the forum) have at least 2 DAW they use, and probably many have 3 or 4 DAW products (and likely all kinds of audio processing tools as well).

for myself (having 6 DAW products), if i get audio files and no restrictions, it's CbB. if it's a mostly mixed PT project, then i open it in PT, save in PT, and re-share it back as a PT project. same for Cubase, FL, REAPER, Audacity, Studio One, etc etc... it would be silly to use a framing hammer to assemble picture frames when an air powered brad gun would be perfect... the right tool for the job is the right tool. smae for plugins - i need both VST and AAX so investing in products which support both eliminates redundancy in the plugins i use and the breadth of knowledge needed to use them across DAW...

if you're making a living off this stuff, then investing in the right tools and acquiring the skills to use them is part of the gig...

Edited April 4, 2021 by Glenn Stanton

[AJ Nester]

Cakewalk is a godsend for many of us and I really appreciate what BandLab has done. 

We still live in a world with many other.. mostly very expensive.. DAWs. 

A tool like cakewalk is greatly hobbled in the real world by not being able to exchange files with, for one, Logic Pro X- which supports AAF but not OMF (which admittedly sucks on its own as Logic Pro 9 did support OMF).  

Please O' Lords of BandLab and Cakewalk.. we beseech you to do us this solid. 

[John]

I agree AJ. With Cakewalk supporting OMF plus AAF that would give Cakewalk a comprehensive file interchange ability. This would make it easy for people to migrate from their old DAW to Cakewalk. That can't hurt acceptance.  Not supporting AAF does.  MTC 

[Keni]

a penny from me?

 

I think it a wise decision to include very popular common set of file specs as to make interchange between any 2 DAWs (eventually) able to invisibly, seamlessly exchange media between systems...

 

An obvious limitation is always the ownership of 3rd party plugins to be common across these systems which is unlikely, but a system of markers containing specs of the original plugins settings...  Does any of these file standards do this? I'm sorry, I digress...

...an any case I'm completely in favor of Cakewalk adding AAF support. It can't hurt, only help?