[F] Mp3tag v2.46a - 'Album Artist' Not Correct

I just noticed today that in v2.46a in the lower left of the window pane, under 'Album Artist' that this actually makes a 'Band' tag.

There is a Album Artist tag and when looking at this window pane seeing that name, you assume it's a 'Album Artist' tag.

In this screen shot you'll see I underlined the names under red, showing you in the Metadata window the actual tag name it is given, 'Band'.

If this is suppose to be a 'Band' tag then then name in the left side window pane where you can add this in should be changed to 'Band' and not be displayed as 'Album Artist', this is not correct.

I personally use Album Artist tags and I know they are more popular to use, that is why I assumed this name in the left window pane had the correct tag to it and not 'Band'.

Filling in the 'Artist Album' in the left window pane, should now give you that tag in the metadata, show in this screenshot:


P.S. Sorry I didn't pay attention and see that this had been posted already. But as I said in the other post, this is not technically correct since there are both 'Band' & Album Artist' tags. If the window pane is going to say 'Album Artist' then it should be tagged that way, otherwise it should be changed to 'Band' in the window pane...

I agree. This doesn't make a lot of sense and at the minimum is going to cause confusion, and at worst is going to have users adding the wrong field to Flac and Ogg Vorbis files.

It's somewhat specific to Mp3/ID3v2 tagging, since it writes BAND/TPE2 to Mp3 files. That's fine, as this frame is interpreted as 'Album Artist' by most programs. The confusing part is that the label conflicts with Mp3tag's own internal field naming convention that calls it 'BAND'.

What's worse is that anyone thinking that they're tagging a Flac or Ogg Vorbis file with 'Album Artist' is going to mistakenly tag those files with a (literal) BAND field, which few programs will interpret as 'album artist'.

I think it would be best if it wasn't included in the default Tag Panel configuration. If it is kept, it should be labeled 'Band:'. Then it won't confuse people tagging Mp3s and shouldn't cause problems for those tagging Flac and Ogg Vorbis, who can either ignore or remove it.

Case in point: http://forums.slimdevices.com/showthread.p...4609#post574609

Please fix this ASAP.

I've recently been confused by this myself. My solution was to rename "Album Artist" to "Band" (to help me remember what it really means) and add custom "Album Artist" ("%ALBUM ARTIST%) and "AlbumArtist" (%ALBUMARTIST%) fields and columns, and make their contents all the same when editing metadata. Does anyone perceive any harm to come from this? (I also renamed "Artist" to "Track Artist" to help me keep it all straight. It's a lot of "Artists".)

Well does anyone that works on this project reply to these posts so we know someone has read this and will fix it?


P.S. Doesn't look nice when someone takes the time to report something and there's no reply almost 6 weeks later. :frowning:

The problem with this issue is that I'm not entirely sure how to fix it. There are two perspectives and each of them are valid.

The VorbisComment/APEv2 user wants the label of the Tag Panel field match the actual field that is written to the tag. Storing a BAND field doesn't help at all and I can confirm that this undesired behavior in most cases.

The MP3 user wants Mp3tag to store the value in a frame that is readable by other popular software. Unfortunately, there is a big semantic gap between the field name BAND and the actual intention to store the album artist in the frame. That's why changing the Tag Panel label doesn't help much.

So, the only solution that fits for both perspectives is to remove the album artist field from the default configuration.

What do you think?

P.S. I really appreciate your bug report. Unfortunately, my free time is limited and I have a lot on my plate in real life currently.

Yes, I think that would be best.

Long term thoughts: This would be a major change, so would only be appropriate for a major release, as in Mp3tag 3.0. But have you ever given any thoughts to changing Mp3tag's default field names?

My take on it would be to use names now commonly used in VorbisComments to tag Ogg and Flac files. These would then require minimal or no mapping in VorbisComments, and no odd gyrations required when using Mp3tag to tag different file formats.


Even the fields invented by iTunes have simple counterparts:


There is, but I don't see the problem. TPE2 is used universally as ALBUMARTIST now. De facto standards are far more important than some ancient ID3v2 spec put together by some random people. The ALBUMARTIST/BAND thing could finally be put to rest by using ALBUMARTIST.

ALBUMARTIST instead of BAND (and mapped to TPE2)

Many thanks for your feedback.

I really like the idea, and although it would break any existing format strings and export configurations, it would improve the situation significantly in the long run.

Kind regards

Just one additional question, is there any (semi-)official specification that contains the field names you're proposing (e.g., ALBUMARTIST, ARTISTSORT, ...)?

If not, is there any other source of information?

I've renamed BAND to ALBUMARTIST with the current Development Build Mp3tag v2.46d along with some other field name changes:

Just to make sure I understand this right:

BAND was changed to ALBUMARTIST at the tag panel and at the file list? Anywhere else?

Since I have set more custom field in the tag panel and custom columns in the file view list for time time now, I don't remember if it was always there. I thought I had set it up myself. But after reading this thread, I think it's a custom field which was there be default and there had been a little naming confusion, right?

Not affected by this change are all the saved functions and actions where I had used the %band% tag a lot for renaming folders and converting directory name into tags, right?

When I want everything like before, I just have to set the value of the tag panel field and the column back to BAND / %band% , right?

When I used WinAmp, I had all my files tagged whith BAND
When I switched to Foobar, I added ALBUM ARTIST (with a space), because BAND was not supported by Foobar.
I'm confused at this point, testing right now, it seems that:
Winamp supports ALBUMARTIST and ALBUM ARTIST, but not BAND.
Foobar supports ALBUMARTIST and BAND, but not ALBUM ARTIST.
So the two players treat ALBUM ARTIST and BAND the other way around from how I thought. Am I confusing things and remembering wrong, or has this change something to do with the change for mp3tags behaviour right now?

So at this point, it seems best for me to abadone the ALBUM ARTIST and BAND tag completly and change everything to ALBUMARTIST.
Are there any media players which don't supporst ALBUMARTIST?
From the ones i have installed, i can say the following behaviour:

Supported Tags:
Foobar 2000 [v]: ALBUMARTIST, BAND (if both, they are displayed as multivalue tag)
WinAmp [v 5.581]: ALBUMARTIST, ALBUM ARTIST (if both, ALBUMARTIST is displayed)
iTunes [v]: ALBUMARTIST, BAND (if both, ALBUMARTIST is displayed)
Windows Media Player [v 11.0.6002.18311): ALBUMARTIST
VLC Media Player [v 1.1.4]: ALBUM ARTIST, BAND (if both, both are displayed seperately, only viewable at file information)

So it seems ALBUMARTIST is indeed standard now. Can anybody report from other players?

No, the default internal album artist tags of different file formats used to be displayed as BAND in Mp3tag. This has now changed to ALBUMARTIST. (BAND was renamed to ALBUMARTIST)
I guess this means you must also change your actions.

foobar2000 supports like Mp3tag almost any tag, but in its default setup it favors
ALBUM ARTIST at mp3, flac
ALBUMARTIST at wma, mp4 (displays as ALBUM ARTIST in foobar)

You can see in the Mp3tag manual what ALBUMARTIST actually means for each tagging format.

I am very worried by this change that has gone into 2.46d.

TPE2 should not be ALBUM ARTIST. The standard is that it represents BAND/ORCHESTRA. There are applications that honour this spec; Squeezebox Server and Foobar, for example (although SBS has an option to interpret TPE2 as Album Artist instead of Band).

These apps instead read a custom id3 tag TXXX ALBUM ARTIST.

With Mp3Tag pre 2.46d, I could write to the custom tag "ALBUM ARTIST" and ALSO have a BAND tag, and get the correct desired result with flac vorbis and id3 tags.

I think this is really going to confuse a lot of users upgrading Mp3Tag, unless I mis-understand the effect it is going to have. I'm sticking with 2.46c for now.

Will the Mp3Tag upgrade affect my currrent configuration, or is this only for new users? i.e. will writing to BAND now create a custom tag "BAND"? Will writing to a custom tag "ALBUM ARTIST" now actually write to BAND (TPE2)?

I think removing the Album Artist/Band from the default configuration may be a good idea if you think it's confusing, but to change the meaning of the field which breaks the id3 standard, especially in a point release, is a very bad idea.

This is also a bit wrong.

ITUNESCOMPILATION relates to an id3 tag that isn't official (Apple made it up), called TCMP. A lot of other software doesn't understand that frame, and they use a custom tag "TXXX COMPILATION".

To rename ITUNESCOMPILATION (which I thought was quite good, as it highlights the very-specific frame created by Apple for ITunes) to become COMPILATION, may break/confuse people who have set up a custom tag called COMPILATION.

Is it still possible to write to a TXXX COMPILATION tag, or would this map to the invalid TCMP frame?

just to make sure I get this right:

Not BAND was renamed to ALBUMARTIST
but TPE2 was remapped from BAND to ALBUMARTIST

old files which had been tagged with a BAND tag have now a ALBUMARTIST tag, because it is and was TPE2.
(how do you call it, TPE2-field, TPE2-tag?)

i think this needs a update, because it still states BAND as TPE2: http://help.mp3tag.de/main_tags.html

to what is BAND mapped now?
to what is ALBUM ARTIST mapped now?

do i see this right:
almost all web sources scripts need a update now, because if their output commands have also been remapped.

TPE2 is an id3v2 "frame", which is used for holding BAND/ORCHESTRA, and sometimes abused by iffy software for representing Album Artist.

As I understand it (haven't tried new beta version yet), Mp3Tag now associates an Album Artist data entry field to TPE2. This used to be Band, and thus Band is no longer associated to an id3v2 frame.

i.e. anyone opening files in this new version would see their "Band" content appear within "Album Artist", and Band would be blank.

So where I have a compilation album with a track containing:
ARTIST=Robert Fripp
ARTIST=Brian Eno
BAND=Fripp & Eno
ALBUM ARTIST=Various Artists

The Album Artist would now be reported as Fripp & Eno, and Band would be blank.

It was a good idea just to release a "only name change develop test version 2.46d", so it can be easily turned back to the prior state.

With Mp3tag 2.46d my files have suddenly three tag-fields relating to AlbumArtist.
One tag-field "ALBUM ARTIST" and a multi(2)-value tag-field "ALBUMARTIST".
What should I do with these tag-fields now?

The list view's column dialog still has the column header "Band", but anyway behind the scenes, there was a change of the column value.
I am quite sure, that I did not write this expression by myself.

Hmm, Mp3tag 2.46d makes me insecure, which path has now been taken.


I respectfully disagree that the change is wrong or confusing. I think mapping COMPILATION to TCMP eliminates confusion and simplifies compatibility with key applications like iTunes and dBpoweramp.

I am also interested to know in general if Mp3Tag has the ability to write to specific frames by frame name instead of just Mp3tag field names. I don't think this capability currently exists, but if added in the future, it would add significant flexibility for those who want to map to frames and tag names any way they choose.

I edited the quote from your original post to focus on what I can comment on:

Foobar supports BAND in the sense that Foobar reads and writes BAND to the TPE2 frame. Foobar will populate its ALBUM ARTIST field with the data it finds in a TXXX frame described as Album Artist.

For scripts things are trickier, since per http://wiki.hydrogenaudio.org/index.php?ti....2CaN.2Celse.29, Foobar will populate Foobar's %album artist% value based on what it finds in the following metadata fields, in this order: "album artist", "artist", "composer", "performer".

Based on the above and what other applications do, I think the change to drop BAND and write ALBUMARTIST to TPE2 maximizes compatibility across iTunes, dBpoweramp, Foobar.
I can't comment on other applications. For any application that reads and writes to TPE2, there is no universal standard for associating a tag name, but all seem to use either ALBUMARTIST or ALBUM ARTIST with the exception of Foobar, so using either ALBUM ARTIST or ALBUMARTIST for TPE2 seems the best fit. Since Foobar will loook for a TXXX frame described as ALBUM ARTIST for its field of the same name, then assigning ALBUMARTIST to TPE2 and ALBUM ARTIST to a TXXX frame seems the best alternative. Lastly, Vorbis Comments uses ALBUMARTIST, which further aligns with assigning ALBUMARTIST to TPE2.

I like the mapping assignments announced in 46d.

I think that ITUNESCOMPILATION more clearly shows support for iTunes Compilation tag than COMPILATION does, seeing that it is an iTunes-specific id3 frame that not may other apps can read (id3 tag library API's used by a lot of software don't support it), let alone are written to understand.

If TCMP were a standard tag, and anything else in addition to iTunes used it, then I'd agree.

i.e. if some software instead looks for a custom tag (TXXX frame) COMPILATION tag, then what would that be called?

What does Mp3Tag do for non-id3 tags? If I want to write COMPILATION=1 for a Vorbis tag, does the Mp3Tag field called Compilation write to that tag?

All of these issues are just complicated by the fact that id3 is such a poor "standard", and different apps have used different tags/custom tags. One solution does not fit all, and therefore customisable/mapping is necessary.