[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: kfile_mp3 patch to support id3v2 tags
From:       Scott Wheeler <wheeler () kde ! org>
Date:       2002-10-28 10:41:23
[Download RAW message or body]

Quoting MadCoder <pierre.habouzit@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        this.       
       
*) 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        style.       
       
*) 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];    
return text;    
 
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...  
  
-Scott  
_______________________________________________
kde-multimedia mailing list
kde-multimedia@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-multimedia


[prev in list] [next in list] [prev in thread] [next in thread]