It's probably 4 or 5 years since I did any significant work with AAF. Since then, it's mostly lain dormant on my system :-(
However, I recently became involved with an open source DAW called Ardour whose team wants me to develop an import/export system for it. I'm considering AAF but I have a few questions….
1) Is AAF still alive and well? (I'm only asking because there doesn't seem to be a lot of activity on these forums any more).
2) Ardour is available for Linux & Mac (and is being developed for Windows) but according to the AAF FAQs, each platform seems to have its own SDK. I'm assuming there's proably a common code base so why the individual SDKs? Do they use the same code base but implement different build regimes, for example?
3) If so, what are the recommended compilers / build regimes for each platform? (e.g. 'gcc & make' for Linux, 'VC++' for Windows or whatever).
4) Most modern DAWs are capable of delivering overlapped audio on the same track(s). e.g. a given time region on a given track might contain two overlapping audio clips (without any crossfade). Last time I looked at AAF it was impossible to represent this in an AAF file without crossfading between the clips. Is that still the case?
I've a few more questions too - but that's enough to be going on with!
John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
AAF is still an active technology & widely deployed. The AAF Association group that did a lot of the original work became the "Advanced Media Workflow Association" and continues with a broader scope including workflow, metadata and multiple formats, particularly working.
Re. the source code, it is common for all platforms. The platform specific directories just contain platform specific build files and (when built) object code. The top level README file gives instructions for building on each platform.
Phil
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Many thanks Phil. When I last used AAF there were only two audio codecs (WAV and AIFC). Coming back to it now, I'd be tempted to ditch my old code and start afresh. However, I remember that I extended my local codecs to be "endian aware" (which the standard ones weren't).
For example, WAV is a little-endian format but the AAF codecs at that time seemed to be unaware of this. I added some code so that when writing WAV data, the data would be byte swapped (if necessary) to guarantee a little-endian target WAV file. The opposite procedure would be carried out when reading, so that the user's app would never need to be aware of endian-ness (it would all get handled automatically). Ditto for AIFC.
I guess there might be some extra formats to accommodate now but would any of this code be of interest to the AAF/AMW Association? I find it quite a worthwhile feature and I don't want to lose it if I upgrade to the current code!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm wondering if you would address the issue of sample code - I'm aware of the samples provided with the public-facing distribution, without going into too much detail I think it's fair to say those samples are of limited practical use. Can you explain
why this forum (or the SDK, or any update to the SDK) has not been a point of distribution for a suite of useful (and fully documented) sample files? (Meaning AAF source code that clearly demonstrates the placement of various types of media on timelines that is fully functional on widely circulated platforms, including import/export, etc? Specifically - Avid Media composer, ProTools, FCP, Nuendo, Logic).
Thanks for any info,
tj
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I didn't come here to engage in AAF bashing but I must admit I sympathise with tj. And it's not only sample files that are lacking. One only has to take a cursory glance around these forums to see how many requests for help are going totally unanswered. In all seriousness, this is probably the main reason why OMF is still in widespread use - despite having been officially obsolete for the best part of a decade!! The quality of the AAF code and the techniques used are first class but support is frankly, dismal :-(
When I first revisited these forums recently, I genuinely assumed that AAF must have been scrapped because there was so little activity here. Is there any way that support could be improved Phil? Or are we all using the wrong forum? Is there some other forum somewhere that gives better support?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm a feature film sound designer and from my perspective AAF is not dead at all! And MXF seems to have become the defacto standard exchange format for digital cinema as part of the DCP (Digital Cinema Package). But OMF is still used extensively because everybody is used to it and it fulfills the basic needs.
Regarding tj's and your remarks on support, I suspect the dev community simply isn't that large = little activity. After all, this kind of technology is dominated by big players (like AVID) with proprietary file formats, which is a major pain in the ass for professionals like me! For me it would be best if everybody would agree on one format and lead it to perfection, which won't happen.
I came here to research the possibilities of writing a tool with AAF export capabilities under OSX and I'm a little bit intimidated by the complexity of the SDK. I will also try the AMWA forum and maybe the mailing list, but i guess it will be very hard for a semi-pro dev as I am. So if any of you guys has suggestions for a primer in writing AAF files (to be imported in DAWs like Pro Tools) I'd be very happy!
Sebastian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Sebastian. Replying 6 years later. I am in the similar position as you. I have successfully created AAFs that import to protools. Currently Im having trouble with some API that Im hoping isnt broken by OS updates. Would be happy to chat.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) What's the current status of the AAF source code? Is it available from SVN or GIT these days? Or is it still only available in zip form?
2) The most recent zip file I could find was dated around April 2013. Is that the current version?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I should probably report this to the developers somehow but FWIW I just tried building the (latest?) code with VS2015 Community Edition. So far I've only tried the main SDK but it won't build properly (for the Release target, AAFBasicInterpolators fails to link).
Having said that... are these mailing lists even valid any more? Or have the discussion forums moved somewhere else now??
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's probably 4 or 5 years since I did any significant work with AAF. Since then, it's mostly lain dormant on my system :-(
However, I recently became involved with an open source DAW called Ardour whose team wants me to develop an import/export system for it. I'm considering AAF but I have a few questions….
1) Is AAF still alive and well? (I'm only asking because there doesn't seem to be a lot of activity on these forums any more).
2) Ardour is available for Linux & Mac (and is being developed for Windows) but according to the AAF FAQs, each platform seems to have its own SDK. I'm assuming there's proably a common code base so why the individual SDKs? Do they use the same code base but implement different build regimes, for example?
3) If so, what are the recommended compilers / build regimes for each platform? (e.g. 'gcc & make' for Linux, 'VC++' for Windows or whatever).
4) Most modern DAWs are capable of delivering overlapped audio on the same track(s). e.g. a given time region on a given track might contain two overlapping audio clips (without any crossfade). Last time I looked at AAF it was impossible to represent this in an AAF file without crossfading between the clips. Is that still the case?
I've a few more questions too - but that's enough to be going on with!
John
Was I right then in thinking that AAF is no longer an active technology? Or at least that it's no longer being supported?
Hi John,
AAF is still an active technology & widely deployed. The AAF Association group that did a lot of the original work became the "Advanced Media Workflow Association" and continues with a broader scope including workflow, metadata and multiple formats, particularly working.
Re. the source code, it is common for all platforms. The platform specific directories just contain platform specific build files and (when built) object code. The top level README file gives instructions for building on each platform.
Phil
Many thanks Phil. When I last used AAF there were only two audio codecs (WAV and AIFC). Coming back to it now, I'd be tempted to ditch my old code and start afresh. However, I remember that I extended my local codecs to be "endian aware" (which the standard ones weren't).
For example, WAV is a little-endian format but the AAF codecs at that time seemed to be unaware of this. I added some code so that when writing WAV data, the data would be byte swapped (if necessary) to guarantee a little-endian target WAV file. The opposite procedure would be carried out when reading, so that the user's app would never need to be aware of endian-ness (it would all get handled automatically). Ditto for AIFC.
I guess there might be some extra formats to accommodate now but would any of this code be of interest to the AAF/AMW Association? I find it quite a worthwhile feature and I don't want to lose it if I upgrade to the current code!
Hi Phil,
I'm wondering if you would address the issue of sample code - I'm aware of the samples provided with the public-facing distribution, without going into too much detail I think it's fair to say those samples are of limited practical use. Can you explain
why this forum (or the SDK, or any update to the SDK) has not been a point of distribution for a suite of useful (and fully documented) sample files? (Meaning AAF source code that clearly demonstrates the placement of various types of media on timelines that is fully functional on widely circulated platforms, including import/export, etc? Specifically - Avid Media composer, ProTools, FCP, Nuendo, Logic).
Thanks for any info,
tj
I didn't come here to engage in AAF bashing but I must admit I sympathise with tj. And it's not only sample files that are lacking. One only has to take a cursory glance around these forums to see how many requests for help are going totally unanswered. In all seriousness, this is probably the main reason why OMF is still in widespread use - despite having been officially obsolete for the best part of a decade!! The quality of the AAF code and the techniques used are first class but support is frankly, dismal :-(
When I first revisited these forums recently, I genuinely assumed that AAF must have been scrapped because there was so little activity here. Is there any way that support could be improved Phil? Or are we all using the wrong forum? Is there some other forum somewhere that gives better support?
@johnnyfartpants:
I'm a feature film sound designer and from my perspective AAF is not dead at all! And MXF seems to have become the defacto standard exchange format for digital cinema as part of the DCP (Digital Cinema Package). But OMF is still used extensively because everybody is used to it and it fulfills the basic needs.
Regarding tj's and your remarks on support, I suspect the dev community simply isn't that large = little activity. After all, this kind of technology is dominated by big players (like AVID) with proprietary file formats, which is a major pain in the ass for professionals like me! For me it would be best if everybody would agree on one format and lead it to perfection, which won't happen.
I came here to research the possibilities of writing a tool with AAF export capabilities under OSX and I'm a little bit intimidated by the complexity of the SDK. I will also try the AMWA forum and maybe the mailing list, but i guess it will be very hard for a semi-pro dev as I am. So if any of you guys has suggestions for a primer in writing AAF files (to be imported in DAWs like Pro Tools) I'd be very happy!
Sebastian
Hi Sebastian. Replying 6 years later. I am in the similar position as you. I have successfully created AAFs that import to protools. Currently Im having trouble with some API that Im hoping isnt broken by OS updates. Would be happy to chat.
A couple more questions...
1) What's the current status of the AAF source code? Is it available from SVN or GIT these days? Or is it still only available in zip form?
2) The most recent zip file I could find was dated around April 2013. Is that the current version?
I should probably report this to the developers somehow but FWIW I just tried building the (latest?) code with VS2015 Community Edition. So far I've only tried the main SDK but it won't build properly (for the Release target, AAFBasicInterpolators fails to link).
Having said that... are these mailing lists even valid any more? Or have the discussion forums moved somewhere else now??