If I am correct, Picard (at this moment) does not read all existing tags that are present in a loaded file and make them available for scripting.
Would it be an idea/possibilty to have a plugin that reads all tags present in a file, and make them available as a hidden tag?
E.g. if there would be a custom tag in a file named ‘subgenre’, it would become available for scripting as ‘_subgenre_file’. (or something like that)
As you might expect, it is complicated…
a. Different formats support a different subset of predefined tags.
b. Some formats support additional freeform tag names (like ID3 comments) and some don’t.
c. Picard does not currently support all tags defined by any particular format - I think I created a ticket some time ago requesting that we work out all tags supported by all formats and get Picard to know about them.
d. I also suggest that the Picard team reach out to e.g. Hydrogen Audio and other tagger / player authors (MediaMonkey, MusicBee, Foobar2000 etc.) to see if we can reach some consensus about make tags more consistent across formats - but if not to create some Picard specific ones and see if they get adopted by other taggers). This seems to be how new tags (like Replay Gain) get created - someone defines it and others adopt it and it becomes some form of standard.
e. I have a feeling we need to do something more in Picard to have an option to automatically keep or delete tags that are not populated from MB data or a plugin.
If we did the above, then tags would automatically have variable equivalents and be available for scripting.
Alternatively, perhaps the Picard team should lead by creating a vision document that creates draft definitions for all missing tags in all formats, and do the normal internet thing of sending it out as an RFC.
But I am against the idea of doing anything using external files.
I don’t understand what you mean by this? It’s not something I suggested?
With files, I mean the actual music files that get loaded into Picard.
I do agree about a lot that you are saying, but I’m thinking that what I am asking for here might be a little bit simpler than needing to align different sorts of software and reach any sort of consensus:
My thinking:
If we look at FLAC.
There is no such thing as an agreed proposal, industry standard, consensus, or any restriction on what tags are allowed or agreed on.
There is only a defined way how a tag should be written in the file, so a player/manager/tagger will know that it is a tag.
So couldn’t Picard just read all tags in a FLAC file, irrespective of their naming, and make them available as a hidden tag in a format such as ‘_tagname_file’?
It already does something like that for ID3 - some ID3 comment tags (TXXX) map to picard pre-defined tags, but those that don’t become freeform tags (i.e. visible in metadata. (There’s also some funny stuff that happens if your comment tag wants to use a tag name that is matched to a different type of ID3 tag - it becomes a hidden variable called %TXXX:name% if I remember correctly - but I may not have.)
Having comprehensive support for all formats as I described above would (in my head at least) provide the same capability for freeform tags across all formats. Which is essentially what I think you are suggesting.
And apologies for misunderstanding what you were suggesting. 
I’m not sure if it is clear now, but this feature I am suggesting exclusively pertains to reading tags.
(I for sure also have had a wish in my mind for a long time that relates to what (I think) you have brought up here.
I would love it if Picard had the possibility to create extensive customised tag mapping, so you could specify exactly how tags are read and written. Including giving full control over the capitalisation of tags)
May I ask what specific tag in what file format you have in mind? For FLAC and other files with Vorbis tags Picard already loads all tags from the file. Likewise for Ape. For ID3 all freeform tags (TXXX) get loaded as well. A similar mechanism exists for MP4, where most software stores user defined tags in the ----:com.apple.iTunes: namespace.
But are they also available for scripting?
(personally I exclusively use FLAC and MP3 (vorbis & id3v2.4)
Depends what you mean. All the tags are available with their value as shown in the new value column. What’s currently not available is the original value. So if you have a tag that gets set by the data loaded you will only be able to access that value. But if it is data that is not overwritten by MB the value from the file is directly available.
By ‘all’, you mean all tags that are in the curated lists here right:?
https://picard-docs.musicbrainz.org/en/variables/variables.html
Not all tags that may have been written by other software that are not in these lists?
(such as e.g. custom tags)
Suppose for FLAC you have a tag ‘STYLE’ in a file.
Or for idv3 TXXX/style.
Picard isn’t able to read that and make it available for scripting, is it?
If you have a tag “style” in FLAC you will have it available as %style%, likewise TXXX:foo will be available as %foo%.
Unless you have “clear existing tags” enabled, then it would be cleaned and doesn’t have a new value that would be available for scripts.
Ah yes, I gave a completely wrong example and explanation in my previous post.
Sorry for that.
The issue is actually with tags that are present in Picard’s list of approved tags.
So if you have a file that has a date for ‘original date’, you won’t be able to use that value in a script.
You can either preserve it or have it overwritten, but you can’t use the value.
So that’s why I was thinking that having all tags read from a file and making them available as a hidden tag ( _tagname_file ) might be a useful solution/feature.
Yes, in case of Picard providing data for this tag only the new data is visible.
A plugin could do this and make the original file variables available. I actually think we should add a way to have those available in Picard itself.
We need a function $original(varname) which is equivalent to %varname% except it looks it up in the original metadata instead.