/* Copyright (c) 1992 by Sun Microsystems, Inc. */
#ifndef _MULTIMEDIA_AUDIO_FILEHDR_H #define _MULTIMEDIA_AUDIO_FILEHDR_H
#ident "@(#)audio_filehdr.h 1.10 92/11/10 SMI"
#include "archdep.h"
/*
* Define an on-disk audio file header.
* This structure should not be arbitrarily imposed over a stream of bytes, since the byte orders could be wrong.
* Note that there is an 'info' field that immediately follows this structure in the file.
* The hdr_size field is problematic in the general case because the field is really "data location", which does not ensure that all the bytes between the header and the data are really 'info'. Further, there are no absolute guarantees that the 'info' is ASCII text, (non-ASCII info may eventually be far more useful anyway).
* When audio files are passed through pipes, the 'data_size' field may not be known in advance. In such cases, the 'data_size' should be set to AUDIO_UNKNOWN_SIZE.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* Define the magic number */
|
|
|
/* Define the encoding fields */
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#endif /* !_MULTIMEDIA_AUDIO_FILEHDR_H */
NAME
audiofile - file format for audio data
SYNOPSIS
#include <multimedia/libaudio.h>
DESCRIPTION
An audio file is composed of three parts: a 24-byte header, a variable-length annotation block, and a contiguous segment of audio data. Audio header and data fields are stored in network (big-endian) byte order, regardless of the native byte-order of the machine architecture on which an application may be running. Therefore, multi-byte audio data may require byte reversal in order to operate on it by the arithmetic unit of certain processors. The header is defined by the following structure:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The magic field always contains the following constant :
AUDIO_FILE_MAGIC ((u_32)0x2e736e64) /* """.snd""" */
The hdr_size field contains the length of the fixed header plus the variable-length annotation field. Consequently, it may be interpreted as an offset from the start of the file to the beginning of the audio data. The data_size field contains the length, in bytes of the audio data segment. If this length is not known when the header is written, it should be set to AUDIO_UNKNOWN_SIZE, defined as follows:
|
|
|
When the data_size field contains AUDIO_UNKNOWN_SIZE, the length of the audio data may be determined by subtracting hdr_size from the total length of the file.
The encoding field contains one of the following enumerated keys:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
All of the linear formats are signed integers, centered at zero. Another common linear format, 8-bit unsigned linear PCM, is not currently supported. The floating-point formats are signed, zero-centered, and normalized to the unit value ( -1.0 <= x <= 1.0 ).
The sample_rate field contains the audio sampling rate, in samples per second. Common sample rates include 8000, 11025, 16000, 22050, 32000, 44100, and 48000 samples per second.
The channels field contains the number of interleaved data channels. For monaural data, this value is set to one. For stereo data, this value is set to two. More than two data channels may be interleaved, but such formats may not be supported by all audio applications.
Following the header structure is a variable-length annotation field. The contents of this field are currently undefined, except that its length must be a non-zero multiple of eight bytes and it must be terminated with at least one null (zero) byte.
The audio data segment begins on an eight-byte boundary immediately following the annotation field. Audio data is encoded in the format identified by the file header. The current implementation supports only a single audio data segment per file.
NOTES
Applications are encouraged NOT to decode the fields of the audio file header directly.
Instead, applications should use the routines described in /usr/demo/SOUND/man/man3/audio_filehdr.3 to read, write, and decode audio file headers.
The variable-length annotation field is currently ignored by most audio applications. It is present for interchange compatibility. In the future, applications may use this field to store structured data annotation, such as markers and edit points.