kfile_mp3 patch to support id3v2 tags

[Malte Starostik]

On Sunday 27 October 2002 02:33, MadCoder wrote:
> > > kfile_mp3.cpp:180: no matching function for call to `ID3_Tag::Link
> > > (QString, ID3_TagType)'
> > > /usr/include/id3/tag.h:74: candidates are: size_t ID3_Tag::Link(const
> > > char *, short unsigned int = 65535)
>
> what did you do ? line 180 is :
> ,---------------------------------------------------
> id3v2->Link(mp3.filename, (short unsigned int)ID3TT_ID3V2);
> `---------------------------------------------------
> and mp3.filename is a char[] ...
> it's not my fault !
Now this is weird. I'll try to build it later and see if it breaks for me as 
well (only the error message got my attention for now, I didn't try it myself 
yet).

> I used the KDE build system !!
I though so, that's why I wondered how it happened

> > There's also a more serious problem to this: what encoding is used by
> > libid3? Is it UNICODE-clean? You'll have to use latin1() if it only works
> > with latin1 anyway, local8Bit() if it works only with 8bit strings but
> > supports local charsets or utf8() if it supports UTF-8. Similarly for
> > converting back from libid3's char* values to a QString. Otherwise your
> > plugin will fail for non-latin1 users.
>
> in fact, the id3lib does not care of encoding. you give her the string it
> copy it to the tag place, and it read the tag and give you the raw data,
> you do what you want with it.
Ouch :-)

> the standard tells that a id3v2 tag should be iso-8859-1 encoded or unicode
> encoded (http://www.id3.org/id3v2.3.0.html#sec3.3). But as one developper
> of the actual kfile_mp3 plugin said on the cvs comments : many player
> does'nt support utf8.
>
> So i made the same choice as him, i used
> QString::fromLocal8Bit/QString::local8Bit as the previous developper did.
>
> if there is something wrong, say it to me, the modification is easy to do.
I'd say local 8 bit is the right way *) if players don't really support it.
BUT, reading the spec you linked, I see that unicode does not refer to UTF-8 
but UCS-2 and uses the usual 0xFF 0xFE resp. 0xFE 0xFF to mark the contents 
as such. I have no idea if other players support that or not, this is worth 
investigating. That many players don't support UTF-8 seems pretty normal as 
UTF-8 isn't allowed in the tag :-)

-Malte

*) local 8 bit does violate the spec, but seems like a good compromise to me 
if there's really a problem with many players and UCS-2