kfile_mp3 patch to support id3v2 tags
wheeler at kde.org
Mon Oct 28 10:41:23 GMT 2002
Quoting MadCoder <pierre.habouzit at m4x.org>:
> what do you think about it ?
Well there are a few issues here:
First, let me give a bit of background -- I was the id3lib maintainer for about a year. There are a
number of reasons why I have never switched KFMI for mp3 to id3lib:
*) id3lib is not binary compatible between releases, even minor versions. There is no attempt at
*) id3lib is barely maintained. There was a new maintainer who stepped up after I (mostly)
stopped working on it, but there are still a lot of issues there.
*) id3lib's code is *really, really* horrible and this makes it very difficult to maintain.
*) I've been working on an id3lib replacement for some time.
Sorry that I didn't see this the other day -- my home internet connection is gone for a couple of
weeks (switching providers). But, I actually spent most of the weekend hacking on my
replacement, which I hope to wrap with KFMI and I think should be ready for 3.2.
Advantages of my lib:
*) Faster -- I just did some testing yesterday and even before I've started any tuning my lib
reads tags about 40% faster. This really shocked me since there are a number of places in my
code that are far from optimal. (My theory has been design first, tune later; attempt to
encapsulate the areas that need tuning.)
*) KDE lib style code - While I'm not linking to Qt or the KDE libs (the only dependancy is the
STL) since I'm rather used to the style of KDE/Qt code, my id3lib replacement follows this
*) binary compatibility - I don't promise this before it stablalizes a bit, but the library is at least
designed to be binary compatible between releases once the API is a bit more finished. I use
d-pointers for every class and am familiar with the BC guidelines for C++ libraries.
*) Unicode support - id3v2 supports 4 text encodings - Latin1, UTF8, UTF16 and UTF16BE. As
such my string class supports those 4 encodings. id3lib was basically written to just support
Latin1, and Unicode support has been sortof halfway hacked in.
Right now I'm still a little way off from being ready to use "TagLib" (named such because I
eventually hope to provide a homogenous high-level C++ API to at least ID3v1, ID3v2 and
OggVorbis comments), but reading COMM and T[xxx] (comments and text fields) is working
and I did some work on the tag rendering code this weekend. I really feel like this should be
stable enough for inclusion in 3.2. However, if that fails, it *might* be ok to add the patch that
you sent depending on the other developers thoughts on the issues above.
I guess basically, taking a look at the id3lib code hurts. It's horrible. It's horrible enough that
after being the maintainer for a year I decided that it isn't salvageable. Basically it looks like it
was written and designed by bad C programmers who were trying to learn C++... You have to
be very careful to avoid memory leaks when using id3lib (this is from the code):
text = new char[nText + 1];
Oh, and there's also a lot of code -- about 30000 lines. Right now I can do many of the useful
things that id3lib does in about 3200!
Anyway, sorry for the rant. I've *really* wanted id3v2 support in KDE for a long time, but I
personally don't think id3lib is the way...
More information about the kde-multimedia