Re: Inconsistencies with large WAV file
Re: Inconsistencies with large WAV file
- Subject: Re: Inconsistencies with large WAV file
- From: Doug Wyatt <email@hidden>
- Date: Fri, 04 Dec 2009 08:36:11 -0800
I tested AIFF and it doesn't have this problem.
Doug
On Dec 4, 2009, at 3:21, Richard Dobson
<email@hidden> wrote:
Brian Willoughby wrote:
If this turns out to be a bug in the AudioFile source, then you
should probably look for something similar with AIFF, in addition
to WAV. When I first started working with AIFF (long before
AudioFile), I made the assumption that the chuckSize should be
UInt32, since there's no meaningful need for negative sizes.
Apparently, however, the AIFF specification states that the
chunkSize is only 31 bits, and is technically undefined for 32
significant bits.
AIFF/AIFF-C has always been a bit of a mess. In the spec, the chunk
size is defined as a signed 32bit field; which does indeed mean that
in principle an AIFF file as a whole cannot exceed 2MB. However, the
specs (Apple draft, 1991) also propose that the best source of
information on the size of the audio data is not the chunksize but
the numSampleFrames field in the COMM chunk - and that is an
unsigned 32bit long. BUT: the chunk size in the SSND chunk is of
course a signed value - go figure. Way back then, the chances of
anyone wanting to make a file that long must have seemed vanishingly
low. I have to confess in CDP we simply treat all sizes as
unsigned, Just In Case. Looks like AudioFile needs to do the same.
Of course, ~now~, everyone should be using CAF instead anyway.
The great irony here is that in the (IMO) ill-conceived RF64 64bit-
extended WAVE proposal adopted unquestioningly by the AES and EBU
(and meant to be backwards-compatible with WAVE; which it isn't),
they depend on setting a size of 0xFFFFFFFF in the main chunk size
in order to indicate that the new larger 64bit "ds64" chunk should
be used to obtain the size.
Richard Dobson
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
@apple.com
This email sent to email@hidden
_______________________________________________
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