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.
@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.
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.
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.
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?
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ā¦
