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.
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!
Perhaps it’s not the most elegant or efficient way (not sure), but for now I am using this to write a ‘firstrelyear’ tag.
(note that I am not interested in specified dates. Years are more than good enough for me)
I now realise this may not work standalone.
I have some other ‘year’ scripts running before it, to mitigate between differences between flac/id3.
So you may need to adjust some stuff to make it work for you.
Certainly easier than merging all the recordings that need merging across MB in order to make recording_firstreleasedate correct all the time. Whilst of course it would be great if you were willing to fix source data rather than kludge the end results instead, recordings are such a mess that this is really too much to ask IMO.
I use origyear in my file naming path - so I use the RG first release date so that it is the same across all tracks on the album. If I used recording_firstrelease_date I would have different tracks in different directories. But I may well save the origyear in a different variable and start to use recording dates for the tracks.
The thanks here really needs to go to the server team. It’s were the actual work was done, making this data available in Picard then was technically rather trivial, the difficult thing was only to get an agreement how to exactly make this data available
But my personal experience with this pretty much is how you describe it. I enjoy that many of my files now have better original release year.
@dpr There is a big difference between the date a track was recorded and the date it was released for sale.
This discussion is about the earliest date that a specific recording was released for sale, not when it was recorded.
As you point out, there are some issues about the recording date frames in ID3 being used for release date - and I suspect that if you look then you will find several examples of where this has been extensively discussed in these discussion forums.
understood. It appears that resolving this is holding up making the recorded date available in Picard so I can tag my files with data from MB, a few of which Ive entered.
if this is not the case, apologies
The issues of changing the use of the recording date ID3 frames back to the formally stated usage are:
a. Backwards compatibility - which can be handled by providing an option to switch to correct usage;
b. Compatibility with how other taggers and players interpret these date frames - which would need to be researched.
Its a long debate, but the author lays out the request well. Theres also concern for backwards compatibilty.
I think its clear mistakes were made or complexities ignored or glossed over in id3 v2.2 and 2.3, but 2.4 tries to fix them. I hope we agree that there are three distinct events
When the track was recorded
Whn it was first released
The date of the release that this copy came from.
MB already allows us to document all of these dates. My plea is to move forward and support with simplicity. I’d like to get my copies of the Beatles cds tagged correctly in alingment with those 3 dates above
You cannot currently compare it to the tag from the file with scripting. What you can do is always keeping existing value from the file by adding the date tag to the preserved tags list. Then the new value would be written only if the tag is empty, otherwise existing values are kept. But as I understand that does not help in many cases for you as some files need to be updated with older date.
Another option would be to use the “original recording date” plugin:
It provides you a new tag / variable recordingdate which holds the oldest recording date, and also a couple of specialized variables if you need more control over dates from different relationships.
Just a note, because that kind of confusion goes through this entire thread: MB does not give 2002 as the earliest recording date but as the earliest release date. That’s an important difference.
If you look at the recording you’ll see that 1972 is also listed as the (start) date of recording in the relationships to the recording studios and to the work:
maybe a dumb question: I am using the script $set(originaldate,%_recording_firstreleasedate%) for a couple of years. On some compilations the result isn’t satisfying, e.g. Madonna’s Immaculate Collection, where release date is for all songs 1990. But this only has to do with the database and therefore the new plugin cannot change this, too. Right?