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.
@hiccup That is from up higher in the thread… hunt out the setting. But you need to look close at your example as track 2 is missing the Recording date on the actual recording. It is only the “recording of” line that has the date being used. So track 2 needs fixing.
I don’t understand what you are saying.
Track 1 says: recorded at: … on 1959-05-05
Track 2 says: recorded at: … on 1961-05-25
Neither of these dates show up in Picard. (checking with ‘View script variables’ plugin)
