kfile_mp3 patch to support id3v2 tags

[Scott Wheeler]

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       
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