I am at a loss here. I replaced your 'do flac work' with %Album Artist%
and 'do other work' with %Band%. But with me, it does not work ...
Can you actually put that statement in the FIELD area
It doesn't work for me either. That's expected - FIELD works only with a single placeholder. I know of no solution that gives a single editable column for BAND/albumartist.
FIELD could be made to accept an expression, interpreting it as delivering a placeolder rather than the value for a placeholder. But I for one would not vote for this work, since it leaves the BAND/aa problem unfixed in many other program locations.
Ultimately, the only solution that is going to be flexible enough for practical use with
multiple-codec libraries is going to be user-definable field mappings.
Couldn't agree more!
I must say... couldn't agree less! Mp3tag already has a solution for MP3 TPE2 v. WMA AlbumArtist and a similar one for FLAC AlbumArtist would be adequate to solve the current problem.
Then you've missed the point. It's not about any single field or single tagging scheme. It's about being able to write actions which work with multiple codecs without resorting to ridiculously complex nested functions or complicated and difficult to debug multiple action groups. Just one of the problems with the current implementation is that Mp3tag interprets some field names literally and some it translates to something else, which makes things very unwieldy. The problem with your idea of starting to map FLAC tags is that it would break tens of thousands of existing action groups already in use.
The solution that I've proposed, of user-definable mappings through the use of text configuration files would change nothing for a default installation. You just recreate the existing mappings. So there's little reason to argue against adopting a flexible scheme.
Then you've missed the point. It's not about any single field or single tagging scheme.
A single field is the point of this topic and I've not seen anyone give an example of another field affected.
The problem with your idea of starting to map FLAC tags is that it would break
tens of thousands of existing action groups already in use.
You may have an idea of an idea of mine idea breaking actions, but I have made no such proposal.
The solution that I've proposed, of user-definable mappings through the use of
text configuration files would change nothing for a default installation.
Then sorry it falls well short what's neede to satisfactorily address the point of thread.
there's little reason to argue against adopting a flexible scheme.
There is much reason - development cost.
Then explain what you meant by:
Other than Mp3tag mapping its BAND to FLAC's ALBUMARTIST, I have no idea what else it could mean. You immediately run into two problems, just to start:
- How would you actually write a BAND field?
- What if you need to use 'ALBUM ARTIST' (which is used by foobar2000) in FLAC files?
Right now, you can do either one, because Mp3tag writes either field literally. Which puts us back where we began.
Then explain what you meant by:
a similar one for FLAC AlbumArtist would be adequate to solve the current problem.
E.g. this proposal
Format-independent album artist
... an Album Artist placeholder that works across all formats i.e. translates to
%BAND% on WMA and MP3 and to %ALBUMARTIST% on FLAC
Other than Mp3tag mapping its BAND to FLAC's ALBUMARTIST,
I have no idea what else it could mean.
See the above.
You immediately run into two problems, just to start:
How would you actually write a BAND field?
I suggest %band% - unchanged.
What if you need to use 'ALBUM ARTIST' (which is used by foobar2000) in FLAC files?
That is separate from the current problem. I agree that is needs consideration but better in a separate topic.
If I understand you correctly, you ask what to do if you actually want to create or read a field named "band". Right now that is not possible in MP3Tag for MP3 and WMA since they get automatically translated to TPE2. So IMHO translating this field to f.i. "ALBUM ARTIST' for FLAC would not add a new problem.
Yes I would strongly be in favor of "ALBUM ARTIST": as said, Foobar uses it, and WinAmp reads for FLACs both "ALBUMARTIST" and "ALBUM ARTIST", but when both fields are present displays primarily "ALBUM ARTIST" and writes itself any changes only to "ALBUM ARTIST".
But I agree with chrisjj that maybe this discussion could be held better in a separate topic.
As for breaking existing scripts, that could be overcome by making this particular mapping user-defined for FLACs. That would give the user a choice of working with a field named "BAND" (no mapping, existing situation), or to map it to "ALBUMARTIST" or "ALBUM ARTIST", whatever flavor one wants. Although indeed I do not know how much programming this involves.
OTOH scripts would simplify, since now scripts need extra $if-statements looking for the existence of BAND in MP3 and WMA and for ALBUM ARTIST in FLAC.
create or read a field named "band". ... IMHO translating this field to f.i. "ALBUM
ARTIST' for FLAC would not add a new problem.
Apart from the existing scripts that it broke.
As for breaking existing scripts, that could be overcome by making this particular mapping
user-defined for FLACs. That would give the user a choice...
Agreed. That is essential. Mp3tag should make no more script breakages than it has already.
Mp3tag v2.44a now supports user-defined field name mapping for the various tag types.
Wow, that is great news!
I mapped BAND to ALBUM ARTIST for VorbisComments. Using BAND in the tagpanel, mysteriously creates two fields named ALBUM ARTIST in FLACs, for MP3s it works fine. Filling in the BAND field in list-view works great. Sorry sorry, sorry to immediately point you to this one minor thing ...
Florian, you are a hero in developing this program, thanx a million !!!!
If you want to use BAND as your Album artist placeholder for all formats then you should map VorbisComment > ALBUM ARTIST > BAND
Indeed very good news.
Mapping was getting me mad.
I will make a donation is the beta is "alfa".
Thank you, Florian. This looks like it will work well.
However, it's not working as I'd expect with ID3v2 tags. My preference would be to map common vorbis comment names to ID3v2 frames. When I create a new mapping, the default is ID3v2, so I assume you intend to be able to map names in ID3v2 as well as VorbisComment.
Here are the mappings that I've defined:
When I try to set COMPILATION=1 in an Mp3 file using ID3v2.3 I still get a TXXX/COMPILATION=1 frame (a user defined TXXX frame with a description of COMPILATION and value of 1), which is what I get with no mapping. At worst, if the mapping was working I would have expected a TXXX/TCMP=1 frame, but I hope to be able to write native frames.
ID3v2 does not work on frame level
Your first ID3v2 example must be
ID3v2 > BAND > ALBUMARTIST
I don't understand. Going by the VorbisComment entries as examples, wherever in the program TRACKNUMBER is used, the actual vorbis comment field being written (and read) is TRACK. So I would expect
ID3v2 > BAND > ALBUMARTIST
to mean that wherever the field name BAND is used within the program, an ID3v2 frame of TXXX/ALBUMARTIST is written.
It's the other way around, TRACKNUMBER is written to the file, but Mp3tag displays TRACK to the user.
ID3v2 > BAND > ALBUMARTIST
means when you use ALBUMARTIST it reads from and writes to BAND (which actually is TPE2)
Ahhh, I get it now. And the source names must be Mp3tag's internal field names. So what I was trying to accomplish above is actually:
Thanx, that works flawless!
This reads from and writes to a VorbisComment with fieldname ALBUM ARTIST in the FLAC, while Mp3tag works with the placeholder %band%.
Apparently the column titles are a bit counter-intuitive, for me f.i. the Target is the audiofile. This could be overcome by changing Target to something like "Mp3tag" and Source to "Audiofile". Just a suggestion.
Florian, again a million thanx for implementing this! In another thread I pledged a contribution for solving this ALBUM ARTIST problem, so I keep my promise and just made that donation.
Great! Also thanks dano, for your splendid explanations!
I've tried to make the help topic on this feature as specific as I could (given that it was around 23:00 and I spend almost the whole day coding). I'll have a look at it again and try to improve it based on your feedback.
Thanks a lot! I must have missed this topic, but it's a nice surprise after the countless hours of thinking about and working on that feature
Suggestion: an option in the process of installing a new version - Don't change mappings. I was surprised after installation of 2.46a over 2.46 - deleted mappings were recreated.