There are three challenges I seem to have with MusicBrainz / Picard use.
First, when handling a catalog, I don’t see how Picard handles multiple encodings. Specifically, when renaming directories, I use “Music/Encoding/Album/Track.fmt” format, so that my catalog uses encoding as top level breakout.
Second, I also need to be able to override the “Album” name to differentiate. In MusicBrainz, the album artist selection is far too verbose, and for tracks, the artist selection is problematic. So for me my directory structure is “Music/$encoding/$album/$track_title”. However, I need a way to override $album and I think also $track_title locally, say in an SQLite database … and make it sticky.
Third, it’d be really nice if the meta-model could be layered better, with a simple versioned schema for simple tools and more nuance meta-data layered over this. Perhaps what MusicBrainz needs is it’s own mimetype for a track metadata, and store this in the resource fork of these music files.
$ is a reference to a function not a variable. Variables are %variable%.
$encoding (or %encoding%) is not a standard Picard variable - I suspect you mean %_format% but there are also %encodedby% and %encodersettings%.
Using %_format% or any other track metadata in a path does have the potential downside of splitting an album if different tracks have different values for this variable.
Another issue you may face is that different formats can store different ranges of tag information.
You can always override %album% and %title% (not $track_title) by either:
A script with $set(album,new album title) or $set(title,new track title) though this will override tags as well as the file path/name.
A script with $set(_new_album,new album title) and then use %_new_album% in your file naming script instead of %album%.
In terms of making data “sticky” I am not sure what exactly you mean by sticky. Some formats (such as mp3) allow you to store arbitrary tag names, and you can access that data the next time you load the files into Picard, and this might help. But if you can explain futher what your desired use is, we can perhaps help further.
Equally, I am not sure what you mean by “layered metadata”. But the other topic you linked to already has an extensive discussion, so I am not going to address this further here.
I am not sure what the point would be of storing metadata in a resource fork - this sounds like it might be operating system dependent, and it would not be recognised by players, might not transfer when you copy the file to another device etc. etc. Metadata is stored as tags inside the music file itself rather than as sidecar files, so I am unclear what your intention is here.
I’d like a explicit track name rewrite phase, and a local cash to store them. When ever Picard refreshes from MusicBrainz, those overwrites are applied so downstream scripts use them transparently and so my local changes don’t appear as differences in the meta-data.
What I mean by local cache is a way to override various album/track properties and keep them in a local database or something. I’d like that in my personal folders so it gets backed up (~/.picard/overrides.json). In this way Picard could find them if I have to reinstall for any reason, or I could share them. Translations would also go here, for now at least.
Scripts that interest me would be to auto populate “suggestions” for these overrides, but in a local cache so I could edit them manually as needed. For example, the track names on https://musicbrainz.org/release/4ac155df-5090-4a10-bc58-e0a4eec965c1 are extremely long for file names, so one would want to select parts to shorten. It’s also listing the roles that are performing, which I’d strip, etc. These rules can be very specific by classical album. A small tool box to modify/generate/manipulate titles would be good, but it’s important to see them and sometimes do manual edits. Another example is that track artist for known soloists shouldn’t be the composer as it is in MusicBrainz, that’s a very silly convention and I don’t want my meta-data in my files to reflect this.
By resource fork, I mean meta-data attributes in FLAC, MP4 container, etc. That said, I wish there were standards/support for complex values, perhaps in JSON. The term “resource fork” comes from the old-school Apple file system, where each file had paired metadata, not as a side-car that had to be tracked separately (well, it was technically a side-car if viewed in other operating systems).
You want to manually edit certain fields in Picard and then save tags.
Next time you load those files into Picard you don’t want those manual changes overwritten by data downloaded from MB.
Exactly what you are asking for (stored externally) could probably be achieved by you writing a plugin (which YOU would have to write in Python), however you can probably achieve something like this for some file formats (i.e. those that can store arbitrary text tags) simply by using scripts.
Unfortunately there is no way I know of to run scripts before file save rather than the normal process which is after MB data download during file load. Nor is there any way to determine whether differences between old data and new data are due to changes in the data on MB or because you manually changed the field the last time it was saved. So scripting is not going to be that simple and compromises might need to need to be made.
However, my interpretation of what you are asking for / suggesting is that you don’t understand what tags are nor how they are stored in music files, nor do you understand Picard file naming scripts and how they can be used to shorten track filenames, nor do you understand Picard options to set / scripts to write so as not to store some data in tags, nor do you understand what plugins already exist for classical releases.
There are VERY GOOD reasons why MB stores classical track artists as the composer, and you are not going to change that (and making derogatory comments about this being “a very silly convention” is lacking in both knowledge and empathy), however I can understand why you might want to store the performers for track artists instead and this can be achieved in Picard by using Classical plugins and / or scripts. (Your requirements are likely not unique to you - there is a huge Picard community and if you have a requirement then probably someone somewhere else will also have had the same requirement and possibly come up with a solution.)
My advice to you is to:
Read the Picard documentation.
Read the Picard documentation again
Look at the Picard plugins.
Experiment on a copy of a subset of your music files, to see if you can work out how to achieve what you want. If you still cannot achieve it, …
Research the internet for Picard solutions to your issues.