Hi, I just found amarok two days ago - I\'m amazed! I\'m *still* finding cool things it can do

Anyway, many of my mp3s were having their ID3 information apparently \"truncated\" by amarok. As it turns out, this was because it was using the ID3V1 versions of the tags (which have limited space for the fields). It was ignoring the ID3V2 versions, which have the proper names.

However, lots of my other mp3s have id3v2 tags that are read correctly. However there is a fairly sizable number that \"drop back\" to id3v1.

I tried stripping the ID3v1 tags from them, but leaving the ID3v2 ones. Result: for the tracks which had the problem before, amarok now just uses the filename as the track title, and does not complete any of the other fields... I assume this is what it would do if there was no tag whatsoever.

Is this a known bug? I can easily supply a sample of an mp3 with this problem if someone wants... The information in them only has A-Z, 0-9 and some punctuation, so I don\'t think its a character converson issue.

Hi - its a bug in taglib - it can\'t cope with TSIZ tags. Bug report here: http://bugs.kde.org/show_bug.cgi?id=100515

I hacked a quick program together using id3lib (NOT taglib as it breaks on them to strip them out - here it is if someone finds it useful.


[code]
#include \"id3/id3lib_streams.h\"
#include \"id3/tag.h\"
#include \"id3/misc_support.h\"
#include \"id3/id3lib_strings.h\"

using std::cout;
using std::endl;
using std::cerr;

using namespace dami;

int main( int argc, char *argv[])
{
ID3_Tag tag;
ID3_Frame* frame;

if (argc == 2)
{
tag.Link(argv[1]);
do {
frame = tag.Find(ID3FID_SIZE);
if (frame) {
tag.RemoveFrame(frame);
tag.Update(ID3TT_ID3V2);
}
} while (frame != NULL);
}

return 0;
}