ietf-822
[Top] [All Lists]

Audio redux

1991-11-01 14:14:33
I humbly apologize for acting too hastily with my previous note "New
Audio Stuff".  In my exuberance at making progress, I mistook progress
for consensus.

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.


--------------------cut here--------------------
                            EDITING INSTRUCTIONS


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

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
                                be used.

    3           encoding        the data encoding format:

                                    value       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:

    field       values
    -----       ------
    encoding     1 (8-bit ISDN u-law) or
                23 (8-bit ISDN u-law compressed using CCITT G.721 ADPCM)

    sample      8000

    channels    1

No conforming implementation will generate an Audio/Basic body
part that does not obey the above constraints.
///////



<Prev in Thread] Current Thread [Next in Thread>
  • Audio redux, Nathaniel Borenstein <=