Slightly Changing the Paradigm

Development
1

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:

  1. There would be instead one release with all the info you acquire as time goes on in one local, personal, supreme (to me) repository.
  2. This release is manually associated (by a unique id) to zero or more audio files.
  3. 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.

2

I think this is already possible.

3

This opinion is not quite right.
Once the "dump all tag data" MTE script ist established in the proper way, then the restore process can be done by Mp3tag Convert "Textfile - Tag" as easy as is.
To have a functional Backup/Restore process at hand, that was the main target to evolve such MTE scripts.

DD.20140923.1728.CEST

4

You can export tag-field data and free floating text into any text format you are aware of, by writing or applying the proper export script.

DD.20140923.1734.CEST

5

I would love to see a working script that 1) exports all data from my thousands of albums, compilations, EP and singles of various levels of completeness and in numerous places, and 2) idiot-proof enough to allow fully import without any intervention except to run the script. This is all within the current paradigm.

Currently, it is one of the best at accessing and manipulating the metadata. It is a tool, a good one, but I have to do the management. My proposition is to make the next evolutionary step with a repository as basis. This will allow for easier, consistent management and hopefully by the app. With a repository db, backup and restore has to be built-in at the start - no afterthought. In my world, the data is king—structured, accessible, distributed and safe.

I hope I did not imply the contrary. This is a benefit of Mp3tag in its current form, but it lacks roundtrip data.