As I specifically noted, “the performance dates exist and are the same” - when all performance dates are the same, it can be reasonably inferred (i.e. it is probably but not certainly true) that the recording date was the same as the performance dates. Of course, it is possible that e.g. the backing track was on one date and the vocals on another, and if the recording date does not exist and backing track performance dates exist and are the same but the vocal performance dates are missing, then this inference will be incorrect - but in the absence of the missing information it is perhaps the best guess possible and is likely to be close.
(Of course, this would not be good enough as an algorithm in MusicBrainz itself, because MusicBrainz aims to be accurate and definitive. But when tagging, a best guess like this might well be better than having no recording date at all. And of course, it is quite possible to add an option to the plugin to turn such guesses on / off.)
Yeah, true, but isn’t it just easier to add the missing data to the website? That way other people benefit from it.
In this case it looks like it came from a merge. One often sees cases like that. (But this is taking the thread off tangent and I feel daft enough having got my Release and Recording dates confused again )
What to do when there are multiple relationships, but they disagree? Use the earliest date?
Is there any other way to store the recording date?
I am copying my response in here to stimulate discussion and get alternative viewpoints:
A. Another issue is when the recording relationships above are a range not a single date. Do we take the first date, the last date or some sort of average? My vote is for the last date.
B. When there are multiple relationships but they disagree, then again, my vote is to use the latest date.
[Discussion about using performer dates snipped as it largely duplicates what I posted earlier. I will note, however, that I have suggested a best guess is still possible when performer dates vary by taking e.g. the latest of these dates as a recording date. Again my thinking is based on a best guess being likely close to the actual date and better than having nothing in recording date tag. But others may equally validly disagree with this.]
ID3v2,.3 has TDRA for the recording date. ID3v2.4 has TDRC - but the Picard documentation says that this is (incorrectly!!??) used to store the Release date instead of using TDRL. I have not checked other formats to see whether they have equivalents. So, I guess Recording Date should be a visible tag rather than an invisible variable.
Hm, the quote feature doesn’t seem to work, so: @Sophist wrote:
A. Another issue is when the recording relationships above are a range not a single date. Do we take the first date, the last date or some sort of average? My vote is for the last date.
B. When there are multiple relationships but they disagree, then again, my vote is to use the latest date.
About A:
I am guessing this could happen when a release was recorded over the period of e.g. three days, and the exact recording days are not specified per song?
I agree using the latest day is more than sufficient.
About B:
Not so sure.
What are the chances between the first, or the last date being wrong.
As a completely uneducated guess I would think the first one has the most credit. Why invent such an early date?
A later date could be a result of mixed information regarding release dates?
edit:
About B:
Perhaps there are some actual examples of releases in the database that have disagreeing recording dates, so we could try and understand what causes it, and which one in general would be the most valid one to use?
Useless (but fun) observation:
If I am not mistaken, this could become the very first time that the TDRC frame would get to be appropriately used as intended more than 20 years ago.
I hope the guy that thought it all out still lives
(for compatibility sake, perhaps a TXXX frame would be better, I don’t know)
As far as I know FLAC (vorbis comment) has no specific proposals/guidelines on recorded date.
So anything, such as e.g. DATERECORDED would probably be fine.
Not quite - or at least I don’t think so. I imagine that some bands can dash off several recordings in a day, particularly if they play the track as a group - others can take several days for one track, particularly if they record each element separately and overdub etc. (I am thinking for example of 10cc’s I’m Not In Love which took days and days to record the choir effect.)
So I think the dates for a particular recording could span several days.
On reflection, I agree. This is a bit more complicated - how do you judge which of the dates is correct. They may not actually be an error either. For example, they could be a day or two apart i.e. they rehearsed and laid down a recording in the studio on day 1, and then played it live at an event on day 2 but a plane went over during one verse so they had to use part of the studio recording to fix it. Or perhaps they made several recordings over several days and just used some bits they liked from one and other bits from another.
Real life is messy and doesn’t always fit the nice database schemas dreamed up by the MusicBrainz folks. Equally there could be an edit cock up and have mixed the dates for two completely different recordings which were years apart.
The choices are: A) don’t set a date, or B) pick a date using a repeatable algorithm (e.g. earliest or latest) but definitely not randomly. (Random dates would mean different dates on every load making the album dirty and needing saving even if no MusixBrainz edits had been processed inbetween. This is why multi-value tags where order can be random should always be sorted.) I really have no idea whether earliest or latest date would be best.
It is them pesky artists not thinking about us OCD taggers again. Any solution has to be “per track” and no algorithm will be perfect. I spend a lot of time in these kinds of details. Often having to chase through many contradictory history books about the bands involved. 40th Anniversary reissues can often be good as the band may get together and write up a book with more details - but then you are relying on the contradicting memories of those who were there.
Sometimes a track is recorded over multiple sessions, multiple locations, then pieced together at a later time.
Live tracks can be spliced from three different concerts if a guitar solo was particularly good from one concert.
Often an album is “Recorded in Summer 1976” or “Between September and December 1967”. Leaving it hard\impossible to know which tracks were on which date.
Picking the highest value is a good approximation \ cheat as it will be close. But once it is in the tag how do you know if this was a guesstimate or accurate date when looking at the music file years later?
Though it is impossible to get things nailed. At least one of the bands I work on has a noticable “off by one year” error on their own website history! Musicians are rarely good at documenting things.
Quick question with regards to getting the earliest release date of a track:
Does every release always get a musicbrainz_releasegroupid tag?
So e.g. also if only one batch of a vinyl single was ever pressed and released?
As far as I know, in the MB database schema, every release (even a single) has to be linked to a Release Group, which means that the RG MBID will be populated.
It would IMO be useful for Picard to put the count of Releases in the Release Group in a variable %_releasegroup_count% in order that scripters can know if this is the case (PICARD-2167).
Which is better? The clock which is right twice a day, or the one which is only right once a year?
Which is better? The clock which has stopped, or the one which loses 10s per hour?
IMO, the answer is that MusicBrainz is the location of the most accurate information. The tags written by Picard are a snapshot of that. And whether it is the recording event-date which is wrong, or that Picard made a best guess estimate, if MB is updated, the tags will be out of date until you run them through Picard again.
However, perhaps we should set a variable indicating whether the recording date is specific data or a Picard guess.
Testing the new _recording_firstreleasedate and _releasegroup_firstreleasedate tags, I run into a release that gives me results I don’t understand and wouldn’t expect.
This is my script:
$set(1st recording first release date,$left(%_recording_firstreleasedate%,4))
$set(1st releasegroup first release date,%_releasegroup_firstreleasedate%)
This is the result:
Shouldn’t the ‘recording first release date’ also be ‘1994’?
I am not surprised this happens, because the default when you add a new release to an existing release group from scratch rather than basing it on an existing release is to add new recordings, and I warned that this might be the consequence in the other thread about earliest recording date. (And this is one of the two reasons why earliest recording date is NOT automatically used as Original Date for the track.)
So the issue you are seeing is that when the 2001 release that you have loaded was entered onto MB, it was entered without linking it back to the recordings on other Releases within the same Release Group. So this release uses this recording whilst the other two releases use this other recording. When you look at these two pages you can see from the start that this is likely to be wrong unless Dionne re-recorded it specially for the re-release of this album which I doubt.
So someone needs to go and edit this errant release and link this track to the older recording. And to do the same will all the other tracks where it is incorrect. This is a time-consuming task.
You have a first release date for the album of 1994, but if you select one of the Other Releases, you should indeed get a 1st recording release date of 1968 as that is the earliest date for a recording of this track on the other two alternative releases.
Or go and fix the recordings on MB to point to the older more used recording and when these are merged, you can retag with Picard and get the right date - and at the same time, you will fix it for everyone else too.
Unless you have the actual CD, I would imagine that each of the Releases in this Release Group are equally valid - so why not just select the earliest one instead?
In that Dionne Warwick example it looks pretty safe to merge the two Recordings together. And that would fix the date issues for that recording.
But what happens when the recording is an edit which is 20 seconds short? This often occurs on VA releases and can lead to puzzles and no clear way to link back to an original date. This would be a time when MB rules would not allow them to be merged.
Yes indeed. Spent many an hour on some of my favourite bands working on this. Especially gets messy from the VA compilations when it is not clear when single or album versions used.
Every little recording merge helps… but a long mission.
And what complicates this even further (read: makes it pretty much impossible at this moment in time) is that you can’t be completely confident to merge releases within a release group, because you won’t be able to listen to the recordings to make sure they can indeed be considered to be the same recording.
So for now I am starting to think it was a pipe-dream of mine to think that it would be technically possible to get reliable ‘first release date’ results for songs.
Exposing the data is a huge step towards encouraging people to actually care about assigning and merging recordings correctly. It really can’t be overstated how important it is that people see information (or connections) are missing before they will start adding it! This is a necessary first step - if you will ever be able to load your whole collection and get reliable first release dates for every song is another matter unfortunately
I have been testing this on quite a few releases by now.
I created a script that writes the ‘first release date’, unless it is more recent then the ‘original date’.
In that case it just writes the ‘original date’.
After my initial brief disappointment that it will not give perfect and reliable results in all cases, I must admit I am very happy with the overall results I am seeing.
It’s a great improvement on what was possible before this.
So thanks again to the Picard developers for implementing this!
)
Spent many an hour on some of my favourite bands working on this. Especially gets messy from the VA compilations when it is not clear when single or album versions used.