Picard is quite happy with ID3v2.4 (options \ tags \ ID3 \ ID3v2 version…)
When you look one of your tagged files in Picard now what do you see? Are you saying these are all custom fields and nothing lines up?
The stuff that isn’t aligned now will come down to Scripting to take the database data and pop into the tags you want it to be in. And I not a scripting expert, but it is also in that same help file I linked above. (Or someone with The Knowledge will be along soon…)
What do you mean? When I load one of my pre-tagged files in without looking them up? They look like this:
Here’s what they look like when I look them up in the database and select the correct pressing:
Notice how “Record Label” still shows up even though I already had “PUBLISHER”, which I think gets auto-renamed to “Organization” in some software.
I don’t see “PUBLISHER” in your example? I’m guessing a lot of your stuff is the lower case things. Like I never seen “organization” appear before?
Something like $set(PUBLISHER, %label%) is what you are after. On the left the name of your tag (caps sensative) in the %% on the right is the name of the value you are pulling from the database. Or maybe that is “organization” instead of PUBLISHER?
But I can’t give a real answer as I don’t really hack with this stuff as I stick mostly to standard data.
The second image, the green items show the standardised tags that Picard is attempting to add. Here you see “Record Label” being where the label is supposed to go.
Notice how all your lowercase tags are still there?
So $set(labelno, %catalognumber%) would work (Yeah - just tested that… and as you add those items to the Scripting section you get an autocomplete suggestion too… So we should be able to find all the ones you need.)
Yes, PUBLISHER for whatever reason gets renamed to ‘Organization’ sometimes. It did this in the Windows File Explorer too, but I can assure you they’re still tagged as PUBLISHER! Here’s what it looks like in foobar2000:
‘Publisher’ must be some universal value. I originally got these tags from when I used to make cd images and split them with CUETools. These extra tags were mostly the default ones in CUETools, when you select a pressing and split the tracks. I’ve been doing it for so long I don’t want to switch now, as I’ve already integrated most of these fields into my custom media player skin. I also type out all of these tags in caps but sometimes they show up as lowercase.
I will try that $set() function in the scripts section, thanks. Right now I already have a $keep() function, which I disabled to make the above screenshot. We’ll see if they conflict with each other…
What confuses me is Picard is also sticking aggressively to standards. So seeing things like “organization” appear is very weird. All those tags in your files starting with lowercase letters are “odd” and not really standard.
I don’t use foobar2000 as I used I am a Winamp man. I tag with Picard and MP3TAG only now.
Your example looks like you have some kinda custom tags coming from your foobar settings. For example - where is this “artistcountry” field?
Reading your list, and your example image with those lowercase tags
PUBLISHER = label => $set(organization, %label%)
LABELNO = catalognumber => $set(labelno, %catalognumber%)
RELEASE DATE = date => $set(release date, %date%)
RELEASECOUNTRY = releasecountry => ??
RELEASETYPE = releasetype => looks like a default one to me.
MEDIA = media => Looks like another default (its the capitals I note)
“Release Country” is confusing as I only see an “artistcountry” which I don’t know what that would be? Is that UK cos Noel is a Manc? What would it be is this was a USA released CD? In normal tags you have a “Release Country” that is “UK” as it uses two initials for all countries. ISO standard.
I think you misunderstand, I’m showing you an example of an album I had already manually tagged a long time ago. I manually entered “ARTISTCOUNTRY” into my files via foobar2000 so the flag would show up in my custom skin, like so:
I didn’t bother asking about the artistcountry field because I don’t think musicbrainz stores that information
See above - I expanded my list. You can still do your own custom tags. As far as I can see you have lowercase tags which makes it easy to mimic. And yes, artist country is in the database but I don’t know how you’d look that up. It is beyond my knowledge level. I can hack solutions to your requested tags, but can’t do the lookup needed to find out that Noel is “United Kingdom”
Options, Scripting, Add new tagger script
Okay, this seems to be working so far, only I think my $keep() function needs to use my new aliases I added via the $set() function, here are a few screenshots:
A new (to me) CD that I did not tag yet:
My scripts as they currently stand:
releasecountry is a standard tag on Picard. It’s the country the specific CD was released in, not the artist’s home country. That particular CD was released for the UK
You are in the right place. But I notice you are now adding items in UPPERCASE but your example was lowercase.
Remember that apps like Picard and Foobar will often show things in their own style. This is why I showed you that initial table in the first reply… The “Record Label” that Picard shows is a different tag in all the compression formats…
So you may want to carefully check what tag your skin is actually reading. Does it want UPPER or lower case?
I have no idea how to do the lookup to ask for an artist’s country. It is in the database, but outside my knowledge level. Need to wait for Skilled person to answer that one.
It did not work 
Adding my new $set aliases to my $keep script makes them turn up blank. This is probably because Picard is disposing of the original values of label, catalognumber, etc., and then preserving the custom fields I added without looking them up.
I have no idea how one would fix this. I may have to just revert to what it was in my last post and manually delete those fields
BTW - if the $keep is to keep your current data, just go with the OPTIONS \ TAGS \ and UNTICK “Clear Existing Tags” and Picard will never remove any of your old tags.
Worked fine for me… and what is double odd is your example a post earlier shows it working.
Unfortunately I already did that. I already had it set to preserve %date%, by the way. I tried adding label and catalognumber to that list just to see if it would work, but it didn’t. Still get blank PUBLISHER, etc. fields.
Edit: and yes, I put LABELNO and all of my other custom fields into the $keep(). I see it makes the fields turn up blank, but if I don’t do that I get duplicate fields like in my above screenshot, i.e. I get the new fields AND the old default ones.
Hang on - did you say you put LABELNO, etc into the $keep? Errrr… don’t do that. Your are telling Picard to not overwrite the tags you want to set. Drop your $keep statement.
If I drop my $keep statement altogether, I’m going to get a bunch of tags I don’t want such as ‘Scripts’ and ‘Release Status’
You have just shown to yourself that if you add your tags to $keep it stops them being written. So don’t list YOUR tags in $keep.
If I don’t use a $keep then I can add any custom tags I like but just adding them to the scripts.
There is a different command to say “don’t add” something like Release Status. (I’ll see if I can work that out… hang on a sec)
Well this is odd, it seems that even if I drop my $keep() script I still get duplicate fields. For some reason, the field aliases I made with $set() have a space in the very beginning of them. Ignore that, it was just the way I wrote the script. I fixed the space but the problem still remains:
So maybe it is something else
Edit 1: do the scripts run sequentially? I’m going to try placing my $set script before the $keep
Edit 2: I think I have reached the maximum number of replies for a new user today. Thank you for the help but I cannot reply anymore until tomorrow, I guess
Edit 3:
I think I got it to work. I was right about the scripting order. I simply placed my $set script first and my $keep script last to make it happen. I didn’t end up using the $unset one:
I knew it had something to do with the sequence, and I needed the equivalent of an && operator. Looks like those Bash scripting tutorials on Youtube finally paid off 
Thanks again for your help, it’s always incredibly helpful to have multiple minds brainstorming over a problem. I appreciate that. Now to see if this is going to be a viable solution in the long run for me. I would normally just scan discogs for the correct pressing and manually enter the info from there. Maybe Picard can speed things up for me.
If you are trying to REPLACE all tags with a new set of tags, then you need something like $unset. So if you don’t want to see “Release Type” appear then $unset(Release Type)
If Release Type was already in the file, then you need to also TICK “Clear Existing Tags” as that will wipe everything and just set the tags you want to set, along with Picard default set.
And any of Picard’s defaults you don’t want, you just $unset… but $unset on its own does not delete the old data. You need to make sure “Clear Existing Tags” is ticked to give you a clean slate each time.
You also still have your confusion of CAPITALS and lowercase going on in your example…
Actually - try $delete - $delete(release type), $delete(label) etc instead… that is better what you want I think… both unset and wipes the old data. Okay… got there in the end. Need to type that in the same way it appears in the table in my second post. i.e. without any caps.
Sorry for the confusions. I am literally hacking my way through this with a basic knowledge while drinking beer 
at half past midnight. 
. The manual is written by a scripting expert who is clearly well asleep at this hour.
Yes, scripts are in order. But don’t put any of the tags you are trying to change into $keep. You are confusing things as keep keeps things as they are. So if they were blank, they stay blank.
(Why can’t I find $keep in the official manual? 
)
There’s a full $unset list here, just remove from that list the tags you do want to add/change:
“If you want to remove tags completely, instead of just not touching them, replace $unset with $delete”
I can highly recommend keeping the MBID fields, they will make life so much easier in the long term, but up to you 