Only the "album cover" image in a file can be set (all are displayed, though.)

Processing ID3V2 only keeps one copy of the known frames except for images; multiple images are kept, as long as they 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 only format available for saving track information is ID3V2.3.0

One text frame format in ID3V2.4.0 isn't supported yet (though it 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 limited 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) or when you try to apply transformations to such a file. Note that in either of these cases, the decision that the file has changed is made based on whether its date or its size have changed; so changing the ID3V2 tag in an external tool that keeps the file's original date may go undetected.

It is possible for audio frames to store some of their data in the neighboring frames (search the web for "bit reservoirs"), 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 neighbor 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.

Not really an MP3 Diags limitation, but: On Windows there may be some issues with the normalization of files whose names fall outside the system codepage. This is because although MP3 Diags passes such names correctly to MP3Gain, MP3Gain doesn't seem to use Unicode even in the beta version that allegedly added Unicode support. Anyway, testing this took me all of 2 minutes, so I might have missed something. If somebody knows how to make MP3Gain use Unicode names, please let me know. Two options that I could think of were to either use some other normalizer or a small intermediate program, which would rename the files so that MP3Gain could access them, then call MP3Gain, and then rename them back. Also, maybe changing MP3Gain to use Unicode names isn't that hard.

Under some circumstances, it is not possible to change files in some folders under Windows 7. There are more details here.

Daylight Saving Time is not taken into consideration. As a result, on some combinations of operating systems and file systems, it is possible for an unchanged file to seem changed after a DST transition; nothing bad should come out of this except that the file will get rescanned.