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

From: "Neuendorf, Max" <[email-masked]>
Date: Tue, 19 Sep 2017 11:43:34 +0000

Dear Paul,

thanks for the feedback. Could you explain a bit further what exactly you propose to add? Is this about copy&paste of raw data, similar to a picture or a text snippet? Please be aware that these MIME type proposals are for AAC / USAC data only, something you rarely encounter, unless you're doing e.g. shoutCast. Usually the data is encapsulated in an mp4 file, for which the MIME type is well defined (e.g.: "audio/mp4; codecs=mp4a.40.42").

Best regards,
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,

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:
> 
> 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")
> 
> 
> 
> 
> 
> --
> 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 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,
> 
> 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
> 
> _______________________________________________
> media-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/media-types
> 
> _______________________________________________
> media-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/media-types

---

From: "Neuendorf, Max" <[email-masked]>
Date: Tue, 19 Sep 2017 11:50:58 +0000

Hi Paul,

I'll try to answer the last part of your mail:

"
> 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.

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
"

The other two (relevant) (container) formats are ADTS for (audio/aac) and LATM/LOAS (for audio/aac and audio/usac). Both are quite lean but have a syncword (see Magic Numbers) and should be fairly easy to spot.

Best,
Max

-----Original Message-----
From: Paul Libbrecht [mailto:[email-masked]] 
Sent: Friday, August 18, 2017 12:54 AM
To: Neuendorf, Max
Cc: [email-masked]; Schuyler Quackenbush
Subject: Re: [media-types] Proposal for registration of media type "audio/usac"

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 had a quick glance at Apple's URIs and it seems they need to be registered by Apple.

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 case for audio/aac and audio/usac.

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

---

From: "Neuendorf, Max" <[email-masked]>
Date: Mon, 25 Sep 2017 13:01:46 +0000

Dear Chris,

I finally had some time to have a look at this and discuss this in-house with some media transport experts.

After review of the linked W3C spec, we concluded that it is probably not applicable for audio/usac nor audio/aac.
At least we had no idea how to sensibly or practically make use of the described media fragment syntax in combination with the a packeted stream, such as LATM/LOAS.

Admittedly I had originally left this part of the application blank, because it said “(not required)” and also I was not sure what this was about. (And also there were no similar entries for audio/mpeg.)

Can you give some reference for the practical relevance of these media fragments, e.g. examples of where this is being used?
Otherwise, I would be inclined to keep this field of the application empty.

Thanks and Best,
Max

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

From: media-types [mailto:[email-masked]] On Behalf Of Chris Lilley
Sent: Wednesday, August 16, 2017 2:28 PM
To: [email-masked]
Subject: Re: [media-types] Proposal for registration of media type "audio/usac"

On 16-Aug-17 11:51, Neuendorf, Max wrote:

none

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: Chris Lilley <[email-masked]>
Date: Mon, 25 Sep 2017 15:05:28 -0400

Hi Max,

Thanks for looking into this.

On 25-Sep-17 09:01, Neuendorf, Max wrote:
>
> Dear Chris,
>
> I finally had some time to have a look at this and discuss this 
> in-house with some media transport experts.
>
> After review of the linked W3C spec, we concluded that it is probably 
> not applicable for audio/usac nor audio/aac.
>
> At least we had no idea how to sensibly or practically make use of the 
> described media fragment syntax in combination with the a packeted 
> stream, such as LATM/LOAS.
>
Because it is not practicable to seek on a stream?
>
> Admittedly I had originally left this part of the application blank, 
> because it said “(not required)” and also I was not sure what this was 
> about. (And also there were no similar entries for audio/mpeg.)
>
It is a relatively recent specification, and also a lot of media type 
registrations tend to not think about fragment identifiers until long 
after registration, if at all.
>
> Can you give some reference for the practical relevance of these media 
> fragments, e.g. examples of where this is being used?
>
An implementation report is available, with the implementations that 
were tested before Media Fragments became a W3C Recommendation:

https://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-impl/

There is also a use cases and requirements document:
https://www.w3.org/TR/media-frags-reqs/

I'm happy that you examined fragment identifiers for this media type; if 
having done so you have concluded that they are not applicable here then 
I am satisfied.

> Thanks and Best,
>
> Max
>
> ------------------------------------------------------------------------
>
> *Max**Neuendorf*
> Audio
> Am Wolfsmantel 33 | D-91058Erlangen
> <mailto:[email-masked]>| +49 9131 776-6020
>
> *From:*media-types [mailto:[email-masked]] *On Behalf Of 
> *Chris Lilley
> *Sent:* Wednesday, August 16, 2017 2:28 PM
> *To:* [email-masked]
> *Subject:* Re: [media-types] Proposal for registration of media type 
> "audio/usac"
>
> 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).
>
-- 
Chris Lilley
@svgeesus
Technical Director @ W3C
W3C Strategy Team, Core Web Design
W3C Architecture & Technology Team, Core Web & Media