Version: (using KDE KDE 3.3.2) Installed from: Compiled From Sources0 OS: I Don't Know If there are ID3v2.2|3|4 APIC Frames in a mp3-file taglib is not able to correctly parse all tags. It looks like all tags after the APIC frame are ignored/discarded. Maybe not only after the frame but taglib messes things up if you have pictures attached. Remove the picture with another editor and everything is fine. I tested this with iTunes 4.7.0.42 and let iTunes convert the ID3v2 tag to version 2.4. Always the same result.
Update: Its a windows (probably dev-cpp) problem. fread() does not work as expected. I checked it on my linux machine and everything worked fine. Since you don't officially support Win32 you may close this report. However it would be great if you know what to change since I wasn't able to figure out the differences in POSIX and mingw fread() :-(
Solved: To make taglib windows compatible you have to add the following to tfile.cpp somewhere at the top: #ifdef WIN32 #define ftruncate chsize #endif in File Constructor change the file open command: d->file = fopen(file, d->readOnly ? "r" : "r+"); to this: #ifdef WIN32 d->file = fopen(file, d->readOnly ? "rb" : "r+b"); #else d->file = fopen(file, d->readOnly ? "r" : "r+"); #endif
Sorry, I don't add WIN32 stuff to the sources since I don't have any way of testing them in future releases. I got an updated set of patches for WIN32 for 1.3.1 while I was away on vacation (which I just got back from today) that I'll do a review of and post on the taglib site shortly.
I have looked into this on windows (musikcube) and the problem seems to be the unsynchronisation of the tag not taking place when the unsynchronisation flag is set. Since APIC frames are binary, any false syncs have to be converted. All my tags have pictures and all use this scheme. When reading the tags, taglib doesn't do anything regardless of the state of the unsych flag. This means that the size of the APIC tag is reported lower than the actual length, which causes no frame header to be found while trying to parse the next frame. taglib then gives up. You can test this by inserting the APIC frame after the text frames. All text data is read fine because even though the entire tag has been unsynched, ascii data has no false synchs to encode, so they are read fine. From http://www.id3.org/id3v2.3.0.html#sec5 Whenever a false synchronisation is found within the tag, one zeroed byte is inserted after the first false synchronisation byte. The format of a correct sync that should be altered by ID3 encoders is as follows: %11111111 111xxxxx And should be replaced with: %11111111 00000000 111xxxxx