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

From: "Neuendorf, Max" <[email-masked]>
Date: Tue, 19 Sep 2017 13:33:18 +0000

Dear Sean,

thank you for your feedback.

That dot is of course not an issue. I'll fix it. Thanks for pointing (sic!) this out ;-)

Regarding the Magic Numbers, Syncwords:
In the way that you (i.e. RFC6838) describe the Magic Numbers, I would say that the Syncwords that I listed are probably not to be listed there.
One could say that it is in the very nature of Syncwords that they may occur anywhere within the received media stream (though thus indicating the start of a new frame). Ideally of course, the syncword is at the very beginning of the data. Decoders cannot rely on this, though.
I tried to capture this aspect by using "SHOULD" instead of "SHALL" in the following: 

"Receivers can distinguish the two [ADTS or LATMU/LOAS] 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."

In short, it is not possible to give a reliable byte offset at which the syncwords can be found. In consequence I would conclude that I remove the syncwords from the Magic Numbers section and merge them into the section Encoding Considerations.

In addition, it is of course always possible that the syncword occurs in the media stream by pure chance. So the detection of the presence of this magic number anywhere in the stream does not always _reliably_ identify the format type.

Best,
Max

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

-----Original Message-----
From: media-types [mailto:[email-masked]] On Behalf Of Sean Leonard
Sent: Monday, August 21, 2017 4:54 AM
To: [email-masked]
Subject: Re: [media-types] Proposal for registration of media type "audio/aac"

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

On 8/16/2017 1:34 AM, Neuendorf, Max wrote:
> 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")
>
>
>
>
>
>
>

_______________________________________________
media-types mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/media-types