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 23:01:28 -0600
On Dec 2, 2004, at 9:29 PM, Brian Willoughby wrote:
[ 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.
If you're saying that the file ends with this chunk and no padding, or
that
the next chunk starts on an odd byte, then it truly is a bug.
To be specific, I got this from "Chunky Guitar Delay.aif" from the
Apple Loops SDK.
I also found it, just to corroborate, in "Single Closing Hat 01.aif",
which buried deep inside of the Garage Band library install.
Immediately following the 3230 3033 ("2003") comes 6361 7465 ("cate"),
the beginning of the category block. No pad.
Basically every other file in the Garage Band library (and many other
AIFFs, I might add) are like this.
You can corroborate this with a hex editor (I use Resorcerer), and peek
into any of these files and see the same thing.
If they're wrong by their own designs, then, yes, you should report a
bug. It
happens all the time. The most you'll get is a big "thank you" from
the
engineer who made the goof, because you helped them fix a problem.
No you didn't. You just brought it to their attention. Doesn't mean
it's fixed. It could just as easily be ignored.
As a developer of audio-file-reading software, am I supposed to wait
for a fix?
How, for example, would Apple go about correcting around 3GB of audio
samples on each computer with Garage Band installed?
I have reported AIFF errors to many developers, and they have never
come back
and argued with me.
Logic is now owned by Apple, and they have a bug like this.
Telling Apple about this bug and expecting them to fix it is like going
to Harper Collins and
telling them that "ain't" is not a word, and they should remove it from
all of their books they publish.
Of course you're correct, and of course you will not get an argument,
but do you expect anything
to really be done about it? There are literally millions of audio files
floating around with this "bug", not
to mention the number of Garage Band installs, which come on all new
Macs (am I correct on that one?), and
some of the files I see I have *no* idea what program made them or
where they came from (perhaps from PCs) -
and my software is supposed to *not work* with them? They're totally
readable, the solution is right there - "optional padding".
I don't know of any other audio-file-aware app that has a problem
reading these kinds of blocks.
[ 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.
It is not a matter of believing *me* - all you need to do is grab the
specification and see for yourself. Believe the spec.
You're talking about individual files. They are not the specification.
Hey, I've checked the dictionary, I know "ain't" isn't a word. Doesn't
mean I can't understand it.
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