Together with multiple other EBU members we developed the EBU ADM Renderer (EAR), a production renderer for audio described by ADM metadata. It is specified in EBU Tech 3388 and accompanied by an open-source reference implementation written in Python. Recently all the hard work we put into this project got rewarded: the EAR won the EBU Technology & Innovation award. If you are interested in the EAR, make sure to check out our blog post and this article from our colleagues from the BBC about it.
But we do not rest on our oars, instead we are encouraged to continue our work to establish a complete object-based workflow based on open standards. As another piece of the puzzle we have just released two open-source C++ libraries: libbw64 and libadm. Both libraries are licensed under the permissive Apache 2.0 license.
Although the RIFF WAVE file format was first published over 25 years ago, it is still an ongoing success and the standard for uncompressed audio. But time doesn’t stand still and over the years the file format went through several revisions and several extensions like RF64 and BWF were specified. The latest partner in this family of file formats based on RIFF WAVE is BW64 (Recommendation ITU-R BS.2088).
BW64 extends the RIFF WAVE file format to support files bigger than 4 GB. This works exactly as in RF64, which introduced this extension in 2007. Especially for object-based productions this is crucial, as depending on the production the number of channels can easily get quite big. But apart from that BW64 also adds support to store Audio Definition Model (ADM) metadata alongside the file in the additional ‘axml’ chunk. Using the ADM it is possible to describe all different kinds audio (channel-based, object-based and scene-based) in a unified way (read more about it in the following section about libadm). As the ADM metadata is file format agnostic another chunk is necessary to link the ADM metadata with the tracks in the file – the ‘chna’ (short for channel allocation) chunk. This chunk contains a table with track numbers and ADM element IDs.
The de facto standard library for the RIFF WAVE file format is libsndfile. Unfortunately support for BW64 hasn’t been implemented yet. Also for some smaller projects one might not need the full power of libsndfile, but rather favours a more lightweight solution. This is were libbw64 comes in. It is a modern lightweight header only C++ library which supports reading and writing BW64 files in an easy way.
Interactive and immersive audio is on the rise and the fixed channel-based approach with his success story of a hundred years reaches its limits. To overcome these limitations the Audio Definition Model (ADM) (Recommendation ITU-R BS.2076) was born. It formalises the description of all the different types of audio – be it channel-based, object-based or scene-based audio and combines it with interactivity and personalisation features.
Of course this additional functionality comes with an additional level of complexity. The following diagram shows the basic structure of the ADM, to give you a feeling for what is necessary to support all these features of future audio.
Managing the ADM in a C++ context in a reliable way can be quite cumbersome. To simplify the handling of ADM metadata we wrote the libadm library. Parsing ADM metadata from an XML representation (see EBUcore) is basically a one-liner, as is writing. But also creating and modifying ADM metadata can be done very conveniently and reliable. If you want to know more about the underlying concepts, have a look at the documentation.
Even though some ADM sub-elements are not yet supported by libadm, we didn’t want to keep you waiting and give you the opportunity to lay your hands on the library as soon as possible. We will continue to improve the library and welcome you to file bug reports, contribute code, or just tell us your experience with it. Ideally use the issue trackers on github (libbw64#issues, libadm#issues) for your feedback.
If not C++, but Python is your weapon of choice, yet you are still looking for an ADM and/or BW64 implementation, have a look at the EAR reference code. The ear.fileio submodule provides a similar functionality in a nice pythonic way.