Ambisonic data exchange formats. Data exchange formats for Ambisonics have undergone radical changes since the early days of four-track magnetic tape. Researchers working on very high-order systems found no straightforward way to extend the traditional formats to suit their needs. Furthermore, there was no widely accepted formulation of spherical harmonics for acoustics, so one was borrowed from chemistry, quantum mechanics, computer graphics, or other fields, each of which had subtly different conventions. This led to an unfortunate proliferation of mutually incompatible ad hoc formats and much head-scratching.

This page attempts to document the different existing formats, their rationales and history, for the terminally curious and those unfortunate enough to have to deal with them in detail.

Most modern applications use ACN and SN3D, although traditional first order is still common.

Spherical harmonics in Ambisonics 
A common formulation for spherical harmonics in the context of Ambisonics is

where  denotes a spherical harmonic of degree  and index  with a range of .

(Note that if , then .)

 is a normalisation factor (see below), and  is the associated Legendre polynomial of degree  and order .
The azimuth angle  is zero straight ahead and increases counter-clockwise. The elevation angle  is zero on the horizontal plane and positive in the upper hemisphere.

Unfortunately, the "Ambisonic order"  is called the degree in mathematical parlance, which uses order for the "Ambisonic index" .

Relationship of spherical harmonics and B-format signals 

For a source signal  in direction , the Ambisonic components   are given by

If we span a direction vector from the origin towards the source until it intersects the respective spherical harmonic, the length of this vector is the coefficient that gets multiplied with the source signal. Repeat for all spherical harmonics up to the desired Ambisonic order.

Prerequisites for successful data exchange 

For successful exchange of Ambisonic material, some software requires the sender and receiver have to agree on the ordering of the components, their normalisation or weighting, and the relative polarity of the harmonics.

Since it is possible to omit parts of the spherical harmonic multipole expansion for content that has non-uniform, direction-dependent resolution (known as mixed-order), it might also be necessary to define how to deal with missing components.

In the case of transmission "by wire", be it an actual digital multichannel link or any number of virtual patchcords within an audio processing engine, these properties must be explicitly matched on both ends, since there is usually no provision for metadata exchange and parameter negotiation. In the case of files, some flexibility might be possible, depending on the file format and the expressiveness of its metadata set.

However, in practice, just two formats are in widespread use. The first is Furse-Malham higher-order format, which is an extension of traditional B-Format, and the more modern SN3D, in ACN channel order. In neither case is there any ambiguity about ordering, normalisation, weighting or polarity and it is rare to see cases with missing components. A third format is in limited use: N3D, also in ACN channel order.

Component ordering 

The traditional B-format () only concerned itself with zeroth and first Ambisonic order. Because of a strong correspondence between the spherical harmonics and microphone polar patterns, and the fact that those polar patterns have clearly defined directions, it seemed natural to order and name the components in the same way as the axes of a right-hand coordinate system.

For higher orders, this precedent becomes awkward, because spherical harmonics are most intuitively arranged in symmetric fashion around the single z-rotationally symmetric member m=0 of each order, with the horizontal sine terms m<0 to the left, and the cosine terms m>0 to the right (see illustration).

Furse-Malham 

In Furse-Malham higher-order format, an extension of traditional B-format up to third order, orders 2 () and 3 () begin with their z-rotationally symmetric member and then jump outward right and left (see table), with the horizontal components at the end. Higher-order extensions are trivially defined, but are not used.

SID 

In his seminal 2001 thesis, Daniel used a three-index nomenclature  for the spherical harmonics, which corresponds to  in the notation used here. He implied yet another channel ordering, subsequently developed into an explicit proposal called SID for Single Index Designation which was adopted by a number of researchers. This scheme is compatible with first-order B-format, and continues to traverse the higher spherical harmonics in the same fashion, with the z-rotationally symmetric component at the end, going through the horizontal components first. It is, however, incompatible with Furse-Malham. SID ordering is not in widespread use.

ACN 

For future higher-order systems, adoption of the Ambisonic Channel Number (ACN)
has reached wide consensus. It is determined algorithmically as .

ACN is used widely with SN3D and N3D, below.

More simply:

FuMa = WXYZ | RSTUV | KLMNOPQ

ACN  = WYZX | VTRSU | QOMKLNP

SID  = WXYZ | UVSTR | PQNOLMK 

SID used in iem_ambi in Puredata.

Normalisation 
For successful reconstruction of the sound field, it is important to agree on a normalisation method for the spherical harmonic components. The following approaches are common:

maxN 
The maxN scheme by Daniel normalizes each single component to never exceed a gain of 1.0 for a panned monophonic source. Malham states that "[w]hilst this approach is not rigorously "correct" in mathematical terms, it has significant engineering advantages in that it restricts the maximum levels a panned mono source will generate in some of the higher-order channels."
This property is particularly interesting for fixed-point digital interfaces. The maxN weights may be determined by visual inspection up to the third order; above this value the maxima of each polynomial need to be determined explicitly.

MaxN is used in the Furse-Malham format (with the exception of a -3dB correction factor for , which makes it directly compatible with traditional B-Format). Otherwise, it is not in widespread use.

SN3D 
SN3D stands for Schmidt semi-normalisation and is commonly used in geology and magnetics. The weighting coefficients are

Originally introduced into Ambisonic use by Daniel, he notes: "High degree of generality - the encoding coefficients are recursively computable, and the first-order components are unity vectors in their respective directions of incidence".

With SN3D, unlike N3D, no component will ever exceed the peak value of the 0th order component for single point sources.
This scheme has been adopted by the proposed AmbiX format.

SN3D (in the ACN channel order) is in widespread use and a common choice in new software development.

In the Ambix specification paper the term  is replaced with .

N3D 
N3D or full three-D normalisation is the most obvious approach to normalisation. Daniel describes it as follows: "Orthonormal basis for 3D decomposition. Simple relationship to SN3D [..]. Ensures equal power of the encoded components in the case of a perfectly diffuse 3D field. [..] Obvious significance for solving decoding problems [..] (3D reconstruction)."

The relation to SN3D is

This normalisation is standard in physics and mathematics and is supported by some Ambisonic software packages. It is used in MPEG-H. However, SN3D is now much more common.

As N3D and SN3D differ only by scaling factors, care is needed when working with both, as it may not be obvious on first listening if an error has been made, particularly on a system with a small number of speakers.

N2D / SN2D 
Additionally, two schemes exist which consider only the horizontal components. This has practical advantages for fixed-point media in the common situation where sources are concentrated on the horizontal plane, but the normalisation is somewhat arbitrary and its assumptions do not hold for strongly diffuse soundfields and sound scenes with strong elevated sources. Since Ambisonics is meant to be isotropic and the 2D schemes definitely are not, their use is discouraged.

Polarity 
A third complication arises from the quantum mechanical formulation of spherical harmonics, which was adopted by some Ambisonics researchers. It includes a factor of , a convention called Condon–Shortley phase, which will invert the relative polarity of every other component within a given Ambisonic order. The term can be folded both into the formulation of the associated Legendre polynomials or the normalisation coefficient, so it may not always be obvious.

MATLAB and GNU Octave both include Condon–Shortley phase in its legendre(ℓ,X) functions, but undo it by applying the factor again in the Schmidt semi-normalized form legendre(ℓ,X,'sch').

Wolfram Language also includes C-S phase in its legendreP(ℓ,X) implementation, and retains it in SphericalHarmonicY[ℓ,m,θ,φ], which is fully normalized.  Note that this function returns complex values and uses the physics convention for spherical coordinates where  is the zenith angle (angle from the positive Z-axis) and  is the azimuth (counter-clockwise angle around the positive Z-axis).

The presence of Condon–Shortley phase in parts of the signal chain usually manifests itself in erratic panning behaviour and increasing apparent source width when going to higher orders, which can be somewhat difficult to diagnose and much harder to eliminate. Hence, its use is strongly discouraged in the context of Ambisonics.

None of the ambisonic exchange formats described above use Condon–Shortley phase. Polarity is generally only a concern when trying to reconcile theoretical formulations of the spherical harmonics from other academic disciplines.

Reference table of layouts and normalisations 

The following table gives an overview of all Ambisonic formats published so far.
 For Furse-Malham (and traditional B-format), sort by FuMa column and multiply the spherical harmonic by the maxN* factor.
 For SID according to Daniel, sort by SID and apply the relevant normalisation factor as specified in the file metadata.
 For basic AmbiX, sort by ACN and use the SN3D factor.
 For extended AmbiX and all other combinations, good luck!
Conversion factors can be applied either to the Ambisonic components  or the spherical harmonics .

The data is taken from Chapman (2008).

Please do not rely on this table until it has been thoroughly checked and the "Under construction" notice has been removed.

However, please note that only the Furse-Malham and SN3D/ACN encodings are in wide use. (Traditional B-Format is a subset of Furse-Malham.) For both of these encodings, the equations can be expressed directly, without separate normalisation or conversion factors, and there is no ambiguity around ordering.

File formats and metadata 
For file-based storage and transmission, additional properties need to be defined, such as the base file format and, if desired, accompanying metadata.

AMB 

The .amb file format was proposed and defined by Richard Dobson in 2001, based on Microsoft's WAVE_FORMAT_EXTENSIBLE amendment to the WAV audio file format. It mandates the use of Furse-Malham encoding.

From its parent, it inherits a maximum file size of 4GB, which is a serious limitation for live recording in higher orders.

.amb Files are distinguished from other multichannel content by their suffix and by setting the file subtype Globally Unique Identifier in their header data to either of the following values:
 SUBTYPE_AMBISONIC_B_FORMAT_PCM {00000001-0721-11d3-8644-C8C1CA000000} for integer samples, or
 SUBTYPE_AMBISONIC_B_FORMAT_IEEE_FLOAT {00000003-0721-11d3-8644-C8C1CA000000} for floating point.
The definition mandates that the WAVE_EX dwChannelMask must be set to zero. Furthermore, it recommends that the file should contain a PEAK chunk, containing the value and position of the highest sample in each channel.

The channels within an .amb file are interleaved, and any unused channels are omitted. This makes it possible to identify traditional #H#P mixed-order content by the number of channels present, as per the following table:

The free and open source C library libsndfile has included .amb support since 2007.

Dobson's format has been instrumental in making native Ambisonic content easily accessible to enthusiasts, and to pave the way for research and deployment of Higher-order Ambisonics. While it cannot scale any further than third order and does not accommodate #H#V mixed order sets, its capabilities are more than sufficient for most Ambisonic content in existence today, and backwards-compatibility to .amb is an important feature of any real-world Ambisonic workflow.

AmbiX 
AmbiX adopts Apple's Core Audio Format or .caf. It scales to arbitrarily high orders and has no practically relevant limitation of file size. 
AmbiX files contain linear PCM data with word lengths of 16, 24, or 32 bit fixed point, or 32 or 64 bit float, at any sample rate valid for .caf. It uses ACN channel ordering with SN3D normalisation.

The basic format of AmbiX mandates a complete full-sphere signal set, the order of which can be uniquely and trivially deduced from the number of channels. Only the minimum header information required by the .caf specification are present and no other metadata is included.

The extended format is marked by the presence of a User-Defined Chunk with the UUID
1AD318C3-00E5-5576-BE2D-0DCA2460BC89.
(The original specifications used , which is an invalid UUID
).
Additionally, the header now contains an adaptor matrix of coefficients, which needs to be applied to the data streams before they can be played back. This matrix provides a generic way of mapping payloads in any previous format and any mix of orders to canonical periphony, ACN ordering and SN3D normalisation. Theoretically, it can even accommodate sound fields that span only subsets of the sphere.

AmbiX was originally proposed at the Ambisonic Symposium 2011, building upon previous work by Travis and Chapman et al.

Notes

References

External links 
 Notes on Basic Ideas of Spherical Harmonics, an introductory text by Robert E. Greene

Data exchange formats