I humbly apologize for acting too hastily with my previous note "New
Audio Stuff". In my exuberance at making progress, I mistook progress
Here is another proposal. It is not the one I favor, but I believe that
others will argue for it. Interested parties should read both and
contribute to the discussion. I apologize for the premature
announcement of consensus.
Replace section 7.7 with the text below:
7.7 The Audio Content-Type
A Content-type of "audio" indicates that the body or body part contains
audio data. Although there is not yet a consensus on an "ideal" audio
format for use with computers, there is a pressing need for a format
capable of providing interoperable behavior.
The initial subtype of "basic" is specified to meet this requirement.
The BNF for the audio type is as follows:
audio-content-type := "audio" "/" audio-subtype
*[ ";" attribute "=" value ]
audio-subtype := "basic" / x-token
7.1.1 The Audio/Basic subtype
No parameters are required when this subtype is present.
Audio data encoded in three parts: a header, containing fields that
describe the audio encoding format; a variable-length information field,
in which, for instance, ASCII annotation may be stored; and, the actual
encoded audio. The header and data fields are written using big-endian
The header part consists of six 32-bit quantities, in this order:
longword field description
-------- ----- -----------
0 magic number the value 0x2e736e64 (ASCII ".snd")
1 data offset the offset, in octets, to the data part.
The minimum valid number is 24 (decimal).
2 data size the size in octets, of the data part.
If unknown, the value 0xffffffff should
3 encoding the data encoding format:
1 8-bit ISDN u-law
23 8-bit ISDN u-law compressed
using the CCITT G.721 ADPCM
voice data encoding scheme.
4 sample rate the number of samples/second (e.g., 8000)
5 channels the number of interleaved channels (e.g., 1)
The information part, consists of 0 or more octets, and starts 24 octets
after the beginning of the header part. The length of the information
part is calculated by subtracting 24 (decimal) from the data offset
field in the header part.
Paragraph 6 of Appendix A defines the behavior required in order to
achieve conformance with the Audio/Basic subtype.
NOTE: This format is a subset of the one described in the NeXT
Publication "NeXTStep Programmers Guide", in the chapter on "Basic
Sound Concepts", and also in the SMI manual entry for audio_intro(3).
Add to Appendix A -- Minimal Conformance with This Memo
6. An implementation need not support the Audio content-type value in
order to be conformant to this memo. However, if conformance to the
Audio content-type value is claimed, then the implementation must be
able to recognize the Audio/Basic subtype, and to render audio encoded
using these field/values:
encoding 1 (8-bit ISDN u-law) or
23 (8-bit ISDN u-law compressed using CCITT G.721 ADPCM)
No conforming implementation will generate an Audio/Basic body
part that does not obey the above constraints.