Original title for tag mapping, plugin/hook question

Tags: #<Tag:0x00007f31ca346040> #<Tag:0x00007f31ca345f28> #<Tag:0x00007f31ca345e10>

Hi,

I want to keep certain values of the original title if they are there.
So what I did was to write a plugin with file_post_addition_to_track_processor hook and had a look at file.original_metadata[“title”] which contains what I want. I then transferred this information/appended it to track.metadata[“title”].
All fine, in Picard the track metadata in the right upper screen then displays the “extended” title. But the thing is, because this hook runs after the metadata processors the real metadata[“title”]/title is unchanged.in the tags.
I did not find out how I can get Picard to use the tags from track.metadata, or how this is even possible if the hook runs after this processing is done. I am sure this is just a small thing I miss here

Or is this not possible at all at the current state? Then I would have to derive it from the accessible ~filename variable, which is much more cumbersome

Can someone help me on this please, thanks

I don’t know if this is the best way to handle it right now but for the moment I solved it via register_file_post_load_processor hook in the plugin, wrote the original title into a ~ variable and then accessed this variable via script directly in picard. At least this works, the thing is that the files have to be loaded before of course. But in my use case this should always be so.

I saw somewhere here the idea to make all the original tags available via a $original() function. This would be a great addition to Picard. The handling in this direction is lacking at some points although it is a great tagging program

You need to update file.metadata as well. That’s because this hook, as you already said, runs after the track metadata has already been applied to the file. But that actually allows you to have fine control over which data to set for the file, and you can even access the original metadata from the file via file.orig_metadata.

3 Likes

Damn, I knew it was something small. Thanks for that, will try it out later and get back if there’s something not working. It will save the workaround over a ~ variable which is odd if you are writing a plugin already :slight_smile:

Of course this works like a charm with the one line added :slight_smile: That makes life so much easier now as I have the full powers of python available and don’t have to mess around with temp variables and scripting inside of the app then. Thanks again

1 Like