Only a single image per file is displayed or can be added.
Currently, if asked to save an image that is identical to an existing one except for the picture type, the new image is not saved. This approach looks the least likely to confuse players. If needed, a transformation that changes picture types can be added.
Links are not supported for images. This is bad if you REALLY need to scan your vinyl collection at 4800dpi and save the result as an uncompressed TIFF. Instead, images are stored inside the MP3s themselves and if they are big they get resized so they take less than 100KB. For now this maximum size is hard-coded.
Processing ID3V2 only keeps one copy of the known frames except for images; multiple images are kept, as long as they only they have different image types (and the settings say to keep them.) The other frames are supposed to have only one instance, except for POPM (which is used for ratings), so this is the only case where valid data is lost; that is, assuming anybody has files containing multiple POPM frames.
The e-mail address in POPM frames is ignored at reading and erased at saving.
The only format available for saving track information is ID3V2.3.0
Some text frame formats in ID3V2.4.0 aren't supported yet (though they can be added easily, if needed.)
MP3 Diags expects folders to be albums, having less than 30 files. If this is not the case, it's better to avoid using the tag editor, which might take a long time to load, especially if the files contain images. Even if the tag editor loads OK, it is designed for albums, so it may do things that make no sense for random collections of files (e.g. assigning the same image to all the files.)
Symbolic links aren't handled nicely. I noticed that Qt replaces them with their targets, which is something I don't like. Also, I haven't tried it myself, but I expect scanning folders that have symbolic links to their ancestors to cause MP3 Diags to keep scanning the same files until it runs out of memory.
There is no automatic detection of a file being changed by an external tool or removed. You should use the "reload" button to update the file information. However the changes are detected the next time you start the application (assuming you didn't disable the automatic scanning.)
It is possible for audio frames to store some of their data in the neighbouring frames, but I haven't looked into how to detect when this is happening. Currently MP3 Diags only reads the header of the audio frames (which doesn't have neighbour information.) As a result, it doesn't detect that some frames are missing or should be deleted.
The function calls to the file system (open file, search for files, ...) provide and expect UTF-8-encoded file names. This is important if you have file names using non-English characters (or rather non-ASCII, to be more correct.) I have no idea how big this issue is, because the test systems use UTF-8. It may be that the file names are displayed incorrectly, but the files are still processed, or it may lead to more serious errors. So please
tell me if you seem to encounter errors related to this or if you can provide more insight into UTF-8 handling.
On Windows the path separator is usually the forward slash '/', as on Unix, and not the backslash '\'. However, '\' is shown in file open / directory selection dialogs, because they are native Windows dialogs.
On Windows MP3 Diags doesn't even look at a file whose name contains characters with a code above 127, so file names in foreign languages are affected. This is caused by a limitation in MinGW, the Windows port of the GCC compiler that I use. I don't know if the ancient MinGW 3.4.2 can be persuaded to use UTF-8 for file names, but I suspect it can't. If anybody knows different, please tell me.