As the title says. Doesn't work in v3.29b nor v3.30 for me, i.e. nothing happens.
(I would think that this isn't a safety precaution to avoid splitting the wrong fields? Since _ALL is present in the default field listing for this action.)
Can you please show us a screenshot to see how you use this type of Action?
Have you checked Alt + T to see if multiple fields with the same name have been created?
BTW: The Action "Split field by separator" does not work for _FILENAME (included in _ALL), because it only splits the content of tag fields by separator, not a filename (nor a directory name).
Special Fields
_TAGcovers all tag fields_FILENAMEdenotes the file name of the file_DIRECTORYdenotes the parent directory of the file_ALLcontains both_TAGand_FILENAME(not_DIRECTORY)
I think that this is problem.
The semicolon-separated list of artists and composers should be split with _ALL - but it doesn't. Still, _ALL can be selected.
The description of the function says it splits
a tag field into multiple separate tag fields
which I read in this context as "not of all but only a single selected one".
But you are right: _ALL appears in the list of possible fields.
Exactly. But I'm still not sure if this is a bug or by design, since _ALL can be selected from the dropdown listing. But since _TAG doesn't work either, perhaps it's all by design.
It would be so much easier to use _ALL (or _TAG) since as it is now you need to setup many separate actions to split all the fields. And I'm sure it's possible to find a rare enough separator character to avoid accidental splittings.
Yes, it would be easier but still much more dangerous.
In my example (that I just made up) the artists and composers are separated by semicolon - and that also happens to be the standard separator e.g. for INVOLVEDPEOPLE. COMMENT also frequently has a semicolon somewhere, just like UNSYNCEDLYRICS.
I would prefer a function that I can call only for a dedicated field.
And, TBH, _ALL is not even a real field reference but a pseudo field to address all fields.
Other frequent separators like /, | or even , will cause problems in other fields, e.g. for TRACK with 1/3, the language token separator in UNSYNCEDLYRICS or POPULARIMETER.
So the pitfalls are everywhere.
I think that for this function _ALL should be removed like any other variable starting with the underscore _.
2 Likes
+1 
I would even go one step further and not allow _TAG or _FILENAME or _DIRECTORY or _ALL for this kind of Action. The (mostly negative) side effects are unpredictable and remain undetected at first glance.
1 Like
You can do that already if and when you prefer. And if you don't like _ALL or _TAG at all don't use them. For me they can be extremely useful in some cases.
How much you need _ALL (or _TAG) with e.g. "Split field by separator" depends on the use case. A little background:
I was inspired by this recent thread where the $list function was mentioned (by ohrenkino actually ). I started to build two action groups for export and subsequent import of tags. But since the $list function separates multiple field values with , (comma + space), problems arise when importing the tags back - i.e. when the values themselves also has commas, it's impossible to import them back as multiples correctly without a workaround. The solution was to merge all multiples with a special character before using the $list function, and afterwards split them back by the same character.
The merging with the action "Merge duplicate fields" could be done by using _ALL. But the action "Split field by separator" cannot utilise _ALL from the listing, hence my bug report here. Bug or not, it would help a lot if _ALL or _TAG could be used so you wouldn't need to create separate actions for splitting each and every field, when so many of them are considered for splitting.
By the way, pitfalls are easily avoided in this case by using a very unique character as a separator. One shouldn't use the common separators you mentioned of course.
Come to think of it, an alternative solution would be if one could specify the multiples separator for the $list function. The comma isn't ideal as a separator if there are commas in the values themselves.
Anyway, my point is that "Split field by separator" has many use cases, some of which would benefit a lot from _ALL or _TAG.
You can already define parts of the $list() output - see the documentation:
With $list you cannot define a separator for multiple values of a field, it is fixed as ,
But you can define prefix/suffix.
It's intended to work for _ALL, so I regard this as a valid bug report. Thanks for reporting!
I appreciate the cautionary notes about potential side effects. Ultimately, it's up to the user to decide in that case.
Will this "_ALL" work like the "_ALL" in an action of the type "Replace"?
If so, it will also effect _FILENAME.
I wonder how a file with several filenames will look like or what the filename will look like if it is split to a first part and a leftover - does that leftover then disappear?
I think there are some fields like InvolvedPeople (IPLS) that should be in a tag only once (if I read the ID3 spec correctly) - wouldn't these also get split (accidentally)?
For this action, handling the filename obviously doesn't make sense. That's why I don't differentiate between _ALL and _TAG here, but I only wanted to offer _ALL (for "all fields") in the list. _TAG can still be entered, it has the same effect, but listing it separately would only cause confusion.
By the way, this is also how it's handled with actions of type Merge Duplicate Fields.
I don't enforce these rules in Mp3tag (you can also enter multiple of those via extended tags), so yes — this would also be split.
1 Like
In valid files it is fairly unlikely to have more than 1 filename - so nothing would be merged.
As a compromise - would a different (new) pseudo-variable help to make it clear that this _ALL is different from other _ALLs? E.g. _ALLFIELDS.
I do see the easier use with an encompassing variable. I would prefer a naming scheme that makes the differences transparent.
I see your point and I understand that it might be confusing for someone who has already internalised that _ALL includes _FILENAME in other places (which seems to be the case for you).
I don't want to introduce yet another special field name and I don't think that it's necessary. However, I'll most likely change this to _TAG, which is already used as special field covering all tag fields (at least where this distinction makes sense, c.f. action Replace).
Never expected this to be so controversial. I think I let me be drawn to use _ALL for these two action types, because it's the most natural word for "all tag fields" and, thus, probably the most intuitive to understand for the user.
If you change the default listing to only include _TAG I think that _ALL should still be a working option. There could be users with action groups setup like that already.
Yes, I already thought of that. Will do so.
TBH, so far I went "by the book" i.e. the documentation which does not mention the special fields for this action. So I was flummoxed to see _ALL at all for the action to split fields.
I found it far too dangerous to meddle with anything but a dedicated field esp. as the required unique separators were hardly ever unique in and for other fields.
So I thought it was only correct to address 1 field at a time esp. as it does not make sense for some fields to split them.
Your reply seems to refer only to the "controversial" bit: to clarify, I was referring to the choice of field name, not the fact that applying this to all fields might have unintended effects.
I've just released Mp3tag v3.30a, which now supports _TAG to apply the action to all fields.
Please use with caution when applying the action to all tag fields at once. It might match fields you hadn't initially considered (as @ohrenkino and @LyricsLover rightfully pointed out above).
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.