Re: Itunes structure (off-topic)
Re: Itunes structure (off-topic)
- Subject: Re: Itunes structure (off-topic)
- From: Allan Odgaard <email@hidden>
- Date: Tue, 6 Apr 2004 19:53:46 +0200
On 6. Apr 2004, at 16:48, Bob Ippolito wrote:
GIF is a perfectly fine format, it is actually MUCH MUCH easier to
write a binary parser for the GIF header in a low level language than
it would be to decode some XML garbage, especially in the 1980s when
well, XML DIDN'T EXIST AND NO PARSERS WERE AVAILABLE FOR IT!
I did not mean to say that GIF should be encoded in XML. And I
certainly do not agree that GIF is a fine format, I know this from
experience as I wrote the GIF decoder for a web browser long time ago
-- I started out using a public source (from the unix image package:
netpbm), but it turned out to only be compatible with 90% of the images
floating around on the net -- so I eventually had to write it myself,
and I tell you, despite the perhaps simple specification, there are
tons of pitfalls which you probably do not notice unless you get a
sample of all the ways the format was "exploited", although much of it
relates to GIF anims (but that was actually possible with the org.
specs).
As for ID3 v2.x, I see no real good reason to store XML at the
beginning or end of all your mp3 files. I don't know the specifics,
but they might be trying to encode it into valid MPEG frames, which
are pretty small, so XML would be a bad idea there too.
Again, I was not advocating XML -- just pointing to some formats which
one should definitely not draw experience from. The main problem with
ID3 v2 (apart from each of the 3 minor versions being incompatible with
each other) is that it is far to ambitious, it supports checksumming
each tag, compression, encryption, different encodings, padding and so
on, which are again indicated by bits which change the way one has to
interpret the tag (there are some variable length flags in the
beginning IIRC) -- this makes it difficult to write a generic parser
without incorporating knowledge about the previously mentioned things,
and it makes it cumbersome to skip through the tags.
In any case, you are an idiot if you write your own library for
dealing with ID3 and GIF for nearly anything but educational reasons,
Well, thanks a lot for that label! As said, I started out with a public
source for GIF decoding, but it actually crashed with some GIFs -- when
I had to do ID3-parsing the people making the standard hadn't even
completed their own library, which was anyway bloated like hell.
Did you stop to consider that some actually have to write those public
libraries in use? perhaps that somebody is me, perhaps I like to use
the formats before public libraries become available or perhaps I write
mp3 player software for embedded devices where the bloat of the
existing libraries means that we need to place an extra RAM chip on the
device, which enlarges the size and/or price of the device.
Or perhaps I want to batch edit my mp3-collection from Ruby and would
prefer something simple rather than having to bridge to C and go hunt
for a public library because the format has been rendered too complex
for a computer science graduate to be able to write a parser for it in
less than several days.
and you have very little reason to complain about the formats.
I have much reason to complain! I am a programmer and I do on occasion
need to write parsers for public formats (or generate output in a
public format, which was the case with Flash/SWF) -- of course it is
better to provide constructive criticism, but believe me, I do try to
do that as well (to the authors of the formats)!
Saying that I should just use public libraries instead of "complaining"
about bad design (or at least point to the weaknesses of the formats)
is really counter to how I think. And although it sounds like a
cliche, I would like to make things better instead of accepting the
status quo, and I don't mind getting my hands dirty in the process,
meaning making as many constructive contributions as possible, which
sometimes means complaining in public about bad design... although this
list is probably not the best outlet for such -- and I apologize to
others for following up (again) to this off topic thread...
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.