Great!
Iām a noob re. scripting so I donāt quite understand if these are all new tags (great), or changing existing ones? releaseoriginaldate? Is that a new one, is it changing āOriginal Release Dateā, or is it just a backend scripting variable?
If this is all about scripting variables then I have no input, if it is changing out of the box Picard behaviour/tags then I would add my 2 cents 
Have a look in the first link in the OP. It looks like a suggested Picard change to add an option in Picard to allow that āOriginal Release Dateā to be optionally switchable between Album Release Date and Track Release Date.
I too donāt do scripting in Picard, so am looking at this as a āalmost defaultā Picard user. Also as a user of KODI and knowing how that mob will try and use Picard with respect to a Media centre. I know they were talking about something like this which is interesting timing. BUT that does mean a huge mob of people many suddenly enable this, hence my thoughts above.
I like this wording āTrack Release Dateā as it s indeed different than the āRecording Dateā itself. Else could be āRecording Original Release Dateā
Regarding the initial questions:
Default behavior should not be changed to avoid many returns or unseen issues
Yes an option should be created but it could be more generic: Switch from āAlbumā to "Recording/Track mode to define priorities for this field as other main ones: Rating, Genre, Retrieving Artist and Track names from recordings or albums,ā¦
In other words when data exist at both Recording and Release levels two variables should exist and this new option will define the priority to use for the generic tags.
To explain this I would say that we have two types of users:
The ones who are scripting and as them I would like to have all the possible variables available (cf having original release year per album and per track, same for genre, rating,ā¦)
But part of the community may like an easy mode and as them I would like to just have to tick one box and tagged my files. And I can still split the tagging between Albums/Compilations/Classical releases if I want to use a different behavior depending of release type.
Warning: I would prefer a detailed explanation in the help about all the changes implied by this option. Then definitly a warning if such option will support only date at start.
This looks great, from an end-user perspective:
As long as it defaults to the current behaviour. Changing data to something as granular, and often wrong (recordings have to be merged and linked correctly), as āoriginal recording dateā would open a can of worms. I would expect to see a lot of forum posts from confused/unhappy casual or first time users if that happened.
Thanks 
Thanks a lot for all the details. This has been very useful. Some of the repeated core topics from above as I see it:
originaldate e,g. @hiccup would like to use the date of recording there for some genres.So for now and for the next release we have decided for having the recordings first release available as a scripting variable %_recording_firstreleasedate%. For consistency there is also the corresponding %_releasegroup_firstreleasedate%. Both variables can be used in scripting. The tag originaldate will be untouched by default (so it by default is set to %_releasegroup_firstreleasedate%).
If one wants to have the recordingās first release date instead they can add a simple script like:
$set(originaldate,%_recording_firstreleasedate%)
But you can also do more sophisticated things, like e.g. using the recordingās first release date only for compilations, but otherwise use the release groupās first release date:
$set(originaldate,$if($inmulti(%releasetype%,compilation),%_recording_firstreleasedate%,%_releasegroup_firstreleasedate%))
For now there will be no GUI to change that, for several reasons:
originaldate. But it would have no effect if you set this to something different anyway with a script or plugin, and that could be confusing.%originaldate% for creating a folder in file naming and they toggle this option it would likely break their folder structure. This might be unexpected if the option does not make this very clear.$set(originaldate,%_recording_firstreleasedate%) (which is pretty much exactly what the option would do in code)The change will be available for you to play with in our next release. We plan to have 2.6 beta release soon.
Looking good. 
Thank you for this. Donāt take my points as negative, I just have head that sees holes.
I like the way it is will be available to scripters first. This allows the geeks to give the code a kicking and find the holes before the impatient masses get at it.
I have been merging a few Various Artists collections lately. It is noticeable that many editors who add the ā100 greatest hitsā collections are often the Hit n Run type editor. These are the people that will cause the most potential damage to the database once a feature like this comes online. Once the media centreās pick up on this feature us editors will have to be ready to do a lot of checking of merges.
This is why I suggested giving these people an edit box to fill in for āapprox release dateā to keep them away from the quality data. Give 'em a quick box to fill in that lets a date be guessed\approx which gives the real researchers time to perform the correct merges.
Or āif no date, guess date from earliest recording of this workāā¦ but that will be tripped up by the fact many tracks are not linked to works. Complex.
Yes, also my experience. I often wish there would be at least AcoustIds submitted so others have a chance to properly merge recording. But to be fair these types of compilations are often especially tricky. They are often cheaply made and the publisher cares more about having all the big names on them than for providing accurate data. Figuring out which previous recordings match can be a pain.
Hopefully this will encourage the āHitānāRunā editors to be more careful with the track/recording information now that itās more useful for generating playlists, etc. I for one will be checking all of my compliations and making sure that the original tracks are linked correctly in the database - and I hope that others that have requested this feature will do likewise.
2 posts were split to a new topic: How to handle recordingās first release date for rare recordings?
Okay - so now I have the beta (awesome work everyone!!!) and I thought Iād get a few of the compilations retagged to see how it went and I realise the apauling state of the links between compilations and the original release. This isnāt helped by the browser editor not being able to use advanced query syntax or an MBID when editing the release.
Does anyone have any pointer on how to clean up the data more easily (I can locate the original tracks, but I canāt get the editor to find them in the drop down list for the recording).
Mass attaching Works is the easy bit, it is the linking of the actual Recording in use that can be more complex.
The biggest problems I find is trying to work out which version of a Recording is being used. A Single, the original Album, a re-edited version. With some artists it can be very difficult \ impossible to pin down.
I have also noticed that Spotify (and likely others) are changing tracks used in compilations. I have seen more than one occasion where a 1990 CD would use a Single version of the track, and then Spotify suddenly swaps to using an Album version instead.
All you can really do is make use of AcoustIDs. As you have these albums, pop them into Picard and let Picard go hunting into the database for you. With some fiddling of the matching to bias singles and albums and lessen the match to compilations it can often track down a large chunk of the album for you using the SCAN button.
This still leaves you with lots of ālookup in Browserā and manual merges of tracks, but it has been a handy trick I have often used. Also the more common the track has been used, the more compilations start popping up helping confirm you have the right track
In many case you should be merging those Recordings, not reassigning them. If the recording currently attached is just a lone recording only used in that compilation, then you need to merge it into the original version of the recording.
Set direction of the merge to be Compilation into Original. (NOT age based - the aim is to preserve the more important MBID)
As to using the little dropdown lists - you can paste a URL of a Recording into that box and it will work. Copy\Paste the whole URL of a Recording, not just the MBID bit. That makes up for the limitations of those boxes.
But almost always I expect you will be merging tracks of a Compilation into the originals, not replacing them.
Edit: Iāve looked at my actual process for doing this task. I make use of a Userscript that adds the AcoustIDs to the Recordings on the Release page. This means I can work down a Release page, clicking on the listed AcoustIDs, and then check the matches found. If matches look good Iāll merge those recordings. (This often scoops up a few extra VA collections and Greatest Hits Releases at the same time)
Wow - Iāve had a look at merging the recordings but the process is eluding me. Itās rare that the lengths (picking something easy) on the compilations match other recordings exactly so I canāt guarantee itās the same version of the recording.
Is there a way to reference the original without merging?
This is one of the issues I was trying to highlight above and a reason a manual option may be needed to add an āearliest release dateā. Real Worldā¢ musical data does not comply to neat database guidelines.
The only possible relationship would be āedit ofā, but that will get very messy, very quickly. Also canāt be certain it really is an āeditā of the original. Is it an edit of the single or album version? And I donāt think this code will use that date anyway.
Post a few example links here so the devs can see the puzzle. I know for some of the artists I follow there are four or five different versions of a common track sitting on VA collections that can vary by 30 seconds or more with no neat way to link them back to the original.
āBased onā isnāt right as that has other uses. This almost calls for a new relationship for this specific use. āVA Version ofā or āCompilation version ofā. Something that can allow this kind of weak link without breaking the more useful links.
Thanks - it seems the older the recording the more versions there are (unsurprisingly). Thereās a lot more consistency in the ones from the digital age (1986+) that first went out on CD or CD single.
An example I started working with is āThe Bumpā by Kenny - a 1974 single that was big in the UK.
Thereās quite a few compilations that have been linked to a particular version (Iām not sure how to get a report with AcoustIDs and MBIDs to see if they actually do match) but the version Iām dealing with is the 2:08 version from ānon stop seventies partyā (donāt judge me based on this btw - it just seemed like a manageable example at the time). The original āsingleā version is in the list but virtually nobody lists that on a compilation (the single doesnāt even have a duration on it, which does seem to be the norm for pre-CD recordings - due to data gathering being easier from CDs I guess).
I think that ārecording ofā seems to be a reasonable way to address the link between a VA track thatās got a different length and the original, but I donāt see how thatās actually set in the interface.
For the āRecording ofā, look at the WORK relationship. This then links all the recordings of The Bump back to the same common denominator. You can add this relationship either from the Recording page, or click on Edit Relationship on the Release page and set the value on the right hand side.
Do I assume that the shorter length on Non-Stop 70s party is due to it being a mix?
Finding the AcoustIDs is easy, they are hiding behind the Fingerprints page on a recording. It doesnāt help you too much with your Non-stop version as the AcoustID is unique. It is often possible to merge VA collections with the AcoustID which you can see has happened at the bottom of your screenshot. That has five different AcoustIDs attached and dozens of tracks. From there the AcoustID can be used to bring in more of the unmerged VA versionsā¦ but you are still left with your copy on its own.
A puzzleā¦ but this is the first version of the attempt to get Original Dates. It is going to work for versions of The Bump on the VA collections that appear in the big mass at the bottom of your screenshot, but so far no neat solution for the loners who canāt be merged.
Thanks! Itās not a mix, its a VA album, I donāt have another recording of that track but Iāll have a look around and see if I can se the comparison.
Okay Iāve found another one which was quite easy to add the relationship (Are āFriendsā Electric? by Tubeway Army which I have on āItās Electric: Classic Hits From an Electric Eraā and actually had 3 releases associated with the same MBID).
Having added the relationship does the āoriginal release dateā follow if itās a relationship for a āworkā rather than an āeditā (I presume itās an edit as itās 8 seconds shorter than the original recording) - does it even follow a relationship? Thereās probably a delay on the processing of the relationships so Iāll give it a few days and see if the original date propagates.
I have no idea if āedit ofā will work. By posting in this thread hopefully we can stir up that as a possible option when no date has appeared.
This is a tricky puzzle to fully automate as Real Recordings, especially on VA albums, donāt follow the Database Rules.
In this example you donāt need āedit ofā and I would not use it unless I have been able to listen to a noticeable difference between the two tracks linked. The Tubeway Army (5:18) track should be giving you that 1994 date as it is linked in with the original album version that has a date. You didnāt need the extra āedit ofā relationship in there.
(Iāve just added the Work relationship to that recording to be complete)
A 5:18 and 5:23 is so close that they often get merged into the same Recording. It is very likely if you listened to them both playing at the same time youāll just find a slightly earlier fade. Hard to know without example of both. How does your 5:18 version end?
After a look at the histories, if it was me Iād merge these examples unless there is anything odd sounding on the end of your version. An difference of eight seconds is nothing of note on a five minute track. This is likely the same recording just a slightly different fade out.
Iām afraid I know the answer, but still asking in case there have been developments or solutions that I am not aware of:
Many recordings have their actual recording date mentioned, like this:
So track 1 was recorded in 1959, track 2 in 1961.
Is there a way to get Picard writing these dates?
.
@hiccup I think that this would be possible with a plugin. I havenāt check but I think that if you have Use Track Relationships ticked in Options / Metadata, the recording dates may well be in the WS response.
In which case, it should be possible to set a recording date tag for each track.
One area of scripting that is IMO deficient in functionality, is the ability in either Tagging or File Naming scripts to analyse metadata across all tracks - i.e. to get a minimum or maximum date or calculate the total album length or get a combined set of track artists etc. I think it would be very useful to have some functions which provide this sort of functionality.
