Standards In Print

• ZIP archive extractor, such as: Stuffit Expander (Mac), WinZip (Windows).
• HTML Web browser, such as Internet Explorer, Safari, or Firefox.
• PDF viewer, such as Adobe Acrobat Reader.

The "minimum" implementation of Channel Status was included in the original AES3 specification to allow implementers to reduce the complexity of transmitting interfaces. Its use has always been discouraged, and in the context of current electronics hardware the complexity saving compared to the Standard implementation is not significant. Moreover, it adds complexity to receivers by requiring them to recognize a special case which does not have a correct CRC in byte 23, and in practice many receivers do not recognize it and flag a CRC error.

This Amendment withdraws the "minimum" implementation of Channel Status. Thus transmitters that use it will no longer conform to AES3, but the practice of insisting on a correct CRC in receivers now will conform.

This Amendment also adds a code point to byte 1, bits 4 to 7, to support the carriage of MIDI data in the user bits as specified in IEC 62537 (digital interface for loudspeakers).

Weighted peak flutter is measured using a 3150-Hz tone transmitted through the equipment. The tone is frequency demodulated, frequency-response weighted, peak-to-peak detected, time-response weighted, and read out on a two-sigma statistical voltmeter over a period of at least 5 s. Results are reported as weighted peak flutter of the recorder (or reproducer, or recording/reproducing system): +/-___ percent.

A toleranced graph and table give the frequency-response weighting (approximately at 6-dB-per-octave drop above and below 4 Hz, with an additional drop below 0,5 Hz). The statistical voltmeter is described; it is preferred, and replaces the quasi-peak meter (now deprecated) of the original standard.

Good engineering practices are given for the meter design. The rationale for this standard is given in an annex. This standard has technical requirements identical to IEC 60386 Ed.1 1972 as amended by IEC 60386-am1, 1988. Measurement results according to this standard are identical to those made according to the older standards originally published as IEEE Std-193, IEC 60386 Ed.1 1972, CCIR 409-2, and DIN 45 507. (13 pages)

This standard describes the data organization for a multichannel audio digital interface. It includes a bit-level description, features in common with the AES3 two-channel format, and the data rates required for its utilization. The specification provides for the serial digital transmission of 32, 56, or 64 channels of linearly represented digital audio data at a common sampling frequency within the range 32 kHz to 96 kHz, having a resolution of up to 24 bits per channel. The format makes possible the transmission and reception of the complete 28-bit channel word (excluding preamble) as specified in AES3, providing for the validity, user, channel status, and parity information allowable under that standard. The transmission format is of the asynchronous simplex type and is specified for a single 75-ohm coaxial cable point-to-point interconnection or the use of fibre-optic cables.

This revision includes minor changes to conform to recent revisions of AES3 and AES5 and provides clarifications of sync reference signals and link transmission-rate tolerance, and references for 'NRZI' and the 4B5B coding scheme. (18 pages)

As well as the audio data, a BWF file (BWFF) contains the minimum information - or metadata - that is considered necessary for all broadcast applications. The Broadcast Wave Format is based on the Microsoft WAVE audio file format. This specification adds a “Broadcast Audio Extension” chunk to the basic WAVE format.

The 2006 revision specifies an Organisationally Unique Identifier, and simplifies the minimum requirements to ensure interworking. (26 pages)

Report AES R4-2002, also available from this site, is a useful explanatory supplement

Companion document AES-R6-2005 provides additional background information and implementation guidelines.

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.

MPEG Surround is an ISO/IEC standard to extend mono or stereo audio towards multiple channels. The mono or stereo audio channels represent a downmix of the original multi-channel audio that is generated by the MPEG Surround encoder. In addition the MPEG Surround encoder generates spatial side information (MPEG Surround data). An MPEG Surround decoder is able to combine this information with the downmix to result in a multichannel audio signal. In this way backward compatibility to mono and stereo systems is achieved.

This standard specifies how MPEG Surround shall be carried within an AES3 bitstream where the downmix channels remain in the linear PCM domain and the MPEG Surround data is encoded into the least-significant bits of the PCM audio data.

See also AES3-Am5-2008 for relevant amendments in the AES3 transport stream

Substantially revised and extended in 2006 (65 pages)

There have been many improvements in PC audio since the original AES-6id document was published. This revision of AES-6id-2000 includes substantial updates that reflect the improvements in the PC sound sub-system, as well as some updates based on many real world measurements.(48 pages)

This information document reviews various ways of characterizing and quantifying jitter, and refines several of them for audio purposes. It also attempts to present a common, unambiguous terminology. Its focus includes wideband jitter, baseband jitter, jitter spectra, period jitter, long-term jitter and jitter signatures. Comments are made on jitter transfer through phase-locked loops and on the jitter susceptibility of audio converters. (25 pages)

The report was revised in 2007 to correspond to the 2006 edition of AES47 and to take account of other events such as the publication of AES51, AES52, and AES53. (21 pages)

Problems occur because the actual peak values of a sampled signal usually fall between sampling instants rather than precisely at a single sampling instant. This results in several peak-sample meter anomalies, including inconsistent peak readings, unexpected overloads, and under-reading and beating of metered tones.

In order to meter the maximum amplitude, or true-peak value, of a sampled signal it is necessary to over sample (or up sample) the signal, essentially using interpolation to increase the sampling frequency of the signal and thus recreating the original signal between the existing samples.

This report discusses criteria for the design of a true-peak meter and proposes appropriate over-sampling ratios to achieve true-peak metering accuracy.

The question was raised concerning how the upcoming AES metadata standards might be handled in a way that would be consistent across a number of AES documents, and also capable of being harmonised with relevant external metadata sets such as the SMPTE metadata dictionary standards (RP210 metadata elements, RP2009 metadata groups etc.) and the IEC work in the same field.

This report discusses primary issues and outlines some elementary considerations.