Re: [OT]Non-padded odd-length chunks in AIFFs
Re: [OT]Non-padded odd-length chunks in AIFFs
- Subject: Re: [OT]Non-padded odd-length chunks in AIFFs
- From: Brian Willoughby <email@hidden>
- Date: Thu, 2 Dec 2004 16:29:25 -0800
I am sorry for following up to my own answer by repeating the same thing
again. For those of you who are interested in this topic, I suggest obtaining
the official specification for AIFF and AIFF-C from Apple - it can be found
online.
Ev, I'm sorry, but while you may have seen different spec descriptions, none
of the conflicting ones are official. Just because it is in print does not
make it true. You're not the only one to be misled. Apple noticed enough of
an issue that the AIFF-C specification has a section paragraph titled "Remember
the Pad Byte!" I reiterate: it is not optional.
Note, when third-parties add their own chunk types to AIFF, they do not have
the option of changing the basic specification. Some block descriptions may
not say that they can have a pad, but they do not need to, since the core
specification defines that this must be true at the basic chunk level. This
was originally intended to make all file chunks aligned on a 16-bit boundary
for efficient 68000 memory access. Whether or not this still holds an
advantage today is moot, because the spec has already been set and must be
followed.
If you prefer to make your AIFF reader routines handle missing pad bytes, then
that is up to you (although I don't see how you can do this an still be able
to read correctly formatted AIFF). However, you absolutely must *not* write
anything with unaligned chunks and call it "AIFF" - no matter how much easier
it makes it for you to walk the chunks. A properly designed AIFF library will
be able to handle all chunks identically, including the ability to skip unknown
chunks, and should be able to report the chunk length as either its data size
(as marked) or as its file size (always even). The data size and file size
only differ when the data size is odd, the file size must always be even. Your
routines which handle specific chunk data need only be made aware of the
reported chunk data size, while only the higher-level chunk code needs to know
the padded length as it appears in the file. AIFF writing routines can
abstract this the same way as reading (parsing) routines.
Whenever you find real-world AIFF examples that are not to spec, report the
issue as a bug to the application developer. There are many open-source
projects that I have corrected, and I have also reported a bug in Logic (which
only appears with 24-bit files, since there is no support for 8-bit audio in
Logic). The size and prevalence of the problem does not mean that we can
simply ignore the specificiation.
Please: Do this right, do not invent your own convenient format and pretend it
is AIFF.
Brian Willoughby
Sound Consulting
Begin forwarded message:
From: Ev <email@hidden>
On Dec 2, 2004, at 2:04 PM, email@hidden wrote:
> Yes, at its most basic level, the AIFF specification defines chunks as
> having a 4-char name, 4-byte (big-endian) length, and data which is
> always padded to an even length. Even if the 4-byte length in the
> chunk header is odd (which is rare, but allowed), the file itself
> should start the next chunk at an even byte offset.
In my dealing with AIFFs and seeing all sorts of weird versions of
files, it is true that a block CAN have a padded byte, but it is not
necessary. That's the trick about the spec. In real life, it is not
ALWAYS padded to an even length.
I've seen it both ways in different kinds of blocks - as I've seen
different spec descriptions. *Some* blocks can have a pad, and others
don't say that they can.
I'm tending toward the REAL 4-byte length, odd or not, and the REAL
size, odd or not, being what is in the file - no pads necessary. It
makes it easier to walk the blocks and avoid accidentally skipping and
reading a wrong block type. That's how I'm doing it anyway. I wish
everyone had followed the spec, but now we're left with what the real
world has to give us. Urgh.
Ev
Technical Knowledge Officer
Head Programmer/Designer
Audiofile Engineering
http://www.audiofile-engineering.com/
_______________________________________________
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