Re: How to use this AudioFile info thing?
Re: How to use this AudioFile info thing?
- Subject: Re: How to use this AudioFile info thing?
- From: Richard Dobson <email@hidden>
- Date: Thu, 05 May 2005 23:19:31 +0100
Brian Willoughby wrote:
..
This is not precisely true.
WAVE does not include the duration in the format "header" chunk - you must
compute the duration from the length of the sound data chunk, divided by the
average bytes per second (or a combination of channels, rate, and sample size).
Of course, I am well aware of both WAVE and AIFF formats, having written my own
file parsers for these for many a year now. Lets not quibble - the calculations
you describe are no more than those any PCM format involves. It would have been
nice had the rendering chunk info contained a data size in frames rather than
bytes, but there you are. In fact, computing datasize/blockalign is sufficient
(assuming the latter is defined correctly!) to extract the duration. And when
you want to play an AIFF file on Windows, you have to convert the COMM chunk
information into the WAVE "fmt " chunk, to send to the audio device.
AIFF does include the frame count in the common "header" chunk, but some
programs create AIFF with conflicting values compared to the sound data chunk
length. Obviously, those files are not valid, but the Finder seems to get the
duration correct.
There has been a possibly apochryphal assumption round and about for many years
that AIFF is so difficult to write that most AIFF files are incorrect in some
way or another. Most applications are indeed quite good at concealing this from
users; if the file can be opened and read, somehow, why worry the user
unnecessarily! I still recall a version of Quicktime on the old MacOS (RIP) that
couldn't render a 32bit floating-point AIFF-C file (as defined by Apple)
correctly unless the word size was stated as 16bits!
Neither of the above require "reading" the entire file, but they do require
"parsing" the entire file.
For a WAVE file, you don't nend to parse begond the size field of the data chunk
if all you need is the basic file properties. While an optional chunk can be
interposed between the parent WAVE chunk and the fmt chunk (one aspect that
older parsers often fail to deal with), that cannot be the data chunk.
As chunk-based formats, both RIFF/WAVE and
FORM/AIFF make (almost) no guarantees about the order of chunks.
This is only true for AIFF (and the main problem with it); WAVE mandates that
the fmt chunk MUST precede the data chunk. Thus all WAVE files are guaranteed
streamable.
Therefore, it
is often true that every chunk must be read. I'm not sure if this is what is
meant by "parsing the entire file" but I couldn't help being pedantic and
pointing out that there is no "header" per se in either format, at least not in
the sense of traditional file headers (which occur only at the head of the
file, as the term implies).
Again, WAVE and AIFF are very different here. AIFF can indeed have chunks in any
arbitrary order, while WAVE insists that the all important rendering
information, inclusing data length, preceded the data chunk itself. In your
terms, WAVE does have a "header" (erroneosuly described in some non-definitve
documents as a fixed-size header), while AIFF does not. I have always regarded
AIFF as a pathological format for this reason; despite the fact that the
~majority~ of AIFF files one reads do in fact present the chunks in a "sane"
order. But the format does not require this, which is the problem. If, as
suggested, CAF does mandate that rendering information precede the data, that is
a very important and long overdue improvement.
Richard Dobson
Brian Willoughby
Sound Consulting
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden