earliest release year

[hiccup]

This MusicBee forum is one of the exceptions on the internet where it's as good and friendly as the software itself...
Glad I found it, and will pas it on every chance I get  

Please don't share this treasure with any lazy or not-so-well-behaved acquaintances.
To be honest, The Hive usually treats those far less kind ;-)

[Tony_D]

Yup, that's why i never asked at the Picard forum, I will be a duck in hunting season  
I saw your name there before and the answers from the advanced forum users were a bit slippery i thought.

O.k. Hope fully you won't shoot me down now because i still need to ask you something.
Looking at the image below you can see 3 arrows and 2 different year entries....



I have no idea what the difference is between the ORIGINALYEAR & ORIGYEAR but the year field at the bottom is not reflecting the earliest (oldest) year.
I do understand the the particular song is a remaster of the original 12 inch.
The original song (was written in 1971 for a musical) and sung in 1989 by Liza herself.
You see my issue here, I'm after the 1989 date but I certainly can't use the 2021 that Picard is giving me
So still much manual labor in checking many songs, but it save me half the work already, and that's a good thing.



O.K. enough confusion now... Question;
Looking at the Metadata in the image above, did i edit something wrong in your last script addition that the YEAR = 2021 and not 2016 ?

Tony D

[hiccup]

Yup, that's why i never asked at the Picard forum, I will be a duck in hunting season  
I saw your name there before and the answers from the advanced forum users were a bit slippery i thought.

To be honest about that, my beef with that forum is/was predominantly that 2 or 3 people with some 'forum power' have all characteristics, behaviour and deceptive tactics of 'social warrior activists'. Of which I am completely allergic to.

The guys who are doing the actual work on MusicBrainz' database and Picard are great.
People such as outsidecontext and RDSwift are gems, and are always extremely helpful, understanding and knowledgeable.
I would be very surprised if you would indeed get nasty or condescending responses if you ask for help on this kind of stuff on their forum.

Looking at the Metadata in the image above, did i edit something wrong in your last script addition that the YEAR = 2021 and not 2016 ?

Are you also using my 'Tag mapping' script?
At a quick glance, there may be some conflict happening using both that one, and this 'earliest year' script.

So I may need to go back to the drawing board for both scripts.
It's best not to invest time in using these scripts together until I have figured things out and reported back.
(which is not going to be today)

PS
If you get bored in the mean time, this could be an interesting read concerning variations of original year, original date, origyear, etc.:
Tag Mapping: MusicBee, mp3tag, Picard

And for understanding how the script makes use of the Recording Date plugin, you can find some reading material here.

[Tony_D]

Had a bad rest last night, my data is still wrong

I have re-read all the steps in this thread and something bothered me so I went on investigation and watched some video's regarding Picard.
I came to the conclusion that I missed one step and that is activating the 'recording date', have missed that, noob mistake, apologies for that.



It's done now, but luckily that I didn't waste your time with that as after further testing on the same test CD's from earlier it doesn't give a single year that is more accurate of different (in my case) so I guess I leave that plug-n of as it increases querying time more then 10x

Below here I want to share with you the latest amendments that i made according to your earlier post to delete 1 line and 1 line.
I start to doubt myself in everything now so before you (eventually) continue please check what i have done as I don't want to lead you on a wild goose chase, there is enough time in the world, but it is precious...



Take your time, I'm not posting here now to rush you (just additional info)
I have been (as explained earlier) been having a love / hate relationship with Picard since many years, I will leave it installed this time around as You have come a long way towards the end of the tunnel
I will not give up if it takes some more weeks, months or years, I'm persistent, it took me more than 10 years to find MusicBee, only now I am at piece with digital music playback, haven't touched my large vinyl collection in quite a while, dust is building on op my Technics

(I will do some more reading to educate myself but I'm afraid it will be a long road ahead...)

Tony D.

[hiccup]

…as after further testing on the same test CD's from earlier it doesn't give a single year that is more accurate of different (in my case) so I guess I leave that plug-n of as it increases querying time more then 10x

That's odd. With my testing (CD1), without the plugin activated 10 songs are tagged to be in the 50's, and with the plugin it increases to 13.
Not a giant improvement, but still.
The slow down when using the plugin is indeed substantial. Especially for compilation albums.

I have slightly modified the earliest year script in this post.

To get the regular 'date' (MusicBee's 'Year') written with Picard's 'original year', add the following line to the bottom of the script.
(or create a separate script for it)

Code

$set(date,$if(%_originalyear%,%_originalyear%,%originalyear%))

Let me know if there is still something not working well?

PS
When using the Tag Inspector to check date/year values, be aware that you may see tags or values that were not written the last time you used Picard on them.
They can be older tags that were written before that, and were not deleted or overwritten later.

[ewan]

A very good topic for discussion has arisen. I use three types of dates in my library: release date, original release date, original recording date (this information is very useful for various compilations or soundtracks, as well as for bonus tracks that were later included in the release). But one of the drawbacks of Picard is that the songs are not always interconnected with the releases they contain (for example, in the case of the Elvis Presley box set, which includes the entire remastered discography). It can also be problematic when the original release/recording date is returned from a bootleg, information about these releases is of course important, but not for calculating the original date, since for example a bootleg may contain unreleased material, but the label/artist may later officially publish it.

[Tony_D]

My view on the matter is that as long Picard is album based and no toggle (to put it simply) to be able to switch to track priority, it will never be at its full potential.
The Idea of Musicbrainz (and their other projects) is actually amazing, too bad no else had made an Picard alternative.
Beets seems to be heaps better in many ways (hearsay), I'm windows user, and command line also scares me ....

Picard is in many ways similar to Musicbee, it can't please everyone but I'm sure happy it's around, and I found it (Musicbee that is )

Tony D.

[psychoadept]

Picard is limited by a couple of major things which make using it for single tracks much more challenging than whole albums.

One is the nature of the data in the database, which is always in a bit of a tug-of-war between accuracy and usefulness. Because MusicBrainz adheres to the principle that no data is better than bad data, many recordings (especially from generic, poorly-documented compilations) exist in multiplicity. It's a combination of some users who add the data not knowing how to link existing recordings on album creation and users who might link them later being hesitant to merge recordings without hard proof that they're The Same. (And also someone just needing to take the time to enter the edit and wait the week for it to pass - or not. I put a lot of my editing energy into merging recordings, but I usually stick to relatively niche artists where it's a little simpler than, say, Patsy Cline, whose recordings can be impossible to positively ID without having the item in hand.)

Hiccup's inclusion of work data is a good workaround because works can be linked to any version of a song, any recording. It's usually a quick thing to add a missing work, too, especially with some of the userscripts out there.

The other issue with Picard and tracks is the search engine and search parameters, which run into trouble with the sheer amount of data and trying to match potentially incomplete or poor source data when looking for a single recording rather than an album. There's been some discussion on the MusicBrainz forum related to this: https://community.metabrainz.org/t/picard-lookups-for-single-tracks-are-wildly-off/

Of course, that just pertains to tag-based searching. It's often more useful to do a scan based on acoustid, the songs's audio fingerprint. However, that again runs into issues with the accuracy of the source data and the fact that the more popular/common the track, the more likely there is to be a mismatched acoustid ID - maybe a live version accidentally linked with a studio version, or even more egregious issues. Editors are always trying to solve these problems, but there aren't enough of them to keep it under control.

[The Incredible Boom Boom]

Yup, that's why i never asked at the Picard forum, I will be a duck in hunting season  
I saw your name there before and the answers from the advanced forum users were a bit slippery i thought.

To be honest about that, my beef with that forum is/was predominantly that 2 or 3 people with some 'forum power' have all characteristics, behaviour and deceptive tactics of 'social warrior activists'. Of which I am completely allergic to.

The guys who are doing the actual work on MusicBrainz' database and Picard are great.
People such as outsidecontext and RDSwift are gems, and are always extremely helpful, understanding and knowledgeable.
I would be very surprised if you would indeed get nasty or condescending responses if you ask for help on this kind of stuff on their forum.

I don't have the kindest of words for their "community."
It was incredibly obnoxious back some years before the earliest recording release tag was finally added to Picard, attempting to explain to them their esoteric understanding of "release" was not jiving with the rest of the Internet who wanted to use their tool. Thankfully I (believe I) have utilized Picard to the extent of which I will ever need it and thus do not need to peruse their boards much anymore.

In any case, I have a couple of questions related to the topic for you, @hiccup.

Code

$set(_year5,$if(%_work:forward:performance:begin%,$left(%_work:forward:performance:begin%,4),9999))

What on Earth is the tag you used? I (lazily) searched through the documentation for the latest Picard version, but could not discover an answer.
I had not yet opened a tab for the plugin you linked to, which I was going to ask about below, but the github page answers the above.

Have you had success with?

Code

place:backward:recorded_at: for the recording's recorded at Place relationship
area:backward:recorded_in: for the recording's recorded in Area relationship
event:backward:recorded_at: for the recording's recorded at Event relationship

Secondly...

Code

$if($or($eq(%releasetype%,compilation),$inmulti(%releasetype%,compilation)),$set(origyear,%_recording_firstreleasedate%),$if($eq(%origyear%,%originaldate%),$left(%origyear%,4),))

I use this script to pull the original recording release year for albums identified as compilations. The script you have written to grab this date seems to be very extensive. I'm wondering if you've had poor luck obtaining the correct year using just the %_recording_firstreleasedate% tag? I have often utilized this script, but I also do not double check the results if they seem accurate.

Thirdly, welcome back @psychoadept!

[hiccup]

Have you had success with?

Code

place:backward:recorded_at: for the recording's recorded at Place relationship
area:backward:recorded_in: for the recording's recorded in Area relationship
event:backward:recorded_at: for the recording's recorded at Event relationship

The single objective I had for creating this script was that I wanted to retrieve a singular, earliest possible recording/release/performance date.

It's been a while since I tested and constructed it, but what I usually do is create a library of some 10-20 tracks that present different sorts of challenges in regard to what I am trying to accomplish.
If I recall correctly, the three variables that you mention never returned a date earlier than the one I am using now, for any track that I threw at them.
So I left them out for this script.
(it may even be the case that the one I am using is created by taking the earliest date of the three you are referring to by the plugin itself. I can't recall)

I'm wondering if you've had poor luck obtaining the correct year using just the %_recording_firstreleasedate% tag? I have often utilized this script, but I also do not double check the results if they seem accurate.

For the majority of releases that will work fine.
But (as a guess) some 10% of them will get better (correct) dates using the variables my script is using.
And in some cases, there will be discrepancies up to 10-50 years...

This all of course also depends on how fine-grained users have specified such additional dates when adding/editing a release in MusicBrainz' database.
So, things may (slowly) get better over time.

[hiccup]

Have you had success with?

Code

place:backward:recorded_at: for the recording's recorded at Place relationship
area:backward:recorded_in: for the recording's recorded in Area relationship
event:backward:recorded_at: for the recording's recorded at Event relationship

To refresh my memory on this a bit (and satisfy a small itch in the back of my head), I checked these three variables.

And, if you use them like this (and as they are written on github also), they don't do anything at all…

They all need to be complemented with either:

begin
end
first
last

to function.

To those interested in testing these themselves, here is a little script you can use for them:
(and a couple others that I found)

Code

$set(001_artist:backward:instrument:first,$if(%_artist:backward:instrument:first%,%_artist:backward:instrument:first%,–))
$set(002_artist:backward:vocal:first,$if(%_artist:backward:vocal:first%,%_artist:backward:vocal:first%,–))
$set(003_place:backward:recorded_at:first,$if(%_place:backward:recorded_at:first%,%_place:backward:recorded_at:first%,–))
$set(004_work:forward:performance:first,$if(%_work:forward:performance:first%,%_work:forward:performance:first%,–))
$set(005_area:backward:recorded_in:first,$if(%_area:backward:recorded_in:first%,%_area:backward:recorded_in:first%,–))
$set(006_event:backward:recorded_at:first,$if(%_event:backward:recorded_at:first%,%_event:backward:recorded_at:first%,–))
$set(007_recordingdate,$if(%recordingdate%,%recordingdate%,–))

(if you also want to check begin, end and last, you'll need to create extra lines for those)

[hiccup]

I have updated the script in this post.

The code was improved a little bit, and it now checks two more variables.
For most releases they probably won't make a difference, but for e.g. some older jazz recordings/concerts and classical music they can.

[The Incredible Boom Boom]

For the majority of releases that will work fine.
But (as a guess) some 10% of them will get better (correct) dates using the variables my script is using.
And in some cases, there will be discrepancies up to 10-50 years...

This all of course also depends on how fine-grained users have specified such additional dates when adding/editing a release in MusicBrainz' database.
So, things may (slowly) get better over time.

Thanks for this assessment. At around ten percent, I'm wondering if it's fine to just leave my script how it is when matching albums. I would bet yours is more accurate with compilations, but I should prioritize the former over the latter in obtaining proper results for now.

To those interested in testing these themselves, here is a little script you can use for them:
(and a couple others that I found)

I will give these a shot and see what they pull - thanks!

[Tony_D]

I have completed my Library now using Picard and I estimate that 30+ % has a wrong date due to fact that my library has almost 3000 compilation albums.
For the majority of artist albums it works perfectly  

[Mosplaceboss]

I'm late to the game, but how do I install this plugin? https://github.com/avh4/picard-recordingdate - when I install it says not compatible with my version of picard, I am using Version 2.12.3