Is there any exception to the virtual Field _ALL?

Is it possible to use _ALL in an action but allow for a particular field exception?

I want to use MixedCase, but not on fields which have (or might have) URLs links, because those might got broken. By the way, for the ones who might not know it, in a DNS link all characters after the the domain, are case sensitive.

Having to have a different action for each field (about 10) and repeat about 6 to 10 commands in each action is very labour intense, and it would be a nightmare to maintain. :frowning:

Please let me know if you know a way around this.

It should be possible to use _ALL to get the mixed case and then apply a $lower function in an action of the type "Format value" on the fields that should not be treated. This would then be the list of exceptions.



This would not address the case sensitive issue, unless you knew that the original string was always all lower case, which is unlikely for all URLs. Once you've changed the case of some letters, you cannot be sure of restoring them to their original values.

To the OP:

I don't think there's a simple workaround. There will be instances where you must create action groups consisting of the same action applied to multiple fields. They can be a little labor intensive to create (although Mp3tag's ability to duplicate actions and action groups makes it fairly painless), but most often these tend to be the sort of basic actions that require little maintenance, so don't expect many 'nightmares' down the line.

Personally, I can think of a lot of different fields that I wouldn't want to apply a blanket mixed-case operation upon.

Thank you very much DetlevD!
I didn't know about this. How useful!
However I needed even a bit more; I needed to avoid another field, like COMMENT where people (like myself) sometimes put an URL, and that was precisely what I was trying to avoid.
However I just found out about a new field that is used by Mp3Tag and MusicBee (my Music Manager) for that purpose.
It's the WWWAUDIOSOURCE (for mp3) and "ORIGIN WEBSITE" for FLAC/Vorbis (which I already mapped to the former one).

So now I will have to avoid this other field too. I think I will have to do it field by field. :frowning:
However I just rememberedd something common in programming: use a temporary variable to store a value, and then restore it.
This way I could save the original values of those two fields before changing them with _TAG, and after that restore them.

But, is this possible?
I'm afraid Mp3Tag does not support it, but if you know some trick or method, please let me know. I really need this to avoid doing some 10 fields manually. :frowning:

Thank you JJ Johnson. That's exactly it. I couldn't have said it better myself. :slight_smile:

My problem is that in this case there is a lot of trying and experimentation, and therefore maintenance. Besides, this will always be an Action open to further development, so having several repeated fields may become a nightmare. :frowning:
But I see your point. It's only once... but only after you get it definitely right! :slight_smile:

I completely agree with you that some fields should not be touched by the changes, and that is why I needed the exception, and also the reason why, in the end, I will prefer doing some 10 fields manually than using the _ALL or _TAG pseudo-tags.

I would call that development, not maintenance. Do your development with a single field. Once you've gotten it right, duplicate the action for the other fields. If you ever have to change the behavior, do the same thing.

Yes, you're right.
That's exactly what I actually do. :wink:
But surely it would be better if one just had to change one thing only... That's just what I was talking about. But this is not critical of course.