Change ALBUM value based on values of tags of other files of the same CD

I have fairly large collection of classical music (approx 10k songs), that I want to clean up / restructure tags. Generally, I aim to follow the convention that is proposed in several www articles, i.e. to put the composer in the ARTIST tag, and I would like to achieve that the ALBUM name becomes identical for all songs that come from the same CD originally, without using COMPILATION (unless there were pieces of different composers on the CD).
As all CDs were ripped with iTunes, all songs/files have the ITUNES_CDDB_IDS field completed (unique value per album).

So I want to accomplish the following :

  1. copy old ARTIST and old ALBUM to COMMENT field (e.g. separated by a | ). This is just to not loose all the information currently in the tags. I also could copy either old ALBUM or old ARTIST to COMMENT, and the other to another (not used) field. But I am a bit short of inspiration which other field to (mis-)use, and I think that keeping both in the comment field, separated with a | would allow me to easily consult the info, and also to filter out again both separate values if in the future I want to undo.

  2. For all songs/files with the same CDDB_ID and the same COMPOSER, the COMPILATION must be set to "0" and the ALBUM value must be made identical :
    2.i) if the existing ALBUM value and ARTIST value is the same for all songs with the same CDDB_ID, set the new ALBUM value as "old ALBUM" [by old ARTIST]" of the 1st song of the album (the square brackets and the "by" is just for easier reading)
    2.ii) if there are different ALBUM values and/or different ARTIST values, set the new ALBUM value as in 2.i), but add "E.A." (et alii) behind either the old ALBUM and/or old ARTIST respectively.
    2.iii) copy COMPOSER field to ARTIST

  3. If CDDB_ID is identical, but there are different COMPOSER values, set COMPILATION to "1". (I don't know yet whether I could automate the ALBUM value change; if there are not too many albums, I might do this manually, otherwise it will be a variation of 1), and keep ARTIST unchanged (the album will be filed under compilations anyway, so ARTIST can remain)

  4. and 2.iii) are not too difficult, as this are just tag/string manipulations on song level, so this I know how to do.

My question is how to accomplish 2). Is the scripting language powerful enough to work on a group of songs/files based on a common ID? How would I have to tackle that? Any hints/pointers/examples?

And 2.i) is the critical / must-have part of course, but I guess that once I know how to accomplish this, it would not be much more difficult to add the test on the ARTIST and ALBUM fields (to add or not the E.A.).

A direct (elegant) solution with actions/scripting would of course be best (but I have no ideal whether this would be possible).

In case it is not possible, I was already thinking about work-arounds / shortcuts:

  • create a new directory structure based on the CDDB_IDS, and then it is maybe easier to work with files in the same directory?
  • export the entire song list & tags into excel, do all the manipulation there, export as txt file, and use this to change the tags in mp3tag (this is obviously not an mp3tag solution ...)

Thanks for your help !!

MP3tag does not know anything about other files. It only treats information that is visible when looking at one file each.
So any attempt to work on some kind of groups will fail unless you tell MP3tag to treat a set of files as group by selecting them.
Also it is not possible for MP3tag to guess what the original name of an album would have been. Even the creation of a folder structure based on the cd id does not help unless the orginal album name is part of the folder name.

Yes, there is an export function that you can adapt to your needs and even export to files that can be treated by Excel and there is an import function that allows you to get the data from the Excel files back into the audio files.

A compilation is treated like one if you keep the fields for ALBUMARTIST and ALBUM constant for the whole set of files. There is no need to use the field COMPILATION.

Merging two fields into one does not seem attractive to me. I would create user-defined fields like %original_artist% and %original_album%.

To transfer the complete contents from a source field to a target field, create an action of the type "Format value" for the target field.
Format string: %source field%
where %source field% stands e.g. for %artist%.

I still doubt that the switch from composer to artist actually is sensible as the field COMPOSER is actually a dedicated field for the name of the composer. The ARTIST would then be (e.g.) Anne-Sophie Mutter or another one like Anna Netrebko. I would never look for these names in the field composer.
iTunes and WMP allow to group by and filter for the contents of COMPOSER.
So I don't know what kind of advice these www sources give.

@ohrenkino, thanks a lot for taking the time to reply.

I already suspected this (I did search a fair bit before posting my question), but I had seen a reference to "macros" in the title of a support forum (although I never discovered a macro function in MP3Tag), and also had seen some functions to extract and pick up album art of songs in the same folder, so I had some remote hope that it would have been possible.
What I want to accomplish seems so easy and straightforward in pseudo programming language (just a few nested FOR or WHILE statements) ... :frowning:

I understand that, and I did not expect that it would be possible (or that I would want it, given that most databases, maybe except discogs, are not very consistent with naming.
Currently the ALBUM and ARTIST field are completed (user defined when ripping), so a combination of both would be sufficient for me, and give a very good view on what is on the Album. Therefor my aim is to create the new ALBUM value myself, by concatenating the current ALBUM and ARTIST values.

Maybe it is redundant, but I use iTunes, and on the remainder of my library, I always used the COMPILATION field. I want to make sure my use of tags is as future-proof as possible. Besides, in most cases I would have to set ALBUMARTIST as the same value of ALBUM (which is a wast of space), or use a generic value as "Various", so having a field with a value of "1" seems in my mind more logical. But it is a good suggestion, and to make my tag content as future proof and compatible with as many possible playing devices (I currently use Apple i-devices, Android phone, car stereo, and Sonos, but maybe others in the future), it is maybe a good idea to populate the ALBUMARTIST field consistently with "Various" if the COMPILATION field is "1" (and keep it blank if "0").

I know that I could use user-defined fields, and that it is supported in the IDv.. standard. But as I read elsewhere on the forum, standards are not always followed. COMMENT seems one of the core tags that are widely supported. In MP3Tag I see some existing extended tags that I could use, ORIGARTIST and ORIGALBUM (so I don't have to create user-defined ones). And I can use the "belt and braces" approach. Use these two fields, and also copy both to COMMENT with the | delimiter.
Or could you elaborate why you think using the COMMENT field would be a bad idea? (I don't use it for anything else).

I played with export in CSV format, but when I changed the ; into | in the export config file, I receive a [ SYNTAX ERROR IN FORMATTING STRING ] in the output file. As the ; (and many others) are already used in the tag values, I want a delimiter for a fool-proof "text to columns" conversion in excel. Any suggestions on how to proceed? Or any other filetype to use that is easy to import in excel?
For import (I assume you mean the "textfile to tag" conversion?) it seems easier. I could add the | between the columns in excel, export as a tab-delimited txt file, and then use "txt to tag". Can you confirm that MP3Tag would ignore the tab characters ?

See some www info below. I have been using this convention, and it suits me well. Main view to browse my collection is ARTIST, and in a mixed pop/classical collection, it just makes sense for me to have Mozart at the same level as Bowie. I am not saying the performing artists (the soloist, the orchestra, the conductor, the choir, etc.) are not artists, but if I had to choose only one, it would be the composer ... And it's not as if I would send poor Anna or Anne-Sophie to oblivion, but they would show up in the ALBUM, e.g. "La Traviata [by Anna Netrebko, Rolando Villazon, Wiener Philharmoniker]" if they are the only performing artist, and also in the ORIGARTIST file and in the COMMENT field of the song.
I would never browse my collection by orchestra or soloist (typical info contained in ARTIST field for classical music); and with a search function, I still can select all tracks where I can hear Anna or Anne-Sophie.
Anyway, just my 5 cents; I fully acknowledge it's not perfect, many other ways exist to structure/classify a music collection, it just depends on how you use it.

Maybe one off-topic question/comment (I probably have to start a new topic for that): I was thinking to start all classical music composers with an underscore, so that they would show together either in the beginning or end of the library if you browse by artist. It's maybe my OCD side that wants that, as I know of course that I can add multiple criteria to search, but just the idea of all this classical composers grouped together in Artist view (and on my hard drive :sunglasses: ), seems compelling ...
Do you see any downside for doing that?

Note : www info about structuring classical music libraries (often with iTunes as a driving force for some of the idiosyncrasies ...)

The "macros" are actions and action groups in MP3tag. They sort of work like for ... next loops as they deal with all the selected files.

E.g. WMP does not display the COMMENT field at all.
I am not sure what Android players do. So the COMMENT field does not grant wide support.
Neither do the ORIGARTIST or ORIGALBUM as most player programmers simply ignore them.
Actually, they are not MP3tag ideas but laid down in the ID3 standard.
You can see a list of fields that are supported by MP3tag in the help:

The export script can be adapted to your needs.
I would use the tabulator character as separator - this is also understood by Excel:

Not by default but depending on the format string with which you tell MP3tag how to interpret the records in the text file.

From a data keeping point of view you turn from structured information (where every piece of data has a specific named tag on it) to unstructured information in the shape of an amorphous string.
Those who collect pop music see the lack of structured information in the lack of a field for featured artists. So there are lengthy discussions and suggestions how to get the featured artist either into the ARTIST field or the TITLE field, depending on the preferences. It would all be easier if there was a field like for MIXARTIST.
So with a purist's view I see it as a step backwards to merge formerly structured data back to unstructured data. But if you find yourself more at home with the merging approach, you are welcome, MP3tag has all the functions to help you to minimize the manual work.

Thanks for your help.
I understand the next loops, but I see that what I want to do is not possible in MP3Tag, and will be quite straightforward in excel, so that's the route I'll take. Maybe you have seen my other post explaining how I will do it (and with another question about the txt>tag conversion)

I didn't know that the TAB character can be used both by excel an MP3Tag, so thanks for pointing that out; but pipe | seems just cleaner and I cannot confuse it with blanks or spaces or other non-printing characters. I am probably too old fashioned ... and too visually inclined to use TAB :wink:

And I agree with your point about data integrity, and not misusing fields. But please note that the current values of the ALBUM and ARTIST fields are not the standard values from a database or meticulously copied from the CD cover. It is often already shorthand or just partial information, so I don't feel that I violate a high-integrity data field with unstructured data. And in any case, I keep the initial data unchanged in the two ORIG- fields in my tag structure of all songs, so all changes I make are fully reversible (if I want to do that in the future). It is indeed a way of working for convenience and a preference to make it easier to do things in iTunes.