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.
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 a lot for all the details. This has been very useful. Some of the repeated core topics from above as I see it:
Having the date of a recording’s first release available is welcomed feature
The default should not be changed
It definitely should be available in scripting
There had been some concerns about data quality:
The recording first release date as it was implemented on the MB server only looks at a single recording. Recordings are often not properly reused. Also maybe sometimes you would consider the first date any recording of the work was released as appropriate?
If the date returned by MB server is not the correct one, fixing it is non-trivial editing (you need to do the proper research and merge recordings), which could lead to unwanted edits by users trying to force MB data to suite them
Some of you “don’t do scripting”
There are other dates one might want to use for the 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:
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:
For now there will be no GUI to change that, for several reasons:
Let’s see how this works out for you first before making this an option. If the quality of this data is not up to what user’s expect having this as a prominent option might lead to dissapointment
It is easy to add an option, it is more difficult to take it away again. If we see it is needed/wanted we can add it.
The option would change the default of 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.
If one uses %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.
I think even to those who don’t do scripting it is easy enough to explain how to add a simple script like $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.
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.
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.
@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.