AAF

#1

I am a sound designer working in sound post production. I use Pro Tools as my main tool for editing and mixing, since it is the most widely used tool out there.
I use Ardour for music recording on my linux machine, and for the more creative sound design that I later import into Pro tools (PT isn’t really designed for this, and Ardour’s connectivity via Jack allows some great productivity between software)

I am very impressed with Ardour 3, been using it for Foley recording when I had some hardware issues with PT, and it was a very pleasant experience.

The one issue is native AAF support: It’s 2014 and the one leading technology used for file exchange in the industry between projects, DAWs and video editing is AAF. I know of ardourxchange, (but that only supports IMPORTING, not exporting) and the reasonably expensive (200 usd) windows app AATranslator.

As an open protocol, and one included in so many DAWs, it would make a lot if sense to be able to integrate import/export AAF/OMF into Ardour!

Is there a reason why it’s still not being considered?

#2

AAF is a design nightmare. It is a complete nightmare to implement support. It includes as “open standards” specifications things like Microsoft’s own “filesystem in a file” which was never actually specified anywhere (there is an open source implementation of something like it but that isn’t approved as part of the AAF standard). It has every hallmark of design by committee.

I spent quite a long time looking at AAF several years ago. I would never voluntarily involve myself in developing code to support it. If this is the best the audio industry can do for session interchange formats, it should be utterly ashamed of itself. A file format that basically implies a relational database to support it? Completely ridiculous.

I also tried my hand at OMF support, starting from an open source part of Reaper. Turns out that the Reaper OMF support can’t handle more than about 20% of all OMF files out there and a full implementation is probably even worse than AAF. Gave up on that too.

#3

Also, note that AAF support is actually not included in “so many DAWs”. There are some that support it but many that do not. Even Protools LE doesn’t have AAF support. Neither does Presonus Studio One, Sonar or Ableton Live. The only truly “portable” way to move a session around is by using stem export, which Ardour 3 now supports in quite a nice way (though like most things we do, it could be better).

#4

BTW, glad to hear you’re enjoying at least some aspects of Ardour :slight_smile:

#5

Thanks for shedding some light on the subject Paul. I suspected it wasn’t something easy to incorporate, otherwise it would’ve been done by now… It’s very unfortunate since it is the industry standard: The major video editors have to export sound in a more sophisticated way than just stems, for an DAW to reference rushes and work with isos, referencing files via timecode and reading embeded metadata, include audio fades made from the editor, etc. Avid MC, Premiere and FCP have AAF or at least an OMF export option.
I understand the complications, I was just voicing what we use as an essential part of post production workflow every day.
Maybe it’s up to third party developers out there, but as of today, I see a single expensive option.

#6

And by the way, yes there are loads of features that just simply do not exist in PT which I relish in Ardour, offline & simultaneous stems bouncing being just one of them!

#7

if you really really need it, aatranslator does its job pretty good (running in wine) and their support is great…

#8

Paul has nailed it with this but I’ll just add this quote from one of my team that I think is pertinent here…

“For me, the [unnecessary] complexity of OMF, AAF and MXF make them a “Use at your own risk format.” Although there are other formats that can be in the same category, these three are the worst. They are self proclaimed standards that never should have been created. Although the container format is always a standard, the methods of describing data within the container is not. They each have multiple ways of describing the same thing and since everyone has a slightly different way of doing things within the containers, they might as well not exist at all. To call it any kind of standard should be against the law. OMF is literally a format within a container format. AAF and MXF are much worse because they are a format within a container within a structured storage format. There are much simpler ways of doing this that still have all the same advantages of AAF/MXF…”

Even Avid have two AAF ‘flavours’ their PT one and their Media Composer one and hardly any DAW/NLE reads either properly let alone both and given that there are two formats, no they are certainly not ‘industry standard’ and never will be unless in terms of marketing they may be but not in reality :wink:

And just to clear something up - while the ‘standard’ version of AATranslator is cheap the ‘enhanced’ version of AATranslator is not. All those ‘industry standards’ like OMF, AAF & MXF and the encrypted ProTools session files can be thanked for that and the ridiculous number of man hours it has taken and continues to take to support those needlessly complex and diverse formats. That is the reason we have two versions so that those who don’t need those formats are not burdened with a higher price
I think most ardour users should understand that someone has to pay for support and continued development but I do realise that for some that price does not represent value and that’s fine too

I certainly don’t envy any developers dealing with any of those formats

Anyway that’s just my two bobs worth :wink:

#9

For AAF and OMF support you need AA translator, it’s a great software.

#10

AATranslator is awesome. Unfortunately the Ardour XML Output is for Version 2 and just has a 50:50 chance to work.

#11

So what’s the best workflow fow now for video post production with audio mixing/editing in Ardour? To use stems as was mentioned before?
I’m now using Lightworks for my video editing purposes and really want to combine it somehow with Ardour.

#12

@mcdebugger

Funny you should mention this, I am using Lightworks as well, and while I am still ironing out my workflow, right now it looks something like this…

I take video into Lightworks, do any AV sync in there (A little more difficult than it should be). In general I use ffmpeg to convert to MXF and link to within Lightworks. If I resync and clean up audio before editing video, then I will mux the audio with the video file externally using ffmpeg, but I haven’t done that much lately (Using a beta version of Lightworks, earlier versions had severe problems with AV sync, I suspect tied to some memory management bugs they had on systems without a swap partition) I did have one file this week that seemed to not quite stay in sync and I had to resync two or three times thorughout the 10 minutes or so, but not horrible. After editing the video sync’d to the audio in Lightworks, I export mono files bypassing the mixer from Lightworks, and a good quality render video only file.

In Ardour I import the mono audio files I exported from Lightworks, and import the video, transcoding it on the way in Ardour. I then do any audio edits I need to there, and obviously processing and mix. I then export the stereo wav file, and remux externally with ffmpeg so I can copy the video without re-encoding.

This seems to provide the best balance of space requirements (Only have a 48GB HD on my laptop) and performance/quality to me. Yes it would be awesome to have handles on the audio, but for the most part I have been able to fake it by being careful with my edits in Lightworks and using multiple audio tracks. Not quite as good as AAF/OMF could be in theory, but not horrible.

I am intending to look at the code for video export and annoy Robin soon to add in a couple of new presets to support such a workflow if I can convince him to take it. But no promises on when or if that happens.

         Seablade
#13

@seablade

Thanks a lot for your detailed description of your workflow.

After some thinking I came to similar one too (except for video importing to Ardour too - in my recent projects I’m not sure that I need it but in the future of course it’s useable practice).

The other exception is that I prefer exporting to some editing codec and then manually using x264 for final public release. I really like the way x264 encodes the video.
In the recent Lightworks 12.5 release candidate (RC1) which has came out today, devs added advanced encoding settings for H.264 that I’ll check when one annoying bug will be fixed and maybe then I’ll export final render directly from Lightworks.

#14

Ahh good I need to see if they fixed a bug that was cropping up for me. Time to upgrade and test again…

Seablade
#15

Hi Paul,

Respectfully, I must echo Jonesints point here. I can’t call myself a user of Ardour (yet), simply because after the install and brief period of play, a few projects piled up and I won’t be able to get back to it until November (also considering going to the Harrison Mixbus flavor as well).

Since I too do post production, I have to come out and say that AAF/OMF IS a standard, simply because it is literally used in every mix house for transferring audio sessions and timelines between audio and video. While there may be a few outliers who insist that you can get around it, the reality is that if you are a house that doesn’t implement this file exchange format you won’t get some jobs because post production supervisors don’t want to hear your work around suggestions. They just want to get the work done the way they are used to doing it. Not only that, but I’ve even had to deliver AAFs to networks along with my mixes and stems. If you want to see what can happen to an NLE that decides they can do better than AAF/OMF, look at Final Cut Pro X. It doesn’t have it and that platform died a spectacular death in the industry to be replaced by Adobe and a resurgence of Media Composer.

I agree that it is an incredibly flawed transfer format whose bits I wish could be stricken from memory, but in the land of audio post production it is a necessary evil. I think that whoever develops for good AAF/OMF import export should be paid for their work, simply because it is such a customized workflow that only really serve the A/V post community, but we’re used to paying for stuff. We’ve all dealt with Avid for years. Not only that, but larger facilities prefer to pay for stuff because there is a great amount of distrust and lack of understanding of how open source works there.

Seeing Avid faltering so much in running its core business is making a number of us want to start branching out to look for alternatives. If Ardour/HMBv3 can do much of what we need them to do and will fit into our workflows easily, things can start to slowly change for the better.

AD

#16

Let me try to restate this as simply as I can:

I am never going to work on AAF. It is impossible to work on OMF (there are no specifications).

If there are people who believe that this is so critical, then you’ve got these choices:

  • Find someone to work on AAF
  • Find a way to make working on OMF possible

That’s all you have to do. Really - that’s it.

You’d have to pay me many, many thousands of dollars to work on either project and even then it wouldn’t be something I’d really want to do. Whatever avenues Ardour is shut out of by lacking AAF and/or OMF support - we will stay shut out of them until one or both of the above conditions occur.

#17

Hi,
there is a product on sale to do this: http://www.avtoolkit.co.uk/
I am going to buy it. Anyone comment on it?
AAF is a mess but its powerful and is the standard.

#18

It worked with A2, at least on certain styles of AAF, not sure on it’s current state with the session formats for A4 or MB3. John has been known to post here though so maybe he can confirm?

    Seablade
#19

There is still GUI integration for ardourexchange in recent Mixbus3.2 (which is based on Ardour 4.7). It’s also for sale as addon on the Mixbus store.

I don’t know how well it integrates with Ardour.

#20

I heard back from John who said ArdourXchange only supports Harrison Mixbus and only embedded AAF. I suppose AAtranslator is the way to go but on OSX you need an emulator.