The Audio/L16 MIME content type
RFC 2586
| Document | Type |
RFC - Informational
(May 1999; No errata)
Was draft-alvestrand-audio-l16 (individual)
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | Legacy | ||
| Formats | plain text pdf html bibtex | ||
| Stream | Legacy state | (None) | |
| Consensus Boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | RFC 2586 (Informational) | |
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
Network Working Group J. Salsman
Request for Comments: 2586 H. Alvestrand
Category: Informational UNINETT
May 1999
The Audio/L16 MIME content type
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
1. Introduction
This document defines the audio/L16 MIME type, a reasonable quality
audio format for use in Internet applications.
Possible application areas include E-mail, Web served content, file
upload in Web forms, and more.
2. The need for the Audio/L16 MIME type
The set of IETF standard MIME types for audio is small; it consists
of only the audio/basic and audio/32kadpcm types, which have a
sampling rate of 8000 samples/second.
Rates below 11025 may obscure consonant information, even for
single-voice speech. Common compressions, such as LPC, are known to
be microphone-dependant and lossy. Thus far all IETF MIME Audio
types either default to 8000 samples per second or use LPC.
In order for advanced speech recognition and related educational
applications to make use of internet transports (such as RFC 1867
file uploading) which use MIME typing, higher standards are required.
This type repairs that lack by registering a very simple MIME type
that allows higher rate, linear-encoded audio with multiple channels.
This is an IESG approved MIME type, and its definition is therefore
published as an RFC.
Salsman Informational [Page 1]
RFC 2586 The Audio/L16 MIME content type May 1999
Please note that there are many other Audio types described in RFC
1890 [1] which IANA may wish to formally register; this one, of all
of them, seems to be most immediately needed. This document may also
serve as a template for further registrations of these audio types.
3. The definition of Audio/L16
Audio/L16 is based on the well know audio format "L16" described in
RFC 1890 section 4.4.8 for use with RTP transport. L16 denotes
uncompressed audio data, using 16-bit signed representation in twos-
complement notation and network byte order. (From section 4.4.8 of
RFC 1890)
It may be parametrized by varying the sample rate and the number of
channels; the parameters are given on the MIME type header.
In order to promote interoperability, only a few rate values are
standardized here. Other values may NOT be used except by bilateral
agreement.
If multiple audio channels are used, channels are numbered left-to-
right, starting at one. Samples are put into the data stream from
each channel in succession; information from lower-numbered channels
precedes that from higher-numbered channels.
For more than two channels, the convention followed by the AIFF-C
audio interchange format should be followed [1], using the following
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)
Salsman Informational [Page 2]
RFC 2586 The Audio/L16 MIME content type May 1999
4. IANA registration form for Audio/L16
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
Show full document text