I suggest that Mp3tag have a changed paradigm, from editing tag data of connected audio files to, editing tag data of a local repository that connects to audio files by way of an unique identifier.
To the casual user the status quo is perfectly fine, however to the retentive, anal or otherwise, we rely on the tag data even more that Mp3tag has perfected it. Most of us spend far too much time compiling composers, lyricists, band info, etc. which is somewhere from difficult to arduous to backup and recover if the data/file is lost.
A major problem is that there is no innate backup/recovery function in the program. There is a script floating around in the forums that helps to cover the dumping of all tag data of each file in a structured way. However, there is no way to automatically go in the opposite direction. The data has to be manually examined and an import function written. A solution may be to write the import script as a function within the exported file. As a matter of process, I backup all of my tag data on a per album basis in the folder as the files.
Even if backup/recover was included, there is the problem of having data of more than one quality existing in your collection. For example, you bought a compilation, tagged with discogs info, then later bought an album of one of the artists and again tagged with discogs info. One dataset has lesser info, maybe it is "T. Eliot" in one and "Thomas Stearns Eliot" as lyricist in the other.
So, in the changed approach, one would find the following:
- There would be instead one release with all the info you acquire as time goes on in one local, personal, supreme (to me) repository.
- This release is manually associated (by a unique id) to zero or more audio files.
- The data in each release is manually synced (or automatically on change or when the audio files are reachable).
On the other side, we can access and import data, partially or wholly, from the likes of the discogs and amazons. So lastly:
4) There should be at least an export/import function which copies the repository, partially or wholly, to a text based data format, like xml.
The drawback on the backend is accessing repositories, which maybe be trivial for a few hundred items but may have an adverse impact for those of many thousands or more. To the user, the filter panel would be prominent and useful.
The problem with Mp3tag is that the more you use it is the more you use. A good problem to have.