Hi all, My Billie Holiday collection (among others) was so sad and blue at being tagged as being from 2000’s (the collection release dates), so I made a Picard plugin for tagging files with the original recording date. This is the first version I put together this evening, so I’m interested in hearing about any issues or suggestions.
If you try it out and have a file it doesn’t work for (either gives an error, or doesn’t do what you’d want it to), please give the musicbrainz link to the recording and what you think it should do instead.
If you make use of this for scripting, please let me know what you found useful.
Plugin development feedback
I’m not actually sure what tag name I should be using for “original recording date”… does anyone know of a standard tag name for that? Are there any music player apps that support that?
Scripters: Is there a better naming scheme I should use for naming all the scripting variables?
Plugin developers: currently I’m making an additional webservice request for every track – is there a good way to batch those up somehow?
recordingdate: Will be the first non-empty value of the following scripting variables (defined below) %_work:forward:performance:last%, %_event:backward:recorded_at%, %_place:backward:recorded_at%, %_area:backward:recorded_in%
The extra stuff seems like it could be useful in some cases, but does it really not fallback on %_recording_firstreleasedate%?
For my own use, I’m planning to keep “recording date” and “(first) release date” as separate things. But I do want to collect some ideas on what configuration options the plugin could have. So maybe fall back to “recording’s first release date” could be a good option to have? Is that a common thing folks will want?
yindesu, in your case, are you wanting to tag files with just a single date, or multiple dates? What’s your ideal logic for which dates to keep and use as tags?
I think that’s true. I added them originally just so I could see all the data from the API and figure out what to do with it. I think the only place forward/backward would matter is for recording-to-recording relationships.
Also the API only returns the forward name of the relationship (“performance” for work → recording), so I guess I’d have to fetch additional details about the relationship types to get the backwards name (“performance of” for recording → work). I think I agree that getting that extra info to simplify the relationship names for the script variables would be good.
I’ve been using “last” to get the later date to handle cases where only one of the begin and end dates is filled in and the other is not set. I wanted to provide “begin” and “end” for use in more advanced scripts, and I didn’t feel right having “begin” fallback to the end date if it was blank, since “begin” and “end” have specific meanings in the MusicBrainz schema.
I was thinking that maybe “earliest” and “latest” would be better names than “first” and “last”? Or maybe the begin/end/earliest/latest variables should just be just for advanced scripts, and a %_work:performance_of% variable could be for basic use that would be the same as the “latest” variable?
Yeah, that’s a good point. I didn’t decide how to handle multiple relationships of the same type yet. In version 0.1.0 you’ll just arbitrarily get the values for one of the relationships of that type.
Do you (or anyone else) have a link to an example recording that has multiple works with different performance dates so we can consider that w/r to what makes sense?
For improving this, I was thinking:
“first” (or “earliest”) and “last” (or “latest”) would be the earliest and latest dates across all relationships of that type
“begin” and “end” should I guess be blank
How do other plugins provides variables for multiple relationships for scripts? I think I’ve seen something like %_artists_1_name%, %_artists_2_name%, etc?
for scripts, maybe have an additional %_work:performance_of:multiple% variable that’s set in this case?
So to summarize that would be:
Basic use
%_work:performance_of%
%_place:recorded_at%
etc…
More advanced use
%_work:performance_of:earliest%
%_work:performance_of:latest%
If there is only one work:performance_of relationship:
%_work:performance_of:begin%
%_work:performance_of:end%
If there are more than one work:performance_of relationship:
This plugin looks like it will be useful for me! Thanks for writing it. I tried it out and I’m not sure if it is working as it should…Please let me know what you think…
I think I loaded the plug-in correctly as I compared results with and without it loaded.
I’m using another plug-in ‘view script variables’ to look at the variables. The tag variable ‘recordingdate’ is not set when the script is not enabled and it is set when the script is enabled…So I’m assuming it is running automatically.
Some questions / comments on the variables that are set:
_recording_firstreleasedate = 1972-11-25. This is the release date of the single. The album release date is 1972-11.
_primaryreleasetype = album. Shouldn’t this be consistent with the recording_firstreleasedate and be ‘single’?
The recordingdate variable = 1972-10, but the song and the album are shown as from 1972-09 until 1972-10. I think this is incorrect. It should be 1972-9. This value is in _place:backward:recorded_at:begin.
I also want to get the original release tagged in my files. So for this specific track, while my file is from a compilation on CD, the song was first released on vinyl as a 45rpm single several days ahead of the vinyl album that it was also on. Any thoughts to extend your plug-in?
This variable has nothing to do with the plugin, that variable is provided by Picard. The value for it is provided by MusicBrainz and is the earliest release date of all the releases the recording appears on, whereas 1972 < 1972-11 < 1972-11-25.
Again this has nothing to do with the plugin, it is the primary release type of the loaded release. All the release data, like album title and album artist, are from the release you tag against. If you want all release data from the single load the single instead and tag the file against that.
Setting the release type to single would make only sense if all the release level tags would be the single tags. Saying album is the album’s title and its type is “single” is wrong because it isn’t.
IF you actually want all the release related tags to come from the single the proper way would be to tag the file against the single instead of the album
Just wanted to note that this is one of the examples why providing this single “recording date” for Picard is not as easy. The date as it is used by the recording is definitely not “incorrect”, but of course there can be different opinions on which date to use. If you look at the discussion at PICARD-2094 you can see that others explicitly preferred the end date, while in the ticket description I proposed the first date. That’s exactly one of the reasons why the most likely outcome will be that Picard will provide variables (similar to how this plugin does it) that help users to use scripting to set the date as they see fit.
I think currently you can’t get around this with the plugin. I haven’t checked it yet, but if Picard would do it it could probably add the required inc parameter already to the initial request and probably have the relevant data available then.
I’m now thinking that a single date is the overall problem, probably driven by existing tag definitions like id3… and it’s not possible to accurately represent the track as stored in MB, which does have two dates/times.
Yes. It’s one of the general challenges that the tagging formats are all rather simple structured lists of tag names and values, Often multiple values, but sometimes also limited to just one (either for unchangeable technical reasons of the format, or just due to interoperability with other tools that don’t expect more than one value). MusicBrainz on the other side provides a rather complex database schema that can handle all kinds of complex relationships*.
That makes it a bit challenging to bring all the data provided by MB into Picard. And an additional challenge is to make this data available inside the file’s tags in a way that it can be used in other software in any meaningful way.
*) And the reality is then even more complex, because reality in general doesn’t care about your database scheme or about being logical and structured
yes, in reality I expect a lot of tracks are recorded over a number of days. The exception might be older recordings and perhaps live recordings, but even those often range over days
I’ve seen some releases where the vocals are recorded months apart from the guitars. Drums laid down at a different time. A date can get quite complex.
When Roger Waters did the Wall gigs he was duetting with his 1980s self… These musicians do this just to wind up the database programmers.
What we really need is a Media Player that can mine the MB data. If the digital file has the Recording MBID, Release MBID, etc then the player could dive into the database online in a more flexible way.
I’m kinda hoping KODI will expand more in this direction.
These musicians do this just to wind up the database programmers.