Update: I found a way to reproduce this, the unicode handling was fixed for some parts of the mp3 header but not for tags. This should be fixed for the next version.
Thats great news!
But...I just found another issue related to ID3 handling.
Check out
this example MP3, cut down from Disarmonia Mundi - Shattered Lives and Broken Dreams.
Ripped it years ago from CD using MMJB, which seems to write a fairly large tag called GEOB.
Testing it out with mIRC, $mp3(test.mp3,0).tag only returns nothing. Using good old $mp3(test.mp3).title, nothing happens either.
Looking at the file in a hex editor (or using my own DLL), it shows other information such as TPE2, TRCK, TALB and TIT1 too.
Also, trying to access one of the tags (TPE2 for example, $mp3(test.mp3,%index_of_TPE2).tag), mIRC hangs for a second or two, and returns nothing at all. At least the real file does, the larger the file, the longer it takes - test.mp3 is cut down to a second, so it doesnt really take that long.
But...the file plays without any cracks or anything. Only Tag-reading seems affected.
I suppose there is either another flaw in reading the ID3v2 header and/or the frames; or the ID3v1 reading is bugged somewhere aswell (using .title etc doesn't return anything either!)
FYI:
The ID3v2 tag size is stored as a 32 bit synchsafe integer (section 6.2), making a total of 28 effective bits (representing up to 256MB).
(from the ID3v2 Spec at
http://www.id3.org/id3v2.4.0-structure)
My DLL uses this to get the right tag length:
unsigned int ConvertID3v2HeaderSize(unsigned int in) {
unsigned char *input = (unsigned char*)∈
return (input[0] & 0x7f) | ((input[1] & 0x7f) << 7) | ((input[2] && 0x7f) << 14) | ((input[3] && 0x7f)<< 21);
}Note this only applies to the ID3v2 header itself, not to frame headers.
I suppose you may be missing that, you are missing some delimiting char (possibly a buffer overflow?) or either got some other offset-related thing wrong.
I hope I could help with that mp3 file, hoping to get it fixed soon
Greetings, BhaaL
