Agreed. I cannot imagine what good it does to ever have a song tagged with anything other than it’s original release year. If I want to create an auto playlist of music from a certain decade or, more specifically a specific year, then why would I EVER want ANY song tagged incorrectly as to its release year. A song was released at a certain point in time…period. What year a compilation album was released is pretty much of zero interest to me.
Yes I’m VERY interested.
It looks like the original release date info is already available for most releases in MusicBrainz, under the internal fields
What we need is the ability to customize Picard’s tag mappings to force it to output these internal fields like
originaldate into whatever tag is used by our music players to display the date.
For example: generate the
TYER (ID3v2) tag using the value of
%originalyear% instead of
Does anyone know if it’s possible to do something like this in Picard (perhaps using a tagger script or a plugin)?
Wow, thanks for the quick reply!
Yeah, I actually already ended up writing a simpler version of this myself:
but your version is safer, so still appreciated!
By the way, this forum supports syntax highlighting (see this post).
I know, I implemented it I was just lazy and answering quickly from my mobile, hence also the short post. I updated it.
Yes, but note that these fields are not showing the actual original dates for (tracks on) compilation albums, and from box sets containing multiple albums.
will get an original date of 2013 for all albums since that is the release date for the box set.
Yet the albums it contains are originally from 1978, 1979, 1980, 1982, 1985 and 1991.
And the Michael Jackson song ‘Ben’ from my example in the start post will still get an original year of 2005 instead of 1972.
I am still curious if this also doesn’t slightly bother the boys and girls working on MusicBrainz and/or Picard, and if they agree it would be very useful and sensible to have these original dates available somehow.
Your example points at tracks in compilations \ boxsets. There is a similar error caused by lack of data on standard Releases.
Currently the algorithm just looks for the oldest item MusicBrainz has in a Release Group. Which can be very misleading for some artists like Charlie Bird if only CDs have been added for his releases.
Maybe there needs to be something attached to a Release Group where an “original release date” can be set manually.
Often when I am adding a re-issue of a Release I’ll go to Discogs and import an original edition too so as to get that “original Release” date filled more accurately. Maybe even use the Wikidata links to pull an accurate date?
Dates are complicated and hard to pin down in a dumb algorithm.
Yes, true. Ehh, well, no actually
Dates by themselves are rather easy and specific. And they are plain numbers, so what more could a maintainer of a database wish for?
The issue here is more about deciding which dates are relevant to store and how to give them a place and availabilty so that humans can make use of them.
To this human, it is relevant to see in what year (when/if) a song was released as a single.
And I also want to easily see that if the song happens to be on some compilation album, and not only if it is on the original single/album release.
The same for original albums in a box-set.
Sure, MusicBrainz is doing nothing wrong technically when it fills the ‘original year’ with the first year that that box-set was released.
But this human is also (read: more) interested to see the original release years of the albums that that box-set contains.
Of course, any of this information can be looked-up, and in some cases it may be a somewhat subjective matter.
But in principle I feel it would be very logical (in a human way) to have such dates available.
Pretty much any music lover will have songs or albums matched to ‘original’ dates in their heads in some way of another.
It would be nice to have MusicBrainz/Picard understand—and accommodate for—that.
Totally agree with you.
I’ll also throw in other awkward dates like:
- first live performance of the track
- when the track first appeared on an album (not everything comes out as single)
- remixed dates
- re-recording dates
- sung by someone else (cover versions)
Huge potential in this database for looking up that kind of data. And there are fields for all of the above available now. These relationships are available now.
Where I find the algorithm fails is when data is incomplete. Examples like the Dizzy Bird tracks. CDs get uploaded to MB first. And it means someone has to fill the original vinyl releases in by hand. This means the current algorithm fails as it just assumes the oldest version in the database is correct. There is no way to say “this data is incomplete”.
Many concerts don’t even have the locations and dates added. Data is still stuck in the titles or the uploaded artwork. Filling all that in takes years. MB is far from complete. It is ever growing.
This is why I was suggesting we need a manual box to put this stuff into. An “override” to correct confused data. That is also why I pointed at WikiData as many releases and even many singles have those links in place. And Wikipedia is pretty good at having correct dates in place that we can mine.
A few entities would benefit directly from this, and the data could be pre-filled by doing wikidata lookups when available.
The reason this idea has been rejected previously is that we’d (much!!) rather have someone do the extra work (and yes, it is admittedly extra work) of actually adding the earliest known release to MusicBrainz. For a lot of vinyls, this can be done by importing from Discogs. (It is also possible to create a mostly “empty” release that e.g., has no medium/tracklist just to get the date in.) I’m not aware of anything to indicate that this position would have changed.
… and so on and so forth.
Yeah, I get the dream. And spend a lot of time doing that to fill in gaps in artists I am working on.
The trouble is the amount of research gets extreme. Until the gaps are filled is it fair to tell people to trust MB for those kinds of lookups? Are people not going to give up due to the bad data?
This is why I was thinking aloud about stop gap. If one is working via the API then there is no way to know how trustable results are without cross checking.
A Release has a “Data Quality” flag. Could there be something similar at Artist level?
I don’t understand how you would do any less research for adding a release that consists only of a title, artist, and release year.
If there exists such a field and you add earliest release date to “2000” but then it is discovered, there was a release in late 1999, the 2000 would have been wrong all along. If you add an “empty” 2000 release—and you know there was a release in 2000—then it was never wrong that there was a release in 2000, but now you just add the additional information that there was also a 1999 release (which can also be empty). But what if there was actually a self-published release in 1996 before they got signed (and the 1999/2000 release didn’t have any additional mixing of the recordings)? What if you add the 1996 release but “earliest release date” field is still set to 2000?
The field you’re lobbying for would not solve the issues you claim it would solve and would not lessen the amount of research needed, but will introduce data duplication that is liable to go out of sync.
(And again, note that all that is required for a release to be entered is a release title and a release artist. Everything else is optional. If you want to add a release from a year, you can do with just title, artist, and year. You don’t need to research anything beyond that. You don’t need to add any data beyond that. If you know a release came out in a given year, that is enough data to make it viable to add it to MB.)
Sorry, it is a failing of mine that I couldn’t just add such basic details. I need to be sure about the data I add and then I’d need to be complete.
I’m not proposing anything, more a case of responding to the complexity of the question.
I’ll unsubscribe from this as my comments are clearly jsut confusing the situation.
Please don’t. You seem to be one of the few active members here that has insights and experiences from both sides of the border.
And you also don’t seem afraid to state opinions in an honest (and perhaps sometimes impulsive) manner.
I think that’s very valuable and applaudable.
Back to the original matter:
Since I am no coder (and clearly on the other side of the border) I grant myself playing dumb here to make my case.
I will also allow myself to completely ignore the behind the screen technicalities about ‘how complicated dates can be’, or challenges in having people entering dates correctly.
My simple account from an end-user point of view:
I am using MusicBrainz’ Picard tagger.
I am using it to match a release that happens to be a compilation (released in 2005), and it contains the Michael Jackson song ‘Ben’.
That song dates back to 1972. Nobody would disagree about that.
But, Picard will not retrieve 1972 as an ‘original date’.
It will retrieve 2005.
What would be needed to have Picard being able to retrieve and write 1972 in this case?
Is this really such an awkward or difficult request?
Just answering from a purely Picard side of things: There would need to be an effective way to get this data.
Somehow this data can already be available in MusicBrainz, as MusicBrainz knows about the recording and where it has been used. With works it even knows about the concept of a song. So we could use MusicBrainz to lookup the earliest recording linked to the work. In the best case the recordings are linked to the work with a date set on the “recording of” relationship. For Ben this would even work. But as you can see for the many recordings linked to the work only 3 have set a date.
If we don’t get dates from the work-recording relationships or if we want to be safe we would then have to query each recording to get a list of releases and their dates.
In case of Ben this would add 1 request for the work and 84 requests for the recordings to be sure about the date. That’s at least 85 seconds more, and this is just for one track on the compilation.
However, having written this down I realize we could easily provide a plugin which does only the single work request and relies totally on the dates on the “recording of” relationship. This plugin would probably provide good enough results in many cases, and in cases where it doesn’t it would be not too difficult for an interested editor to add the data:
- make sure there is a work for the recording being looked up, if not create it and link it to the recording
- link the recording to the earliest recording findable, make sure to set a date
However, there is of course the distinction between recording date and release date. If this should be purely about release date there is currently no way around looking for other releases containing either the same recording or another recording of the same work.
I still don’t understand how a “first release date” release group field/property would prevent this? You’ll still have to do the same amount of research anyway to fill out this field (just you’d have to throw most of this research out if only adding the date)?
Yes, there really needs to be a way to get dates for individual recordings if we want. I don’t know how accurate it is, but iTunes will tag compilation tracks with an original date. Sometimes I’ll rip a compilation with iTunes just so I can copy that info to the original date field before I do the rest of the tagging in Picard
Picard needs to look up the original release date on the recording not on the album’s release group.
%originalyear for a CD compilation of Buddy Holly’s music, will return something like
1996… which is when the compilation CD is released… but if you just look at any of the individual recordings…
Then it’s obviously listed, right there at the top of the list,
That’s the year value we want to use to tag the recording/track in Picard.
The data is right there!