AES Standards Relevant To Broadcasting

There are nearly 60 different standards currently available from the AES with another 40 supporting documents that provide additional advice on how to deploy them.

AES strives to avoid the use of patented technologies or requires the patent holder to allow their use on a minimal or zero fee basis. The society also collaborates with other standards bodies such as the SMPTE, ISO, IEC, BSI and EBU.

The AES Standards are in common use all over the world, largely working unseen but nevertheless vitally important.

These standards are particularly relevant to the design of workflows in IP studios and ST 2110. The rest of the AES standards are also useful and informative as background knowledge:

AES3 - Serial Transmission For 2-channel Digital Audio

AES3 was originally published in 1985 and has been continually revised. In 2003, amendments to the standard were incorporated into the main body. In 2009, the 2003 edition was divided into four separate parts which are now published separately. The entire set was reaffirmed in 2019 being deemed up to date and not requiring changes at that time.

This standard describes how to transmit two channels of digital audio over a variety of different mediums. The supported audio format is linear Pulse Code Modulation (PCM) which is an uncompressed stream of samples. Sample sizes between 16 and 24 bits are supported. Other formats are possible but not described by AES3. See AES5 for the list of acceptable sample rates.

AES3 is composed of four parts describing Digital input-output interfacing. In particular the serial transmission format for two-channel linearly represented digital audio data.

The use of abbreviations in audio/visual contexts is sometimes ambiguous and overloaded with hidden meaning. For example, when the interface is described as AES rather than AES/EBU, the means of electrical connection might be different.

This quotation from Ray Arthur Rayburn – a highly respected audio engineer in the AES community – explains why:

“AES3 allows the use of transformer or transformerless interfaces, while the corresponding EBU standard requires the use of transformers. Therefore, it has become a common shorthand to say AES/EBU when the interface is transformer coupled, and AES3 when it is not or if the interface type is unknown.”

AES/EBU is described in the third edition of the EBU Tech 3250 document.

Also see document AES2id which provides guidelines for the use of the AES3 interface. The fourth edition of AES2id was published in 2020. This document provides important insights when applying AES3. Make sure you are using the most recent edition because the 2006 edition refers to the single part 2003 version of AES3. The latest version has been revised to refer to the current four part version. These standards documents are relevant to the use of AES3:

Refer to ST 2110-31 to see how AES3 is applied to a modern IP studio architecture.

AES5 - Preferred Sample Frequencies

This standard describes various sample rates and recommends 48 kHz at the outset because it is numerically easier to convert this to other sample rates. See Section 4.2 of the standard for an explanation. Sample rates at 96 and 44.1 kHz are also described.

There is an interesting paragraph on bandwidth (see Section 4.1) based on the Nyquist-Shannon sampling theorem.

Derived sample rates ranging from half to eight times the basic sample rate are also described. There are tables listing the number of samples per frame of video at different frames per second rates vs. audio sample rates.

This is an important foundational standard referred to by AES3 and AES67 and other related documents.

AES10 - Multichannel Audio Digital Interface (MADI)

The latest edition of AES10 and its supporting AES10id information document were both published in 2020.

Refer to the digital audio engineering guidelines described in the supplementary AES10id document.  This provides additional insights into how to apply the AES10 standard. The transmission data format is explained in more detail which is very helpful when developing MADI compatible interfaces.

If you intend to use this standard to design a product, there may be patent license fees to pay.

These standards documents are relevant to the use of AES10:

What Is 4B5B Encoding?

AES10 describes a bitstream format for use with MADI based on sending 4-bit frames in a 5-bit wrapper. It operates at the physical connection layer in the OSI network taxonomy. This has certain advantages for signal quality and ancillary control messages.

The 4B5B technique is a very neat solution to provide synchronization of the electro-optical signals arriving at network receivers. This operates at the physical layer in the OSI network model. This is the very lowest foundational layer that describes the electrical (or optical) connection between end-points.

This 4B5B encoding technique is used on optical fiber (FDDI), Ethernet and USB interfaces. It converts each frame of 4-bits into a 5-bit frame. There is a small disadvantage that this increases the amount of data being transmitted by 25%. This allows some of the additional values to describe ancillary control signals.

Nomenclature

This technique is sometimes described as 4B5B or 5B4B when operating in reverse. Search for both variants when looking for information. The 5B4B terminology describes data conversion from 5-bit frames to 4-bit frames. Occasionally it is used instead of 4B5B but that might be a typographical error.

A similar technique called 8B10B is described in the MADI documentation for 8-bit framing. This is far less efficient than 4B5B.

Converting From 4-bit To 5-bit

Here is the conversion between 4-bit framed data values and 5-bit frames shown as a table. Only 16 of the 32 values possible with 5-bits are needed to carry the 4-bit data:

Ancillary Symbols

Some of the other 16 values have special meaning. They are called symbols and use letters above the hexadecimal range. The symbols are somewhat mnemonic to aid in understanding their meaning:

Control Codes

The mnemonic symbols are used in various combinations to send commands ‘down the wire’. Several are used on their own, a few are used in pairs. Groups of four symbols are used on USB interfaces:

Unused Values

A few of the available 5-bit frame values are unused. If they are observed at the receiving end, it indicates a problem and helps to detect errors in the transmission:

Supporting Documents

Refer to these documents for more information:

The AES10 standard directs you to the AES web sites for details of the 4B5B line code for transmitting data on fiber optic or Ethernet connections. That document is missing but there is a very good explanation of 4B5B signaling on Wikipedia. Read that in conjunction with Annex B of the AES10 standard.

AES11 - Synchronization Of Digital Audio Equipment

Multiple channels of audio must be carefully synchronized. The sample clocks governing when the source audio is captured must be accurately regulated. Any downstream processing needs to maintain the phase relationships between channels to avoid introducing unwanted audible artefacts. This is a complex topic and there are many solutions.

Equipment using an internal sample clock must be locked to an external source. AES11 describes this as a Digital Audio Reference Signal (DARS) which is delivered separately from the audio content (usually via a separate connection). AES5 describes multiples of up to eight times the basic sample rate. The internal sample clock must be capable of reliably locking to all of these.

Alternative synchronization techniques can be used instead of DARS:

• Embedded time signatures based on the packet header timestamps. This may drift out of sync with other streams.
• Video reference syncing to frame-start events.
• GPS locking. This requires a separate receiver device and locks to real-world time.

AES11 describes the word clock (see Annex B). This synchronizes hardware devices (such as digital tape machines or CD players). The word clock governs the timing of each sample passing through the system and is derived from a centralized reference. This will be familiar to broadcast engineers who ensure that video across an enterprise is frame synchronous by distributing sync pulses from a reliable source.

The word-clock is not the same as timecode. The word-clock is integral to the sampling process and transmission of the digital audio where the timecode is a separate metadata service that describes the media being transmitted. They operate in different time domains.

AES11 refers to AES5 and augments the sample rate descriptions with advice pertaining to video reference timing.

AES11 is relevant when studying PTP and other timing protocols. In particular when designing products that need to work with ST 2110 based IP studios. The latest version of AES11 was published in 2020.

These standards documents are relevant to the use of AES11:

AES18 - Ancillary User Data Channel Format

Ancillary user specified metadata can be embedded within an AES3 audio stream. Messages can be any length. The only limitation is the maximum bitrate which caps the amount of data that can be inserted in addition to the audio payload. A long message could describe the entire asset with an abstract for display in an EPG. Shorter messages provide synchronous data such as:

• Subtitle text.
• Script cues.
• Editing information.
• Copyright assertions.
• Performer credits.
• Downstream switching instructions.

This is managed carefully to avoid delaying the audio content. Messages can be split and portions deferred to accommodate the bitrate capping limit.

Ancillary data adapts the High-level Data Link Control (HDLC) protocol originally defined in ISO 3309 (as defined in AES18). That standard has now been withdrawn and replaced by ISO 132239. HDLC is bi-directional, but in the context of AES3, the messages only travel one way with no handshaking.

Error resilience helps detect data corruption at the receiver. If necessary, important data could be delivered in a carousel-like structure and repeated periodically.

The standard lists many external references in the Annex C Bibliography. These date from the mid 1980’s to the 1990’s and cover radio text services which are now deployed worldwide. 

Because of the vintage, the specified character sets do not yet use Unicode. Text is constrained to 8-bit character codes as defined in ISO 4873. UTF-8 character encoding of Unicode text is briefly mentioned in the AES67 standard.

AES50 - High-resolution Multi-channel Interconnection

AES50 interconnections are sometimes abbreviated to HRMAI. HRMAI is intended to be used in a point-to-point fashion rather than transmitting data over a network. Having just a sender and receiver enables it to provide the following advantages:

• Supports many commonly-used digital audio coding formats, including “high-resolution” formats such as high sample-rate linear PCM, and one-bit delta-sigma modulated formats.
• Low and predictable latency less than 100 microseconds.
• Able to use CAT-5 data cable which is generally cheaper than CAT-6 or CAT-7.
• Interconnections span distances up to 100 meters.
• High-quality full-duplex clocks are transmitted in parallel with the audio data.
• Full-duplex audio interconnection allows traffic to move in both directions at the same time.
• 5 Mbit/sec full-duplex auxiliary data connection, compatible with Ethernet networks. This is in parallel with the point-to-point interconnect for audio essence.

Project report AES-R6 provides additional guidelines for deploying the AES50 standard for HRMAI connections. Read both AES50 and AES-R6 documents to gain a better understanding of HRMAI. The latest editions of both documents were published in 2020.

These standards documents are relevant to the use of AES50:

AES52 - Inserting Unique Identifiers Into AES3

Inserting unique identifiers using the 128-bit UUID standard is helpful for identifying the stream content at the receiving end. This also helps to connect the stream to metadata that may be stored in another system. The UUID message is transmitted periodically so that clients joining the stream part way through can still acquire the value.

These standards are also relevant:

The related Unique Material Number described by SMPTE ST 330 is less unique as it has fewer bits but it can use a UUID with some special formatting to implement the UMID.

AES57 - Audio Object Structures

AES57 describes the attributes for Audio Objects. These are carriers for audio essence realized as discrete samples that are packaged as multi-channel frames and presented on a timeline. These attributes are reflected as properties when the objects are instantiated in an Object Oriented programming environment.

Annex A describes an XML schema that can be used to represent audio objects.

Understanding the vocabulary used to describe the audio objects informs the design of your metadata model which facilitates the building of a reliable content management system and workflow process supervisor tool.

AES60 - AES Standard For Core Audio Metadata

This standard is described in the Information document identified as AES60id. The latest edition was published in 2020.

The AESCore metadata schema is consistent with the EBUCore schema published as EBU Tech3293. Both of these are extensions of the original DublinCore metadata schema.

EBUCore is the minimum set of attributes needed to describe video and audio media resources.

XML is used as the support and tools are widely available for creating, editing and harvesting metadata delivered in this format.

AES67 - High-Performance Streaming Audio

The original intent for AES67 was to deliver professional quality audio over a high-performance IP network with less than 10ms latency. Bridging diverse pre-existing audio networking systems to provide interoperability was also a core goal. This is suitable for sound reinforcement at live events.

High performance is feasible on existing local area networks (LAN). If suitable switching hardware is available, it can be supported widely across an enterprise.

These are the main features:

• Based on existing and well-known IT standards described in IETF RFC documents.
• Synchronization with boundary clock converters.
• Streaming transport via RTP.
• Session description with SDP.
• Low-latency delivery of uncompressed audio.
• Ideal for live, studio and broadcast situations.
• Decentralized configuration and management of devices.
• Coexists with other IT data traffic on the same network.

Prior to AES67, the available audio networking solutions were incompatible with one another. AES67 is designed to reconcile the needs of architectures designed by different manufacturers and facilitates interoperability between:

• Dante
• Ravenna
• QLAN
• WheatNet-IP
• Livewire

These topics are addressed by the standard:

Transport Synchronization - A variety of techniques are discussed in Section 4 of the standard.

Media Profiles - Standard IP networks must adhere to a media profile (see Annex A) to ensure timely delivery of packets.

Boundary Clock Converters - Networks using switching hardware that supports IEE PTP protocols can provide boundary clock conversion and should provide adequate performance for audio delivery.

AVB - Enhanced Ethernet Networks that conform to IEEE 802.1Q are described as Audio Video Bridging (AVB) and provide synchronization based on IEEE PTP. This is covered in Annexes C and D.

Media Clocks - These are described in Section 5 and provide synchronization at the sample level. A media clock advances in sync with the sample rate. The same frequency should be used for the RTP clock.

Payload Encoding - This is described in Section 7, which reiterates the limited range of three preferred sample rates from AES5 with two possible sample sizes. Packet sizes are determined primarily by how long the data in them would play for the given sample rate. AES67 describes these sample rates (derived from AES5):

• 48 kHz
• 96 kHz
• 44.1 kHz

The standardized sample sizes and formats are defined in great detail in these IETF RFC documents:

• L16 - 16-bit linear format as defined in RFC 3551 clause 4.5.11.
• L24 - 24-bit linear format as defined in RFC 3190 clause 4.

Channel Count - Up to 120 channels of audio can be carried in a generic AES67 link. ST 2110-30 limits the number of channels depending on the conformance level of the receiving device. This may be as low as four channels at level AX and not more than 64 for level C.

SDP - Session Description Protocol provides discovery and connection management support. This includes keep alive heartbeats to maintain connections. The discovery systems are described in Annex E. These include the AMWA NMOS IS-04 specification used by ST 2110.

IETF RFC References - Because this is a standard describing IP network transmission, there are many RFC documents cited in the normative references in Section 2 of the standard and more references are included in the bibliography in Annex H. Using the IETF specifications ensures compatibility with the rest of the IP network traffic.

Networked audio conforming to AES67 is used in ST 2110 installations and covered by ST 2110-30. Additional supporting documentation is available in these AES project reports:

If you intend to use this standard to design a product, there may be patent license fees to pay.

These standards documents are relevant to the use of AES67: 

AES70 - Open Control Architecture

The Open Control Architecture (OCA) was the foundation for AES70. AES70 is now the formal standard for OCA. It describes a scalable control-protocol for managing media devices over an IP network. This is quite separate to managing streaming services although it needs to take account of such traffic.

The emergence of SMPTE ST2138 develops the same concepts.

AES70 is designed around an object oriented approach to coding. It uses the HTTP accessor methods to GET or SET various properties on a target device.  Changes to a property are notified with an event that triggers a handler of some kind. This is described in the AES70 Class Structure.

The goal of AES70 is to provide full-function device control and monitoring for this range of situations:

• Professional applications.
• Multi-vendor systems.
• Mission-critical or noncritical applications.
• Media networking applications of all sizes from two to 10,000 nodes or more.
• Secure or insecure implementations.
• Multiple-controller systems.
• Peer to peer systems devoid of separate controllers.
• Audio devices are targeted now.
• Multiple connection methods are supported.
• Video devices will be targeted in future.
• Other related equipment may be scoped into AES70 as a long-term goal.
• Devices of all sizes - wall panel to mixing desk, possibly with tiny processors.
• Dynamically-reconfigurable devices.
• Products with proprietary features.
• Able to work on low and high bandwidth networks.

AES70 can operate on any IP network and uses these connection methods to reach target devices:

• WebSockets
• JSON
• TCP
• UDP

Audio devices can be controlled using adapters for these protocols. Some presentations on AES70 describe other alternatives as well:

• Dante
• Ravenna
• Milan
• AES67

Video devices are expected to be supported via adapters for these protocols. Others will be introduced in due course:

• SDVoE
• ST 2110

AES70 specifies several different protocols, not all of which have been publicly released. Currently only OCP.1 has been defined for use on TCP/IP networks. When other protocols are defined, they will all be based on the same core object model.

There are several published parts of the AES70 standard with others nearing publication. The numbering of these parts suggests there are many more to come. The descriptions of those parts is not yet publicly known outside of the AES organization. At the time of writing, this is what we know so far. The information is collated from presentations at conferences and published documents:

Parts 1, 2 and 3 describe Core functionality. Parts 21, 22 and 23 are adapters for various proprietary protocols. These work rather like software drivers. It is helpful to read the first three parts together.

If you intend to use this standard to design a product, the standard warns that there may be patent license fees to pay. However the OCA organization states that the protocols are supposed to be license free. Any patents may only affect some of the management adapters used for proprietary hardware.

AES70 is developed in collaboration with the Alliance for IP Media Solutions (AIMS) and the Open Control Architecture Alliance (OCA). Find out more about the Open Control Architecture Alliance here:

These standards documents are relevant to the use of AES70:

Whilst AES70 is a more mature technology, SMPTE ST2138 provides a wider scope of control and will emerge as a competing solution.

The IABM has published an interesting comparison table that maps various attributes of AES 70 against other control plane architectures (such as ST 2138, Ember+ and NMOS). Search online for this document title to locate a copy for downloading:

“IABM-Control-Plane-Comparison-AES”

AES77 - Loudness Of Streamed Audio

Setting the loudness of streamed audio has been an important topic for some time. Content providers have a duty to protect the consumers and avoid hearing damage. There has been a great deal of work on this topic by various organizations. AES provides a page of collected background information about the Loudness project at their web site:

These standards documents are relevant to the use of AES77. These and other useful supporting white papers and conference proceedings are linked from the AES Loudness project resources page:

Older AES Standards

Earlier AES standards are based on Asynchronous Transfer Mode (ATM) networks. An ATM network can carry voice and data simultaneously. Ethernet can only carry data but Voice over IP (VoIP) supports telephony applications as well.

AES47 & AES51 describe how to transmit audio over ATM networks.

AES Member Benefits

Being aware of everything the AES offers will enhance your skill-set when dealing with audio matters.

The AES document collection is a foundational source of reference. The standards are backed up by information documents that help you apply them and other technical documents that describe useful background and supplemental material.

Some of the newer standards such as AES70 will have a profound impact and facilitate the implementation of software defined workflows and studios. AES70 bridges between the software and hardware worlds in a very elegant way.

The benefits of joining the AES as a member far outweigh the cost of subscribing. I cannot recommend this highly enough.

These Appendix articles contain additional information you may find useful: