RFC 2586

The Audio/L16 MIME content type

📅 published May 1999, from ietf

RFC 2586: The Audio/L16 MIME content type 🎀

okay bestie, so this is RFC 2586 from May 1999 💖 It was written by James Salsman and Harald Tveit Alvestrand (from UNINETT) 🫶 It's Informational, which means it's giving "here's some good info," not an Internet standard ✨ It doesn't list anything it obsoletes or updates, so it's a solo main character 💅

Status of This Memo 📜

This memo gives information to the Internet community. It doesn't specify an Internet standard of any kind 🌸 Distribution is unlimited, so share it with everyone 🦋

Copyright (C) The Internet Society (1999). All Rights Reserved 💜

1. Introduction 🌈

This doc defines audio/L16, a reasonable-quality audio format made for Internet apps 🎧 It's useful for stuff like email, web-served content, file uploads in web forms, and more. Iconic range 💖

2. The need for the Audio/L16 MIME type 😭

So the list of IETF standard MIME types for audio is honestly tiny 💀 It's just audio/basic and audio/32kadpcm, and both run at 8000 samples per second.

Rates below 11025 may obscure consonant information, even for single-voice speech 🙈 Common compressions like LPC are known to be microphone-dependent and lossy, so not it. Basically every IETF MIME audio type either defaults to 8000 samples per second or uses LPC, and that's the problem fr fr.

Advanced speech recognition and educational apps want to use internet transports that rely on MIME typing, like RFC 1867 file uploading 🎓 For that to work, higher standards are needed ✨

This type fills that gap by registering a super simple MIME type for higher-rate, linear-encoded audio with multiple channels 🔥 It's an IESG approved MIME type, which is why its definition is published as an RFC 👑

Also, RFC 1890 [1] describes lots of other Audio types that IANA may want to register formally. Of all of them, this one is the most urgently needed 🫶 This document may also work as a template for registering more of those audio types 🧚

3. The definition of Audio/L16 🎀

Audio/L16 is based on the well-known "L16" audio format from RFC 1890 section 4.4.8, which is for RTP transport 🦋 L16 means uncompressed audio data, using 16-bit signed, two's-complement representation in network byte order. (That's from section 4.4.8 of RFC 1890 💖)

You can parametrize it by changing the sample rate and the number of channels, and those parameters go in the MIME type header ✨

To keep things interoperable, only a few rate values are standardized here. Other values may NOT be used except by bilateral agreement 🙅‍♀️ This is the one place the all-caps NOT shows up, so pay attention bestie 💅

If you use multiple audio channels, they're numbered left to right, starting at one. Samples go into the data stream from each channel in turn, and info from lower-numbered channels comes before info from higher-numbered ones 🌸

For more than two channels, the convention from the AIFF-C audio interchange format should be followed [1]. It uses this notation:

   l    left
   r    right
   c    center
   S    surround
   F    front
   R    rear

   channels    description                 channel
                             1     2     3     4     5     6
   ___________________________________________________________
   2           stereo          l     r
   3                           l     r     c
   4           quadrophonic    Fl    Fr    Rl    Rr
   4                           l     c     r     S
   5                           Fl    Fr    Fc    Sl    Sr
   6                           l     lc    c     r     rc    S

(From RFC 1890 section 4.1 🌈)

4. IANA registration form for Audio/L16 📝

Here's the registration form, copied exactly so nothing gets lost 💜

   MIME media type name : Audio
   MIME subtype name : L16

   Required parameters
        rate: number of samples per second -- Permissible values for
        rate are 8000, 11025, 16000, 22050, 24000, 32000, 44100, and
        48000 samples per second.

   Optional parameters
        channels: how many audio streams are interleaved -- defaults
        to 1; stereo would be 2, etc.  Interleaving takes place
        between individual two-byte samples.

   Encoding considerations
        Audio data is binary data, and must be encoded for non-binary
        transport; the Base64 encoding is suitable for Email.  Note
        that audio data does not compress easily using lossless
        compression.

   Security considerations
        Audio data is believed to offer no security risks.

   Interoperability considerations
        This type is compatible with the encoding used in the WAV
        (Microsoft Windows RIFF) and Apple AIFF union types, and with
        the public domain "sox" and "rateconv" programs.

   Published specification
        RFC 2586

   Applications which use this media
        The public domain "sox" and "rateconv" programs accept this
        type.

        1. Magic number(s) : None
        2. File extension(s) : WAV L16
        3. Macintosh file type code : AIFF

   Person to contact for further information

        1. Name : James Salsman
        2. E-mail : jps-L16@bovik.org

   Intended usage
        Common
        It is expected that many audio and speech applications will use
        this type.  Already the most popular platforms provide this type
        with the rate=11025 parameter referred to as "radio quality
        speech."

   Author/Change controller
        James Salsman

5. Security considerations 🔐

The audio data is believed to offer no security risks 🫶

Heads up, though: RFC 1890 lets an application choose to play just one channel out of a multichannel transmission 👀 An attacker who knows two different users will pick different channels could maybe build some confusing messages. Honestly though, that's ridiculous 🙄

⚠️ This type is perfect for hiding data using steganography. Be careful out there, bestie 💀

6. References 📚

  • [1] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996. 🎧

7. Authors' Addresses 🏡

James Salsman
575 S. Rengstorff Avenue
Mountain View, CA  94040-1982 US

EMail: James@bovik.org


Harald Tveit Alvestrand
UNINETT
N-7034 TRONDHEIM
NORWAY

Phone: +47 73 59 70 94
EMail: Harald.T.Alvestrand@uninett.no

Copyright (C) The Internet Society (1999). All Rights Reserved 🌈

You can copy and share this document and translations of it, and you can make derivative works that comment on or explain it or help with implementing it. You can publish and distribute those in whole or in part with no real restrictions, as long as the copyright notice and this paragraph stay on every copy and derivative work 💖 But the document itself may not be modified in any way, like removing the copyright notice or references to the Internet Society or other Internet orgs. The exceptions are for developing Internet standards (where the Internet Standards process copyright procedures must be followed) or translating it into languages other than English 🦋

These permissions are perpetual and won't be revoked by the Internet Society or its successors or assigns ✨

This document and everything in it is provided "AS IS", and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 🫶

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society 💜

📦 where this page comes from