Blair Whitney (whitney@connectedsystems.com)
Thu, 12 Aug 1999 19:41:07 -0700
The "fmt" chunk layed out by Doug Murray below is correct, and matches the
original spec and reference document:
"Multimedia Programming Interface and Data Specifications 1.0, Resource
Interchange File Format, Waveform Audio File Format (WAVE), IBM Corporation
and Microsoft Corporation, August 1991"
(rather than Microsoft's platform SDK or MSDN usage for formal spec
reference)
Note:
The value of the field:
16 4 bytes 18 Length of the chunk excluding the 8
bytes for the ID and length.
can vary, due to extension data, e.g. it can be 20 if you need to set :
36 2 bytes cbSize
to the value 2,
and then follow it by the 2 byte value which is the samples per block.
Blair Whitney
-----Original Message-----
From: Murray, Doug [mailto:DMurray@avtc.com]
Sent: Thursday, August 12, 1999 6:35 PM
To: 'Glenn Parsons'; 'Keith Moore'
Cc: vpim@lists.neystadt.org; VPIM discussion list
Subject: RE: [VPIM] Re: draft-ema-vpim-wav-00.txt
I agree with Glenn that we need to use an already supported format.
In looking at http://www.ema.org/vpimdir/specs/draft-ema-vpim-wav-00.txt I
see some problems with the wav file format description. The document shows
the following for the "fmt" chunk:
OFFSET LENGTH VALUE DESCRIPTION
12 4 bytes 'fmt ' The chunk ID.
16 4 bytes 32 Length of the chunk excluding the 8
bytes for the ID and length.
20 4 bytes The codec ID.
24 4 bytes The number of channels.
28 8 bytes Samples per second.
36 8 bytes Average bytes per second.
44 4 bytes Block alignment.
48 4 bytes Bits per sample.
The "fmt" chunk actually is laid out as follows (as defined in the MSDN
Library):
OFFSET LENGTH VALUE DESCRIPTION
12 4 bytes 'fmt ' The chunk ID.
16 4 bytes 18 Length of the chunk excluding the 8
bytes for the ID and length.
20 2 bytes The codec ID.
22 2 bytes The number of channels.
24 4 bytes Samples per second.
28 4 bytes Average bytes per second.
32 2 bytes Block alignment.
34 2 bytes Bits per sample.
36 2 bytes cbSize - Size, in bytes, of extra
format information appended to the
end of the WAVEFORMATEX structure.
This information can be used by non-PCM
formats to store extra attributes for
the wFormatTag. If no extra information
is required by the wFormatTag, this
member must be set to zero. Note that
for WAVE_FORMAT_PCM formats (and only
WAVE_FORMAT_PCM formats), this member
is ignored.
A couple of other issues:
1. Is A-law to be supported as well as mu-law?
2. Many applications that create wav files already put data in the fact
chunk unrelated to the total number of samples in the file. I can't see how
the fact chunk will be modified (possibly losing information) to hold the
total number of samples. In reality the total number of samples is easily
calculated by the formula:
Samples = (Data chunk size / (Avg bytes per sec * (Bits per sample /
8 bits per byte))
-----Original Message-----
From: Glenn Parsons [mailto:gparsons@nortelnetworks.com]
Sent: Thursday, August 12, 1999 1:06 PM
To: 'Keith Moore'
Cc: vpim@lists.neystadt.org; Philipp Hoschka; VPIM discussion list;
Graham Klyne; 'Keith Moore'
Subject: RE: [VPIM] Re: draft-ema-vpim-wav-00.txt
> just curious...for whom are you speaking when you say "we"?
>
This is part of the goals document that was agreed by all the traditional
VPIM folks before it was presented at the first VPIM BOF. The last VPIM BOF
concurred with this rational for using audio/wav.
Glenn.
Copyright (c) 1999. Electronic Messaging Association, Inc. All rights
reserved. A member service of EMA-The Electronic Business Forum 1655
North Fort Myer Drive, Suite 500, Arlington, Virginia 22209-3108 el.
703-524-5550 Fax 703-524-5558 E-Mail: support@ema.org
This archive was generated by hypermail 2.0b3 on Tue Mar 19 2002 - 01:04:38 IDT