Subject: [media-types] Proposal for registration of media type "audio/aac"

From: "Neuendorf, Max" <[email-masked]>
Date: Mon, 14 Aug 2017 15:34:47 +0000

Dear experts,

As a representative of the Audio Subgroup of ISO/IEC JTC1/SC29/WG11, a.k.a. MPEG, I would like to propose the registration of the mime type, or media type:

 "audio/aac"

MPEG has produced a resolution which describes the necessary fields for registration. This resolution can be found here for public download:

http://mpeg.chiariglione.org/standards/mpeg-4/audio/mime-type-registration-isoiec-14496-3-mpeg-4-aache-aache-aac-v2

Please follow the download link for w17017.zip

With this e-mail I would kindly like to invite experts to review and comment on the proposal as recommended in RFC6838, 5.2.

We intend to register this mime type in the Standards Tree for types "registered by a recognized standards-related organization".

A similar review request will follow for registration of "audio/usac".

Any feedback is welcome.

Kind regards,
Max Neuendorf

-- 
Max Neuendorf
Audio
Fraunhofer-Institut für Integrierte Schaltungen IIS
Am Wolfsmantel 33 | D-91058 Erlangen
[email-masked] | +49 9131 776-6020

---

From: Sean Leonard <[email-masked]>
Date: Tue, 15 Aug 2017 05:24:27 -0700

What does AAC stand for, if anything?

This is the same thing as .aac files, right (what people commonly but 
erroneously refer to as "Apple Audio Codec")?

What is the relationship between this and .m4* (m4a, m4b, m4v), etc.?

For the benefit of reviewers, we ask that you post the text of the 
proposed registration in the body of your e-mail message to this list.

Regards,

Sean

---

From: Thomas Edwards <[email-masked]>
Date: Tue, 15 Aug 2017 17:38:11 +0000

Advanced Audio Coding (AAC) is an audio codec developed by Dolby.

AAC has been standardized as ISO/IEC 13818-7:2006 “Information technology -- Generic coding of moving pictures and associated audio information -- Part 7: Advanced Audio Coding (AAC)”

-Thomas

-- 
Thomas Edwards
FOX Networks Engineering & Operations
VP Engineering & Development
[email-masked]
+1-310-369-6696
10201 W Pico Blvd
Los Angeles, CA 90035

On 8/15/17, 5:24 AM, "media-types on behalf of Sean Leonard" <[email-masked] on behalf of [email-masked]> wrote:

    

    Regards,
    
    Sean
    
    On 8/14/2017 8:34 AM, Neuendorf, Max wrote:
    > https://urldefense.proofpoint.com/v2/url?u=http-3A__mpeg.chiariglione.org_standards_mpeg-2D4_audio_mime-2Dtype-2Dregistration-2Disoiec-2D14496-2D3-2Dmpeg-2D4-2Daache-2Daache-2Daac-2Dv2&d=DwICAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=sbT6A0SvtHOP29zP8RtcS-C_R3_cbzjY0i2f_0VdxHM&s=W0URv_K7PPf8K93u5n8iwU0E6ND8F4MmWzYrw53VCzE&e= 
    >
    
    _______________________________________________
    media-types mailing list
    [email-masked]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_media-2Dtypes&d=DwICAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=sbT6A0SvtHOP29zP8RtcS-C_R3_cbzjY0i2f_0VdxHM&s=k6_ezvViVCmxIwZP9B4sJ651iWfjk38dGVK70PIlKsc&e=

---

From: "Neuendorf, Max" <[email-masked]>
Date: Wed, 16 Aug 2017 08:34:14 +0000

Hi Sean,

thanks for the quick response.

AAC is short for "Advanced Audio Coding".
I realize that this is not explicitly spelled out in the registration. Needs to be fixed.
AAC is a joint development of a larger group of companies, most notably Fraunhofer IIS, Dolby, and Philips.

There are various "flavors" of AAC. 
This media type targets MPEG-4 AAC (ISO/IEC 14496-3).
It is a successor of MPEG-2 AAC (ISO/IEC 13818-7) which Thomas Edwards correctly pointed to.

On the various file extension: I am guessing they all indicate mp4 files (media in MP4-Fileformat) with various content.
e.g. m4v: MPEG-4 video (possibly with audio), m4a: MPEG-4 audio only, m4b: Audio Books (possibly DRM protected).

The present registration is for audio which is NOT in MP4-Fileformat, but in LATM/LOAS or ADTS format instead.
Audio (also AAC) in MP4-Fileformat is signaled through audio/mp4 with an appropriate parameter (e.g. mp4a.40.2).

Here comes the proposed text for the registration:

2.1	Full Name
Max Neuendorf

2.2	E-Mail
[email-masked]

2.3	Type Name
"audio"

2.4	Subtype Name
Standards Tree (no prefix)
"aac"

2.5	Required Parameters
none

2.6	Optional Parameters
none

2.7	Encoding Considerations
Binary

Files are encoded binary AAC audio packed in one of the following MPEG-4 audio formats
•	Low Overhead Audio Transport Multiplex / Low Overhead Audio Stream (LATM/LOAS) as defined in ISO/IEC 14496-3
•	Audio Data Transport Stream (ADTS) as defined in ISO/IEC 14496-3
Receivers can distinguish the two by inspecting the binary data stream and searching for the syncwords as listed in subclause "Magic number(s)". 
The syncword SHOULD be the first bits that are received from a server when requesting data identified with this mime type.
Encoded audio files packed in LATM/LOAS format SHOULD have the file extension ".loas".
Encoded audio files packed in ADTS format SHOULD have the file extension ".aac".
Files SHALL be transmitted without CR/LF conversion, 7-bit stripping, or any other modification to the binary data.
Files MAY contain ID3v2.x frames at any frame boundary.
For use over the Internet, it is assumed that lower layers take care of transmission errors, so audio/aac data MAY include frames without the optional cyclic redundancy check (CRC).
The AAC audio data is binary data, and must be specifically encoded for non-binary transport; the Base64 encoding is suitable when attaching to Email. Note that the MPEG audio data typically does not yield further compression when using file-based lossless compression, e.g. zip.

2.8	Security Considerations
AAC is a tagged data format, and some tags are available for private use (e.g. the Data Stream Element).  As such, arbitrary material could potentially be transferred in the AAC stream, including executable content. Tagged data containing executable content SHOULD never be sent and MUST not be executed if it is received.
Note: The requirement that such content must not be executed on receipt is especially important since situations exist where content will be generated independently and therefore could contain executable content that the sender or receiver is unaware of.
It is the responsibility of the decoder/player client to respect and apply appropriate file security and protection against any potential malicious content.
audio/aac objects are not signed or encrypted internally. External security mechanisms must be employed to ensure content confidentiality and integrity.

2.9	Interoperability Considerations
The AAC family of codec technologies is specified in ISO/IEC 13818-7 as AAC LC Profile, in ISO/IEC 14496-3 as AAC, HE-AAC and HE-AAC v2 Profiles. Implementations of the AAC family of technologies have reference software for reading and writing the file format and are available for a variety of computer platforms.
2.10	Published specification
ISO/IEC 14496-3
ISO/IEC 13818-7

2.11	Application Usage
AAC audio is device, platform, and vendor neutral and is supported by a wide range of encoders and decoders/players, for example for Multimedia, HLS Audio-Only Streams - IETF HTTP Live Streaming, SHOUTcast/Icecast2 Audio Streams.

2.12	(not required) Fragment Identifier Considerations
none

2.13	(not required) Restrictions on Usage
none

2.14	(not required) Provisional Registrations
none

2.15	Additional Information

2.15.1	Deprecated alias names for this type
none

2.15.2	Magic number(s)
Syncword for LOAS AudioSyncStream() 0x2B7 (11bit sequence)
Syncword for LOAS EPAudioSyncStream() 0x4DE1 (16bit sequence)
Syncword for ADTS adts_sequence() 0xFFF (12bit sequence)

2.15.3	File extension(s)
.adts or .aac (if payload is packed in ADTS format)
.loas or .ass (if payload is packed in LATM/LOAS format)

2.15.4	Macintosh File Type Code(s)
none

2.15.5	Object Identifier(s) or OID(s) — See RFC 1494
none

2.16	Intended Usage
Common

2.17	(not required) Other Information & Comments
none

2.18	Contact Person
Provide the contact for further information. See RFC 6838 §5.5.

2.18.1	Contact Name
Max Neuendorf

2.18.2	Contact Email Address
[email-masked]

2.18.3	Author/Change Controller (for standards tree registrations, this is typically the standards body)
ISO/IEC JTC1/SC29/WG11 (a. k. a. "MPEG")

-----Original Message-----
From: Sean Leonard [mailto:[email-masked]] 
Sent: Tuesday, August 15, 2017 2:24 PM
To: Neuendorf, Max; [email-masked]
Cc: Schuyler Quackenbush
Subject: Re: [media-types] Proposal for registration of media type "audio/aac"

Regards,

Sean

---

From: "Neuendorf, Max" <[email-masked]>
Date: Wed, 16 Aug 2017 08:45:54 +0000

Hi Thomas

Being a representative of Fraunhofer IIS, I ,of course, need to add to that ;-)

AAC was not solely developed by one company, but in a joint development within the MPEG Audio Subgroup. The list of companies includes:
Dolby, Fraunhofer, Philips, Microsoft, NEC, NTT Docomo, Orange, Panasonic, Ericsson.
Source for this list: http://www.via-corp.com/us/en/licensing/aac/licensors.html

ISO/IEC 13818-7:2006 “Information technology -- Generic coding of moving pictures and associated audio information -- Part 7: Advanced Audio Coding (AAC)”
is what is called "MPEG-2 AAC".

A further improved version of AAC was standardized in MPEG-4 as: 
ISO/IEC 14496-3:2009 "Information technology — Coding of audio-visual objects — Part 3: Audio"
That standard also defines the various AAC flavors, such as High Efficiency AAC (HE-AAC), HE-AACv2, AAC-LD, AAC-ELD, etc.

Best,
Max

-----Original Message-----
From: Thomas Edwards [mailto:[email-masked]] 
Sent: Tuesday, August 15, 2017 7:38 PM
To: Sean Leonard; Neuendorf, Max; [email-masked]
Cc: Schuyler Quackenbush
Subject: Re: [media-types] Proposal for registration of media type "audio/aac"

-Thomas

    

    
    Regards,
    
    Sean

---

From: Sean Leonard <[email-masked]>
Date: Sun, 20 Aug 2017 19:54:26 -0700

Upon review of this, the only showstopper is that the character • is 
present in the registration, which I believe is not allowed. Only 
printable ASCII characters are allowed in registrations at this time. 
(It's a pedantic concern, but that's the way it is. RFC 6838/the 
registration procedure should probably be updated at some point.)

As a suggestion/concern, I think that the magic number(s) field should 
specify the position of those bytes in the byte stream, without 
reference to structures in the format itself. RFC 6838 says: "Magic 
numbers are byte sequences that are always present at a given place in 
the file and thus can be used to identify entities as being of a given 
media type." Basically the idea is: if you have a random blob of bytes 
and a media type service (e.g., HTTP, e-mail client) tries to serve it, 
can the service sniff the content without knowing much of anything about 
what it is, and serve it as this media type? So, this field should say 
where 0x2B7 occurs as an exact offset from the beginning of the content, 
or a way to use the first few bytes of the content to figure out the 
variable offset.

Regards,

Sean