AES52-2006

AES standard for digital audio

engineering —
Insertion of unique identifiers into
the AES3 transport stream
Published by
Audio Engineering Society, Inc.
Copyright ©2005 by the Audio Engineering Society

Abstract
The AES3 transport stream continues to be used extensively in both discrete and network based audio systems
alongside audio stored as files. Audio content is moving towards being handled by asset management systems
and descriptive metadata associated with that content is also being stored within systems. In order to provide a
mechanism for AES3 transport streams to have similar abilities to work with content management systems,
some form of unique label is required which can provide the link with these systems. One of the unique labels
currently standardised in the media industry is the SMPTE UMID while another commonly used in the
Information Technology area is the IEC UUID.

This standard specifies the method for inserting unique identifiers into the user data area of an AES3 stream.
This specifically covers the use of UUID as well as a basic or extended SMPTE UMID.

An AES standard implies a consensus of those directly and materially affected by its scope and provisions and is
intended as a guide to aid the manufacturer, the consumer, and the general public. The existence of an AES
standard does not in any respect preclude anyone, whether or not he or she has approved the document, from
manufacturing, marketing, purchasing, or using products, processes, or procedures not in agreement with the
standard. Prior to approval, all parties were provided opportunities to comment or object to any provision.
Attention is drawn to the possibility that some of the elements of this AES standard or information document
may be the subject of patent rights. AES shall not be held responsible for identifying any or all such patents.
Approval does not assume any liability to any patent owner, nor does it assume any obligation whatever to
parties adopting the standards document. This document is subject to periodic review and users are cautioned to
obtain the latest edition. Recipients of this document are invited to submit, with their comments, notification
of any relevant patent rights of which they are aware and to provide supporting documentation.

Courtesy preview copy

No printing or copying
 aes52-2006
-2 -

Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1 Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Definitions and abbreviations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4 Relationship between audio and identifier. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4.1 UID symbol rate................................................................................................................... 5
4.2 System transparency .......................................................................................................... 5
5 UID minimum implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

6 UID data transport in AES3 streams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

6.1 UID indication in AES3 channel status .................................................................................. 5
6.2 UID transport ...................................................................................................................... 5
6.3 UID signaling ...................................................................................................................... 6
Annex A: (Normative) Block CRCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Annex B: (Normative) UMID CRC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Annex C: (Informative) Real-time symbol rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Annex D: (Informative) Informative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 0

Annex E: (Normative) Unique material identifiers (UMID) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1

E.1 UMID format ..................................................................................................................... 11
E.2 UMID data block format...................................................................................................... 11
Annex F: (Normative) Universal unique identifiers (UUID). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3
F.1 UUID format ...................................................................................................................... 13
F.2 UUID data block format ...................................................................................................... 13

2006-02-25 printing
Courtesy preview copy
No printing or copying
 aes52-2006
-3 -

Foreword
[This foreword is not part of the document: AES52-2006 Insertion of Unique Identifiers into the AES3
transport stream.]

This document was developed under project AES-X111 Transmission of a unique identifier on AES3. It was
initially written by task group SC-02-02-G led by C. Chambers.

The members of the task group were: D.
Ackerman, R.
Caine, C.
Gaunt, J.
Grant, A.
Mason, T.
Sheldon,
J.
Strawn, M.
Yonge.

John Grant, chair

Robert A. Finger, vice-chair
SC-02-02 Working Group on Digital Audio Input/Output Interfacing

NOTE: In AES standards documents, sentences containing the word “shall” are requirements for
compliance with the document. Sentences containing the verb “should” are strong suggestions
(recommendations). Sentences giving permission use the verb “may”. Sentences expressing a
possibility use the verb “can”.

2006-02-25 printing
Courtesy preview copy
No printing or copying
 aes52-2006
-4 -

AES standard for digital audio

engineering —
Insertion of unique identifiers into
the AES3 transport stream
Introduction
A unique identifier is used for the automatic identification of a digital audio stream and to provide a key to
related data, or metadata, held in a separate system. In order to maintain an accurate relationship between the
audio content and the unique ID, it is recommended that the following points be considered when implementing
this standard.

• The unique identifier should be capable of being inserted in a consistent way in synchronism with the audio
data it applies to at any AES3 input interface.
• The unique identifier should be capable of being extracted and reinserted at any point where the content of
the audio data may be changed or the ID data could be changed by processes acting on the AES3 transport
stream. A different ID may be applied at this point in synchronism with new or changed audio content.
• Systems monitoring an AES3 interface should be able to automatically identify the audio data stream by
extracting the globally unique reference from the data that can then be used as a look-up label in external
systems.
• Interfaces which insert, extract, reinsert or monitor the ID "data stream" should not reduce the ID symbol
rate (see clause 6) on any AES audio path.

1 Scope
This standard specifies a method for the insertion of a unique identifier into an AES3 digital audio signal.

This document does not cover unique ID usage policy.

2 Normative references
The following referenced documents are indispensable for the application of this document. For dated references,
only the edition cited applies. Clause and figure numbers in references apply to the edition cited. For undated
references, the latest edition of the referenced document (including any amendments) applies.

AES3-2003, AES Recommended Practice for Digital Audio Engineering — Serial transmission
format for two-channel linearly represented digital audio data. Audio Engineering Society, New
York, NY. US.

SMPTE 330M-2004, SMPTE Standard for Television — Unique Material Identifier (UMID)

ISO/IEC 11578-1996, - Information technology - Open Systems Interconnection - Remote Procedure Call
(RPC) [Annex A: Universal Unique Identifier]

2006-02-25 printing
Courtesy preview copy
No printing or copying
 aes52-2006
-5 -

3 Definitions and abbreviations

3.1 Unique Identifier
UID
general term to describe a code, carefully constructed to be unique within specified bounds, that is used to
identify an associated stream or object unambiguously.

3.1 Unique Material Identifier

UMID
unique identifier defined in SMPTE 330M

3.2 Universal Unique Identifier

UUID
unique identifier defined in ISO/IEC 11578-1996, annex A

4 Relationship between audio and identifier

4.1 UID symbol rate

Within the AES3 interface stream, the complete identifier data should be embedded with the audio data at a
minimum rate to suit the identification time resolution expected by the system or process using this data. The
number of blocks between iterations of the UID is known as the UID symbol rate and will be the main time-
determining factor in systems accurately resolving changes to the audio content of the data stream.

4.2 System transparency

Where an AES3 data stream passes through a device that does not change the audio content or the UID, the
synchronism of the UID with the audio data stream shall be maintained. This applies to both instantaneous and
audio storage AES3 input / output devices such as an AES3 distribution amplifier or an audio record and
playback device where the input and output are based on AES3 format digital audio.

5 UID minimum implementation

Various UID types may be carried in the AES3 data stream with each type being signaled appropriately
(see
6.3). Source implementations shall implement at least one of UMID (annex
E) or UUID (annex
F).
Receive implementations shall implement at least UMID and UUID.

6 UID data transport in AES3 streams.

6.1 UID indication in AES3 channel status

To indicate that the User Data stream carries ID data, the user-bit management status data shall be set to 0101,
“reserved for metadata” (signaled by bits 4 to 7 of octet
1 in the AES3 channel status data) see AES3-2003
clause
6.

6.2 UID transport

UID data is transported from one source to one or more receivers. The unique identifier data from the source
shall be carried in the AES3 "U" bit (user data) block (see AES3-2003 clause 5). Note that this provides separate
UIDs for each of the two audio channels in the AES3 frame.

More than one UID type may be carried sequentially on a single AES3 stream providing the minimum symbol
rate for overall system performance is achieved.

Note; as differing UID schemes are of differing symbol lengths which are encapsulated within a
different number of blocks (see Annex E and F), it is important that interpretations of different

2006-02-25 printing
Courtesy preview copy
No printing or copying
 aes52-2006
-6 -

UID schemes are treated as parallel processes to ensure the best time resolution is achieved
for a particular UID scheme. Annex C provides further information on real time symbol rates.

6.3 UID signaling

UID types used in this context shall use a fixed number of blocks to ensure a predictable symbol rate.

For each block, a 4-bit UID type code in octet
0, bits 0 to 3 shall identify the UID type according to Table
1
used in conjunction with the relevant normative annexes.

For each block, octet
0, bits 4 to 7 shall provide additional signaling information for the identified code type to
enable the UID data to be decoded correctly, and to reassemble multi-block data where appropriate.

Table 1: Identifier types

UID type code UID type

0000 No UID
1111 UMID (see annex
E)
0111 UUID (see annex
F)
other values reserved

NOTE additional UID types may be standardised in the future

2006-02-25 printing
Courtesy preview copy
No printing or copying
 aes52-2006
-7 -

Annex A: (Normative)

Block CRCC

UID Block Data cyclic redundancy check character (CRCC).

The generating polynomial shall be:

G(x) = x8 + x4 + x3 + x2 + 1

The CRCC conveys information to test valid reception of the entire channel status data block (bytes
0 to 22 inclusive). For serial implementations the initial condition of all ones should be used when
generating the check bits with the LSB transmitted first.

2006-02-25 printing
Courtesy preview copy
No printing or copying
 aes52-2006
-8 -

Annex B: (Normative)

UMID CRC

A 16-bit cyclic redundancy check (CRC) word shall be generated for each UMID. This field shall be octet-
aligned with respect to the start of the UMID. The bits included in the CRC check shall be all those in the
UMID.

The generator polynomial for this check word shall be

G(X) = X1 6 + X1 5 + X2 + 1

The method is depicted in Figure B1. The initial state of the shift register T should be:

1111 1111 1111 1111

All the bits to be included in the CRC shall be shifted into the shift register in the order in which they occur in
the audio coder control data bit stream. After the last shift operation, the outputs b15…b0 shall constitute the
CRC word to be used.

Data bits

T15 T14 T13 T2 T1 T0

b15 b14 b13 b2 b1 b0

Figure B1 — CRC check generator

2006-02-25 printing
Courtesy preview copy
No printing or copying
 aes52-2006
-9 -

Annex C: (Informative)

Real-time symbol rate

The minimum symbol rate is determined by the number of data blocks needed to contain the identifier, hence the
number of blocks that must pass before a new identifier value can be started. In practice, the real-time
resolution depends on the AES3 block rate, which in turn depends on the sampling frequency of the associated
audio.

Where multiple identifiers are concatenated in a single stream, or where UIDs are separated by one or more blank
blocks (“no UID”), the actual symbol repetition rate, in blocks, may differ from the minimum rate.

Table C1: Real-time symbol rate (ms)

UID Symbol rate Audio sampling frequency

(blocks) 48 kHz 96 kHz 192 kHz
1 4 2 1
2 8 4 2
3 12 6 3
4 16 8 4
5 20 10 5
8 32 16 8
10 40 20 10

Note: In general, AES3 blocks, and hence these UIDs, cannot be locked to video. The exception would be
where frames of 25-Hz video are locked to 10 blocks of audio at 48 kHz sampling, although the phase may be
hard to predict.

2006-02-25 printing
Courtesy preview copy
No printing or copying
 aes52-2006
- 10 -

Annex D: (Informative)

Informative references

DCE 1.1: Remote Procedure Call. CAE Specification, Document Number: C706. Open Group, 1997
http://www.opengroup.org/bookstore/catalog/c706.htm (UUID Pages 653 - 660)

ITU-T X.667, Information technology – Open Systems Interconnection – Procedures for the operation of OSI
registration authorities: Generation and registration of Universally Unique Identifiers (UUIDs) and their use as
ASN.1 object identifier components, International Telecommunications Union, 2004-09.

2006-02-25 printing
Courtesy preview copy
No printing or copying
 aes52-2006
- 11 -

Annex E: (Normative)

Unique material identifiers (UMID)

E.1 UMID format

The format of the UID shall comply with SMPTE 330M Unique Material Identifier (UMID). The length of the
UMID may be 32 octets (Basic UMID) or 64 octets (Extended UMID).

The UMID is checked against possible errors that may occur during extraction and reinsertion (i.e. during bit
rate conversion) by a 16 bit CRC that shall be generated during the first application of a particular UMID to the
content of an AES3 stream.

E.2 UMID data block format

The data from each UMID shall be carried by two (Basic UMID) or three (Extended UMID) 24-octet blocks of
data. Each block shall carry a 4-bit code to identify UMID data, a block sequence identifier to enable correct
retrieval of the UMID, and an 8-bit CRC which shall be generated for each 24-octet block using the method
shown in Annex A.

The data from each UMID shall be packed into 2 or 3 24-octet data blocks sequentially, as shown in the
following tables and these shall be transmitted in the order of Block 1, Block 2, Block 3, Block 1 etc. or Block
1, Block 2, Block 1 etc. depending on the transmission of 64 or 32 byte UMID as indicated by the block
identity of the second block. This allows the insertion of both the Basic and Extended UMID as required
throughout the existence of an AES3 stream. The block 1 identity shall be used to indicate the beginning of the
UMID data.
Table E1: UMID Block 1 table

Octet Bits Use

0 0 to 3 1111 (UMID ID type identifier)
0 4 to 7 0000 (Block 1, UMID)
1 to 22 Octets 0 to 21 of the UMID.
23 CRC for the block (See Annex A).

Table E2: UMID Block 2 table: Only used for 32-octet Basic UMID

Octet Bits Use

0 0 to 3 1111 (UMID ID type identifier)
0 4 to 7 0001 (Block 2, 32-octet Basic UMID)
1 to 10 Octets 22-31 of the 32-octet Basic UMID
11 to 12 16-bit CRC generated for the 32-octet Basic UMID using
the method shown in Annex B.
13 to 22 Shall be reserved for future standardization. Their values
shall be set to zero.
23 CRC for the block (see Annex A).

2006-02-25 printing
Courtesy preview copy
No printing or copying
 aes52-2006
- 12 -

Table E3: Alternate block 2 - used only for 64 octet extended UMID

Octet Bits Use

0 0 to 3 1111 (UMID ID type identifier)
0 4 to 7 0010 (Block 2, 64-octet extended UMID)
1 to 22 Octets 22 to 43 (64-octet extended UMID)
23 CRC for the block (see Annex A).

Table E4: Block 3 - used only for 64 octet extended UMID

Octet Bits Use

0 0 to 3 1111 (UMID ID type identifier)
0 4 to 7 0011 (Block 3, 64-octet extended UMID)
1 to 20 Octets 44 to 63 (64-octet extended UMID).
21 to 22 16-bit CRC generated by the 64-octet extended UMID
data using the method shown in Annex B.
23 CRC for the block (see Annex A).

2006-02-25 printing
Courtesy preview copy
No printing or copying
 aes52-2006
- 13 -

Annex F: (Normative)

Universal unique identifiers (UUID)

F.1 UUID format

The format of the UID shall comply with ISO/IEC 11578, annex A. The length of a UUID is 16 octets and
may also be presented in spaced hexadecimal format such as shown here for example.
00000000-0000-0000-0000-000000000000
This example shows the only special case known as a “null UUID” which is clearly not unique. It may be used
as an indication that the UUID is being reset or changed.

F.2 UUID data block format

The UUID data shall be carried in one 24 octet block. This block shall also carry a UID type identifier (0111),
application signaling data to confirm changes in stream ID or content and an 8-bit CRC which shall be
generated for the 24-octet block using the method shown in Annex A
The data from each UUID shall be packed into data blocks as shown in the following table.

Table F1: UUID: Block table

Octet Bits Use

0 0 to 3 0111 (UID type identifier for UUID)
0 4 to 7 Application signaling (see separate table below)
1 to 17 Octets 0-16 of the UUID.
18 to 22 Reserved for future use.
23 CRC for the block (See Annex A).

Table F2: UUID: Octet 0 bits 4-7 Application signaling

Bits 4 to 7 Use Notes

0000 Default- no signaling Null setting when signaling data not available.
available
1000 Default, signaling active Indicates that the application signaling data is
active.
1001 Audio change boundary Indicates a point in the AES3 stream where a
change in audio stream data occurred.
1010 UID change warning Provides a method of giving advance warning or
conformation of an UID change.
other values Reserved for future use

2006-02-25 printing
Courtesy preview copy
No printing or copying