Using FLAC I found that MP3Tag won't show the Album-Interpret though the tag is available. This is caused by a faulty mapping. The correct mapping tag would be ALBUMARTIST. You can resolve this issue by adding a user defined mapping. Go Options->Tags->Mapping and add:
VorbisComment ALBUM ARTIST ALBUMARTIST
Now this overrules the built in mapping.
Are you sure? I'm still using ALBUM ARTIST. In which direction do you want to map?
There's no mapping regarding ALBUM ARTIST or ALBUMARTIST in my MP3Tag installation. The corresponding help shows no default mappings (at least, I didn't recognize ...). For me, MP3Tag without mapping w.r.t. ALBUM ARTIST/ALBUMARTIST is just fine.
Hi
I came across some similar problems;
I am having an album with various artist - 12 flac files.
I have been selecting all files in mp3Tag (v2.5) and changed all there values in "Album Artist" to 'Various Artists'.
After that I was still not able to see the album as one album in Foobar2k or Media Center 17.
I started to investigate the tags using >>VIEW>>EXTENDED TAGS...<< and noticed that there were tag entries of "Album Artist" and "ALBUMARTIST" mixed across the file tags. I guess mp3Tag has used different entries for different files and did not make them consistent (I know they should be consistent in the first palace but they weren’t?!?) and confirm to the tag specifications. Instead it just filled one of them but left the other value filled with the previous value.
My workaround: deleting both tags in the extended tag view, saving the tag, and then reentering 'Various Artists' in "Album Artist" solved the problem for foobar and Media Center too.
Please impellent some lines that would do the cleanup automatically to avoid this problem in the future.
I have made a backup of the original FLAC files and there screwed tags if this is required to investigate the problem further.
Thanks,
xTobix
guys, the "standard" for vorbis vis a vis "album artist" is ad hoc, de facto, and officially non-existant.
some apps do with the space, some do without. some read both, but only write one or the other, etc...
so just setup the mapping in mp3tag to do what you want. for me, i like mp3tag to comply with winamp, so i added a "VorbisComment" line with "ALBUM ARTIST" as the "source" and "ALBUMARTIST" as the target.
Thanks, but this was a rather useless comment indeed!
If you would have read and understood my post you would have noticed that mp3Tag mixes them in an undesired and fatal way, it fails to clear them and to overwrite them, independent of what is set in the mapping preferences.
So again, what need is, that all common "Album Artist/Albumartist" are cleared/remapped into the one that is specified in the settings!
no, i totally understood your post.
a file can simultaneously have both ALBUM ARTIST and ALBUMARTIST tags. and some users may want it that way, if they use multiple apps that don't both use the field the same way.
you seem to blame mp3tag for your files having what you seem to feel are messy tags. but you don't demonstrate how mp3tag failed. its doing exactly what it should be doing. mp3tag does not by default treat two distinct fields as one and the same field.
I have clearly not blamed mp3Tag messing up the tag - someone else manage that prior... anyway
I agree that it is doing what it is supposed to do. The problem appears however when audio players read the tags. They just interpret differently across the spectrum between 'Album Artist' and 'Album artist'.
In my case (default settings) ALBUMARTIST is modified to @Various Artists' while ALBUM ARTIST is not modified.
I have been checking my tag mapping options and can only see three VorbisComments 1) DATE -> YEAR, ORGANIZATION -> PUBLISHER, TRACKNUMBER -> TRACK. the default settings in v2.50.
I have never played with the mapping before, can you (or someone else) advice how to modify the mapping to do the following:
if ALBUMARTIST is modified/deleted it should be replicated to ALBUM ARTIST too. ( I guess this is the most robust solution but with the danger of overwriting some information in ALBUM ARTIST only visible in the extended tag information)
Advice/opinions welcome!
Thanks!
You are correct that this mapping is not one of the three that are pre-defined with a virgin install of the current stable. They are:
TRACK is mapped to TRACKNUMBER
YEAR is mapped to DATE
PUBLISHER is mapped to ORGANIZATION (which I also mapped to LABEL)
However at some point I also found it useful to map ALBUMARTIST to ALBUM ARTIST
My recollection was that this helped with a problem I had with the current stable MusicBee using the latter rather than the former, and when I posted the issue to the MB forum, the developer stated that the next release will use ALBUMARTIST as his research confirmed this is now the defacto standard.
I believe Foobar2000 also switched over some time ago.
Just for giggles, here are others I've found useful, feedback would be most welcome.
VORBIS totaldiscs disctotal
VORBIS totaltracks tracktotal
VORBIS ORGANIZATION LABEL
ID3v2 ORIGYEAR ORIGINALDATE
ID3v2 SETSUBTITLE DISCSUBTITLE
ID3v2 Acoustid ID acoustid_id
ID3v2 MusicBrainz Artist Id musicbrainz_artistid
ID3v2 MusicBrainz Album Id musicbrainz_albumid
ID3v2 MusicBrainz Album Artist Id musicbrainz_albumartistid
ID3v2 MusicBrainz Album Type releasetype
ID3v2 MusicBrainz Album Status releasestatusSorry if I'm repeating from my recent post above. I feel:
as the now-more-often used ALBUMARTIST is also "canonical" in MP3Tags, it should be "target".
This allows ALBUM ARTIST and even BAND to be set as "source" in the mappings to that target.
This will in effect make these fields if present "disappear" within the MP3Tags UI, so (I think) you will need to create and run a one-time Action to copy their contents over to the new "canonical" field. Personally I'd then delete the old ones you don't need anymore.
If it turns out you do need them and you want to have the same values copied to the extra fields (even though they'll be "invisible" within MP3Tags now), what I would do is add such actions to my "backup" set, which also deletes a list of tags I occasionally come across in the wild but I'm not using.
Note I'm a relative noob to all this, so if there are better ways to accomplish these I hope those with more experience will jump in and correct me.
How would one do this? How can I map the content (if there is one) form ALBUM ARTIST to ALBUMARTIST and then remove ALBUM ARTIST entirely?
Does anybody know?
Read the Help about Actions, in particular the Format value type
When you're done moving the field values over, there's a "delete field" Action you can add to, or create your own.
Then set the Tools>Options>Tags>Mapping up as I indicated above, so any reference within MP3Tags to "ALBUM ARTIST" will actually refer to ALBUMARTIST.
Apologies for the thread hijack, but I didn't want to leave my mistakes above to mislead others - a fine example of a noob getting ahead of himself, greatly appreciate it if one who knows more corrects any further mistakes in my notes-to-myself-while-learning "corrections" below.
I just discovered by looking at my tags with other tools that show the actual tag fieldnames (see the "diffing" thread), that I'd misread the docs, and the Source field is the one that's actually written to the file. This means that for my purposes, I need to go back and reverse at least some of the mappings I posted above. Plus I need to change some that foobar2000 the tool I'm using to convert my FLACs needs to see, e.g. "CONTENT GROUP" with a space rather than not.
Obviously leaving the "shipping default" set:
"DATE" in FLAC for YEAR in ID3v2, and
"ORGANIZATION" and "TRACKNUMBER" are all canonical as per the xiph.org spec
Note that the "Target" string, as a UI alias and in effect can no longer be used as an actual field name in that format. Bottom line - the only reason to mess with mapping AFAICT is when you need to use a Target string in your MP3Tags UI, formulas etc - you then CAN'T use the Source name for that purpose, which remember is the actual physical field for the specified format - that string now becomes irrelevant and unusable.
Therefore for example it doesn't make sense to map "Album Artist" to the canonical internal ALBUMARTIST unless you only want to refer to it with the former string with the space.
And note as well that one of the pair should be the internal name in MP3Tag for the standard mappings (e.g. to ID3) to continue to work.
Question for those who know more than me: In such a case (with hard-coded internally mapped strings) it doesn't seem to be a way to force duplicate fields to be automatically written, the user must manually run Actions?
And a final comment - this is a perfect example of where it would be more user-friendly not less, to allow an option for MP3Tag itself to display the actual fieldnames rather than forcing us to use third-party tools to analyse the results of its behaviour - which BTW is most excellent but you have to get to understand what's happening under the covers.
Not criticising at all mind you, in fact I"ll take the opportunity to once again thank the devs and the supporting community here for all their hard work on this most excellent and useful project.
I've always found this confusing. I don't know why they're not labeled something more straightforward, such as 'Name in Mp3tag' and 'Actual Field', and have the columns reversed. Both changes would coincide more closely with the Help page on field mappings.
That is the case, as ALBUMARTIST maps to the commonly used TPE2 in ID3v2.
Do you mean something other than using \\ to specify a field with multiple values? These are written in vorbis comments as multiple fields having the same name. I don't quite see what the field name mappings have to do with it. Other tagging systems use different methods for storing multiple values. In ID3v2 the multiple values are stored in one field, but separated by null bytes.
I've always thought it would be great to be able to view actual field names, perhaps by a toggle in the extended tags dialog. But it would probably not be a good idea to allow them anywhere else, such as in actions. Mostly to be used as a debugging tool. Even if it were read-only, it would be useful.
Yes I didn't mean multiple instances of the same field, I meant automating the duplication of data into two different fields. For example, if I wanted to use CONTENTGROUP within MP3Tag, but for maximum compatibility also write the same string to "CONTENT GROUP" and GROUPING every time CONTENTGROUP was changed. . .
Thanks for the feedback, at least I don't feel like I'm crazy, or at least on this one little part of my life 
Not that I'm aware of, but actions are ideal for that sort of thing. The way I use Mp3tag is that I've gotten into the habit of always running a set of action groups on all files in an album after I've done any manual editing. This completely automates such tasks and I never have to worry about updating fields that depend on others. For example, filename is always based on TRACK and TITLE. So, along with a few other action groups, I always run my 'Rename File' action group after I've done any editing.