Original release date: Community opinion on how to handle the originaldate tag, first release date of release group and / or recording

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.

1 Like

@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)


The Yellow highlights are the “Recording Of” dates, and the second one has no date.

I haven’t used this beta yet, but will go install it to see if I can find the setting that @aerozol is highlighting in their post to swap to per recording dates instead of release group.

Neither of the recently added ‘original date’ tags provide these recording dates.

I think ‘recorded at’ contains the relevant recording date.
Why would ‘recording of’ be more relevant?

Actually, I think that this example of missing data is amenable to being fixed programatically:

The recording date is missing but the performance dates exist and are the same - so it can be inferred that the recording date is the same as the performance dates. :slight_smile:

Because Recording At is about the location and not the performance. You can have a song recordwed at more than one place (i.e. vocals one studio, instruments the other).

I had assumed this is using the normal “recording of” date as that is the one you set as a property of the recording. (Sorry, I’m not that good at Database language\terms)

No it can’t due to the example I just explained. Some recordings can be made up from multiple sessions. That is why there is a property of a recording to select a date.

Otherwise why have the ability to add separate dates to each instrument? :slight_smile:

So what does the date 1959-05-05 represent in the line that says:
Recorded at …studios on 1959-05-05 ?

It is what is says - it is recorded at that location on that date. In database language - it is the date of that relationship. We as humans can deduce that is logically the same date, but this is a database and it has rules.

It is the “Recording Of” relationship that needs fixing. Open the Edit Relationships tab and fill in the missing dates on the right hand side. They are most important for the “Recording Of”.

(really need a database person to better explain this)

Looking at the Edit Relationship page also makes it a bit clearer. You have the SINGLE date assigned on the right for the completed recording. The one entity. And on the left you have all the parts - which could include a sax solo overdubbed at a later time from a different studio. All those separate sources can be separately listed on the left.

But I clicked onto that release just now and there are a number of little errors. Other dates missing from other tracks, and double work links. I am working now, but later I’ll go clean up the Release for you to make it clearer.

I admit I don’t fully understand the logic why ‘recorded at …on…’ is not the most relevant recording date, but as long as the editors and the guys doing the coding understand it, that’s fine.

I appreciate that, but please don’t do it on my behalf.
I’m pretty sure it won’t solve the issue of those recording dates not getting pulled from the database by Picard.
But @sophist or @outsidecontext may prove me wrong with some brilliant solution.
Or maybe you, after you made database corrections and tested it with Picard beta…

I think the recorded at date is the most relevant recording date, but the discussion above is about the release date.

I think further up in the discussion it has already been established that it wod be good to have the recording date available as well.

1 Like