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: Ev <email@hidden>
- Date: Thu, 2 Dec 2004 20:57:39 -0600
Dude, point well taken, but what the heck are we supposed to do when this:
2863 2920 0000 0019 4170 706C 6520 436F 6D70 7574 6572 2C20 496E 632E 2032 3030 33
( c ) A p p l e C o m p u t e r , I n c . 2 0 0 3
shows up in an AIFF file? Not to mention, an Apple Loop - furthermore, an example Apple Loop from
the Apple Loop SDK??? If you read into ANY Garage Band file, you'll see this line.
I mean, how much more flagrant a disregard of their OWN spec is it to put their own
*copyright* notice in an *example file* of their own *FILE TYPE*?? So Apple is the only one allowed to break
the rules, and we're just not supposed to be able to read them? Are Apple Loop files now all of a sudden not
AIFF files? Are we supposed to throw a *bug report* to Apple themselves, and have them correct the entire
Garage Band library?
I'd love to believe you, I truly truly do, as my programming job would be easier, but in real life it just doesn't play out that way.
On Dec 2, 2004, at 6:29 PM, Brian Willoughby wrote:
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.
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