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

From: "Neuendorf, Max" <[email-masked]>
Date: Mon, 14 Aug 2017 15:38:05 +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/usac"

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-d/unified-speech-and-audio-coding/mime-type-registration-isoiec-23003-3-mpeg-d-usac

Please follow the download link for w17022.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".

Note that there is a related review request for registration of "audio/aac".

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: "Neuendorf, Max" <[email-masked]>
Date: Wed, 16 Aug 2017 08:51:14 +0000

I re-post with the actually proposed registration text.
USAC stands for "Unified Speech and Audio Coding", also referred to as Extended High Efficiency Advanced Audio Coding (xHE-AAC).

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)
"usac"

2.5	Required Parameters
none

2.6	Optional Parameters
none

2.7	Encoding Considerations
Binary

Files are encoded binary USAC audio packed in the MPEG-4 audio format Low Overhead Audio Transport Multiplex / Low Overhead Audio Stream (LATM/LOAS) as defined in ISO/IEC 14496-3. 
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 LATM/LOAS frame boundary.
For use over the Internet, it is assumed that lower layers take care of transmission errors, so audio/usac data MAY include USAC frames generated without the optional cyclic redundancy check (CRC) data. Bit rate not allocated to CRC data can be allocated to audio data, thus yielding improved audio quality.
The USAC 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
USAC is a tagged data format, and some tags are available for private use.  As such, arbitrary material could potentially be transferred in the USAC 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/usac 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, and in ISO/IEC 23003-3 as xHE-AAC Profile. 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 23003-3
ISO/IEC 14496-3
ISO/IEC 13818-7

2.11	Application Usage
USAC 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)

2.15.3	File extension(s)
.loas (preferred)
.xhe

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 ("MPEG")

-----Original Message-----
From: media-types [mailto:[email-masked]] On Behalf Of Neuendorf, Max
Sent: Monday, August 14, 2017 5:38 PM
To: [email-masked]
Cc: Schuyler Quackenbush
Subject: [media-types] Proposal for registration of media type "audio/usac"

Dear experts,

 "audio/usac"

Any feedback is welcome.

Kind regards,
Max Neuendorf

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

---

From: Chris Lilley <[email-masked]>
Date: Wed, 16 Aug 2017 15:27:45 +0300

> 2.12	(not required) Fragment Identifier Considerations

I would have thought that Media Fragments would be applicable here; for 
example, linking to a particular point in an audio file (rather than 
just the beginning).

https://www.w3.org/TR/media-frags/

--
Chris

---

From: Paul Libbrecht <[email-masked]>
Date: Wed, 16 Aug 2017 17:12:46 +0200

Dear Max,

could I suggest that you add a Windows Clipboard Flavour name and a Macintosh Uniform Type Identifier for this registration and the audio/aac registration?
Sound files are pretty common and sound fragments can be commonly exchanged over the clipboards.

This would ensure a greater interoperability.
As example registration with this information, SVG and MathML can be taken.
These slots have not made its way to the registration templates yet; indeed they only make sense for some types of information. Audio and video information is among them.

thanks in advance.

Paul

> On 16 Aug 2017, at 10:51, Neuendorf, Max <[email-masked]> wrote:
>

---

From: "Neuendorf, Max" <[email-masked]>
Date: Thu, 17 Aug 2017 11:50:13 +0000

Dear Paul,

thank you for your suggestions. I will have to look into that. It's not my home turf.

I had a quick glance at Apple's URIs and it seems they need to be registered by Apple.
Maybe both, audio/aac and audio/usac, will fall under public.mpeg-4-audio. Not sure, though, because those might assume that the audio comes in an MP4 File Container. That is specifically not the case for audio/aac and audio/usac.

Best,
Max

-----Original Message-----
From: Paul Libbrecht [mailto:[email-masked]] 
Sent: Wednesday, August 16, 2017 5:13 PM
To: Neuendorf, Max
Cc: [email-masked]; Schuyler Quackenbush
Subject: Re: [media-types] Proposal for registration of media type "audio/usac"

Dear Max,

thanks in advance.

Paul

---

From: Paul Libbrecht <[email-masked]>
Date: Fri, 18 Aug 2017 00:53:43 +0200

Hello Max,

> On 17 Aug 2017, at 13:50, Neuendorf, Max <[email-masked]> wrote:
> 
> Thank you for your suggestions. I will have to look into that. It's not my home turf.
> 

I don’t think so.
This document:
	https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/understanding_utis/understand_utis_declare/understand_utis_declare.html#//apple_ref/doc/uid/TP40001319-CH204-SW1
says:
	"Mac apps can add new uniform type identifiers for proprietary data formats. You declare new UTIs in the  information property list (info.plist) file of a bundle. You can declare new UTIs in any of the following:”

And it says quite later (System Declared UTIs):
	Note: These tables list only UTIs declared by the system. Other UTIs may be declared privately by Apple applications (Mail, for example) and third-party developers.

Registration of 4-letter-codes, the ancestor of UTIs which is still in media-type-registrations, was indeed necessary.

> Maybe both, audio/aac and audio/usac, will fall under public.mpeg-4-audio. Not sure, though, because those might assume that the audio comes in an MP4 File Container. That is specifically not the c…

That seems tricky then. Maybe specify more than one clipboard flavour??

So. If it is not the case, that mp4-containers are always used… Are all other container formats recognisable by people who would apply these media-types?

thanks in advance.

Paul