BANDSORTORDER was undocumented if it was implemented previously. But PERFORMERSORTORDER was said to be mapped to TSOP. PERFORMERSORTORDER is still in the latest documentation, so I'd assume that both map to TSOP?
I always thought TSOP was intended to be an "artist" sort order, related only to the artist on the particular track, not used for the album artist. How would Mp3tag deal with seeing both an ALBUMARTISTSORTORDER and a PERFORMERSORTORDER in the same track, which would be fairly common on many compilations? Say I have a compilation put together by David Byrne:
ALBUM=Brazil Classics 2: O Samba
If that's the case, be aware of how changes like this might break existing Action groups.
These mappings need to be better documented. Perhaps that's intended before 2.40 is released, but currently the mapping help documentation is very out of synch with these changes.
I see this in the changelog, and again I'm just confused:
NEW: support for iTunes sorting fields at ID3v2.2, ID3v2.3, and ID3v2.4 (ALBUMSORTORDER, ALBUMARTISTSORTORDER, COMPOSERSORTORDER, PERFORMERSORTORDER, and TITLESORTORDER).
ALBUMSORTORDER is supposed to be TSOA according to the id3v2.4 spec, TITLESORTORDER is TSOT, and PERFORMERSORTORDER is TSOP. These aren't iTunes specific. So what exactly are the "iTunes sorting fields" for these?
If they're just the id3v2.4 standard, then does this mean that Mp3tag now writes id3v2.4 fields to both id3v2.2 and id3v2.3 tags? This would be a departure from previous behavior and would again have possible side-effects for existing Action groups.
I'll say it again (and give some hope for Mp3tag 3.0)...
With each new tag mapping, this system is becoming almost completely un-maintainable and harder and harder to document and explain exactly what's going on behind the scenes.
We really need a fully user-definable sysetem mapping Mp3tag names to fields, so that changes like this become trivial and users have a way to easily add their own fields and define the behavior across different audio file types and different tagging systems. If Mp3tag decides that 'MYLEFTFOOT' maps to 'TEY8' and that doesn't work well for my needs, then I can easily redefine it. Action groups that can modify many different types of files become trivial when the mappings can be user defined.
No longer theoretical. This did cause problems for me. I'd call it a bug.
I had both ALBUMARTIST and BAND defined in my Tag Panel. I went to update ALBUMARTIST for an album of FLAC files using the Tag Panel, but the new string wouldn't stick and I couldn't figure out why. I examined usrfields.ini and discovered why. The BAND field was changed to be mapped to ALBUMARTIST. Is it no longer possible to set BAND in FLAC tags?
I definitely won't map both tag fields to TPE2. This would introduce further confusion and I don't feel like investing my free development time for hack-fixes and workarounds that would be needed after introducing a mapping of two field names to the same ID3v2 frame.
I've mainly changed the field mapping due to constant moaning of some users who were not satisfied by the cognitive distance between the description BAND and its intention to serve as the field for album artist.
After the discussion in this topic I got a feeling of what I can expect for the final version regarding user feedback and think that I'll revert this change.
I definitely won't map both tag fields to TPE2. This would introduce further confusion
I think good documentation would avoid confusion.
I've mainly changed the field mapping due to constant moaning of some users who were not
satisfied by the cognitive distance between the description BAND and its intention to serve as
the field for album artist.
That fact is that TPE2 is a dual-use field - some people/players use it for Band and others for Album Artist and depriving the Band users to satisfy the Album Artist users was never going to be without dissent.
After the discussion in this topic I got a feeling of what I can expect for the final version
regarding user feedback and think that I'll revert this change.
I have to agree that if two names is impossible, reversion to BAND would be best
Today I ran through my music collection (5,8k files) and removed all BAND and BANDSORTORDER tags to get them replace by ALBUMARTIST and ALBUMARTISTSORTORDER.
Most of the files were FLAC, so there was no remapping like for the MP3s. And the whole thing was for the trash can.
I'm new here, so I'm not sure how important Winamp's behavior is with respect to tag usage. The current version, 5.5, uses the TPE2 tag and calls it %albumartist% when building the Winamp Media Library (ML). There is an option check box that allows Winamp to use the %artist% tag if %albumartist% is unavailable or blank. The "Album Artist" column in the ML interface is even populated from the %artist% tag if %albumartist% isn't found. If both are available and different, the default ML interface looks broken when you add media because the Artist column is displayed, but "%albumartist% is used to determine if tracks are from the same album! Easy to fix by displaying the "Album Artist" column instead of Artist, but a little confusing at first.
So, it looks like Winamp has decided that Albums should be classified by "Album Artist" rather than Artist. From reading the Winamp forums, this change happened around Winamp 5.3. The help file for Mp3tag v2.39 , C:/Program%20Files/Mp3tag/help/main_tags.html should be updated to reflect Winamp's new usage of TPE2. I guess they jumped on the WMA bandwagon!
I don't understand why you would be tagging Flac files with fields only recognized by Mp3tag. In fact, many of the Mp3tag strings, which do not get mapped in Flac tags, are meaningless. For example, the application I use most recognizes ARTISTSORT, not Mp3tag's PERFORMERSORTORDER. This is why it's such a chore to create Mp3tag Actions to tag both mp3 and Flac files - because you must use Mp3tag's specific names to get the correct id3v2 tags, but avoid the same names when tagging Flacs.
I use a lot of non standard fields but this doesn't bother me. And as far as I know FLAC and Ogg Vorbis allow free form tags, that means, when you want to add info that's not one of the basic info, you are free to specify new fields.