Comparing the results of id3tag to the results of taglib: 3 potential bugs

[Brian Nickel]

Just a few comments on a couple of these.

> taglib is usually much better than id3tag. It has however the tendency
> to report trailing spaces in strings like Album name. I check with an
> hex editor and found out that the spaces are indeed present in the
> tag. Given that this string is not null terminated, I suppose that
> there is a length field somewhere. I guess taglib is correct and the
> trailing space has been inserted by the encoder (or the program
> calling the encoder).

As of Id3v2.4, text frames are null separated string lists so "Brian\0"
would become {"Brian", ""}. What TagLib does when reading is split up
the string into a StringList and stores it in the object as fieldList.
When tag->artist() is called, it returns the frame->toString() which
then returns fieldList->toString(). Which should just jount the strings,
therefore TagLib shouldn't return string with a null terminator.

Looking at the code, TagLib does not contain:
String StringList::toString() const, only:
String StringList::toString(const String &separator) const, so I'm
wondering if the calls to "toString()" are causing the problem. You
could try patching taglib/mpeg/id3v2/frames/textidentificationframe.cpp
to use toString("") instead and see if that solves the problem.

It might be best, however, for TagLib to discard empty strings when
parsing, so "Brian\0" would just become {"Brian"}

> taglib svn 621706 returns duplicate genre string like "Rock Rock"
> instead of "Rock" and "Pop Pop" instead of "Pop" (list is non
> exhaustive).

This is probably caused by the new function:
void FrameFactory::updateGenre(TextIdentificationFrame *frame) const

This parses Id3v2.3 genres to Id3v2.4 genres. Often genres are stored as
"(2)Country", which TagLib parses as {"2", "Country"} and converts to
{"Country", "Country"}

-Brian