I've been observing how between different versions of Mp3Tag there are fields that:
new ones appear
others are replaced (and sometimes replaced in later versions)
disappear
To put us in context, let me indicate what I have come to observe so far:
"ALBUMARTIST" field: in version 2.46 it was replaced by "BAND", but I see that in v.2.87 "BAND" disappears and "ALBUMARTIST" returns.
"ORIGTRACK" field: I see that in v.2.87 it no longer appears. And I would like to know if it has happened as in "ALBUMARTIST" which has been replaced, or, directly, it has been deleted.
Reviewing the official Mp3Tag change relation, all changes are indicated, but nothing is indicated about aspects like the changes between versions of the different Fields. Where could one obtain the report of changes made in the different versions?
Some may consider this aspect to be unimportant, but it should be taken into account that if you have a database of years... these changes do affect the updating of this database.
What kind of database do you mean?
MP3tag deals with metadata inside of the music files.
The names you mention are only names for Mp3Tag but in the files i.e. the name for ALBUMARTIST/Band is TPE2.
So the only thing that has changed is the name in MP3Tag for the content it shows in TPE2.
That's why I only know where to find the relation of all the changes of Fields that are made to know which version to install or which one I should update.
You find a complete list of supported fields in the help:
The only place where a different field name could matter would be in the actions - where it gets updated automatically or in export scripts which you have to maintain.
Also, you could configure MP3tag to have a mapping between field names, like BAND, ALBUMARTIST and ALBUM ARTIST - which would be outside the controle of MP3tag.
Your sql database should not be compromised in any way as this should have its own import mechanism form the csv file
Effectively: with mapping I would solve the problem of different names to be able to assign them to the same field:
Thank you very much.
Anyway: The URL you enter only indicates the complete Field relationship. I understand, that knowing in which version of Mp3Tag a field is deleted, there would be no way to know: right?
The initial idea was to not be touching the .CSV export script every time I changed versions. I assumed that those fields were generally stable. And they are in fact, but of course, over time you tend to expand the number of fields to be used ... and in the end those changes of Mp3Tag on "less used" fields end up affecting you.
And not only because you have to touch the script, but also because apart from all the work of maintaining your database, you have to keep a record of all the old and new fields that occur throughout all the versions of Mp3Tag. A bit confusing, isn't it?
The changes in field mapping are also described in the changelog. In fact, most of the changes were made with v2.47 (almost 10 years ago), also slightly contradicting the observations you've described above:
CHG: renamed field name BAND to ALBUMARTIST
CHG: renamed field name ALBUMSORTORDER to ALBUMSORT
CHG: renamed field name ARTISTSORTORDER to ARTISTSORT
CHG: renamed field name BANDSORTORDER to ALBUMARTISTSORT
CHG: renamed field name COMPOSERSORTORDER to COMPOSERSORT
CHG: renamed field name TITLESORTORDER to TITLESORT
CHG: renamed field name TVSHOWSORTORDER to TVSHOWSORT
CHG: renamed field name ITUNESCOMPILATION to COMPILATION
CHG: renamed field name ITUNESPODCAST to PODCAST
CHG: renamed field name ITUNESPODCASTCATEGORY to PODCASTCATEGORY
CHG: renamed field name ITUNESPODCASTDESC to PODCASTDESC
CHG: renamed field name ITUNESPODCASTID to PODCASTID
CHG: renamed field name ITUNESPODCASTURL to PODCASTURL