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

MusicBrainz Picard
1

We have some debate over at the code review to add support for per track original release date to Picard.

This is a feature that is come up a couple of times here in the forums. Current versions of Picard use the first release date provided by the release group (the earliest release date of all the releases inside the group) to fill the originaldate tag. For many use cases this is fine. But it not always reflects the actual first release of each track. E.g. a compilation might have been released in 2020, but the recordings had already been released at different years over the past decades. See this, this or this discussion.

In the past the answer to this has always been that this would be great to have, but difficult to query without change to the MusicBrainz web service. Now work for providing a first release date per recording is in progress (and partially already deployed), and we would like to have this integrated into Picard.

In the discussion for the proposed changes to Picard there seems to be a consensus that it is useful to provide both dates separately as scripting variables, so they can be used in scripting independent of each other. The proposed change would add two variables %_releaseoriginaldate% and _%recordingoriginaldate% that can be used in scripting.

The questions that have come up in the discussion (as far as I understood it):

  • Should the recording’s first release date be the default, or should the default still be the first release date of the release group?
  • If there is a default, should there be a user option to change the default or is it enough to use scripting to customize the value of %originaldate%?
  • If there is an option, should there be an extra warning that the option changes the values of tag variables?

Note that setting the recording’s first release date means different recordings on a release can have different values for originaldate, which would have an effect if you use this date e.g. as a folder name.

The new scripting variables mean you can e.g. use a script to choose which value (_recordingoriginaldate or _releaseoriginaldate) to use for the originaldate:

$set(originaldate,%_recordingoriginaldate%)

Or with a fallback:

$set(originaldate,$if2(%_recordingoriginaldate%,%_releaseoriginaldate%))

Or choose depending on some condition, such as using the recording date for compilations but the release group date otherwise:

$set(originaldate,$if($inmulti(%releasetype%,compilation),%_recordingoriginaldate%,%_releaseoriginaldate%))

You could also choose to have the recording first release date in the tags, but use %_releaseoriginaldate% for file naming.

Opinions on what to choose as default and whether a specific UI option is needed or if it is sufficient to allow this for scripting?

8 Likes
2

I’ve always wanted the first date of recording to be an option. Escpecially helpful on greatest hits compilations.

4 Likes
3

This is really great.

For me there would be a difference between popular music on one side, and classical and jazz on the other.

For pop music I would be interested in the first released date. That will be the year you associate a hit song with.
For classical and jazz I would be interested in the actual recording date.

I have no opinion on what the default should be, I only hope it will be possible by means of scripting to decide which one to use.

5 Likes
4

Oh yes. That one is not part of the proposed changes for now, but if this recording is linked accordingly we could add a variable for this (not sure how to call it, %_recordingdate% is a bit ambiguous).

Issue is a bit that the date of recording can be set on different relationships (recording → work with type performance, recording → area or recording → place). In theory they should all be set to the same date, but could of course in practice happen to be different. Anyway, I like this idea. But it is separate / additional to the discussed change.

Update: I added https://tickets.metabrainz.org/browse/PICARD-2094 for this

Note that the current originaldate is about date of release, so the %_recordingoriginaldate% I described above is the date this specific recording first appeared on a release.

3 Likes
5

Nice idea - but don’t take the following notes as negative. I can see LOADS of positive in this, but I can also see a can of worms you are opening.

This is messy when you get to the details. What is a Release Date? And how it is reliably found from this database? And how can it be easily fixed by a noob?

Being an album person I prefer to see the same OriginalRelease date across my albums, but I can see the interest in having those extra tracks on the Deluxe re-issues getting their separate dates added.

I agree that this needs to be clearly named variables. Most people don’t read details and will expect it to “just work”. So you can’t change current behaviour without lots of warning. Make it a harder to find option and not a default. Keep the default RELEASE GROUP based as now.

Trouble is, the incomplete state of the MB database. I can see some big problems with large compilation releases due to the lazy \ part time editors. Big compilations are often thrown into the database by editors with incomplete attempts at linking back to actual recordings. (Random Example) Sometimes this is due to not actually knowing for sure which recordings have been used, so new recordings are made. Sometimes you can see an editor is just overwhelmed by the choices.

This will cause a lot of confusion. There will be a LOT of duff results coming back. Just look at that one example I have posted. Get ready for the tsunami of complaints in the forum. You know how people love to complain :wink:

It is also going to cause the incorrect linking of these tracks to any recording to just find a date. When this date change comes online then a serious overhaul has to be done to that Search page for adding a release. It has to be made easier and more reliable to find and check a match there. The above random example had linked a few tracks, but got some of them wrong in the process.

And how is a mix album going to be handled? Mix albums always have unique recordings, but would expect to have the original release dates of the tracks not that mix CD. There is currently no mechanism to allow albums like the Ministry of Sound releases to link to original dates as you’d only have the date of the edited version on that Mix CD.

To make this work there needs to be an easier way for a Noob to link a compilation like the above and get the expected dates.

I can already see this thread getting confused between Recording dates and Release dates. That is another potential issue being opened up - people see all kinds of dates as important for a track.

4 Likes
6

Note that I am (deliberately) approaching this from the luxurious position of a Picard end-user.
I do have some insights in the underlying and surely valid “yeah, butt’s” but I am muting such thoughts for now.
Somebody once told me that thinking in possibilities is better than thinking in problems. (But I’m still not convinced :wink: )

As a user of Picard I fully understand that the data it retrieves comes from a database that is populated by volunteering humans.
So I get it that sometimes data can be slightly wrong or even incorrect.
But I can make adjustments to my file tags myself, or I can help with improving the database.

If I would be able to retrieve recorded dates (for classical and jazz) and first release dates (for pop music) as they are available from the database it would already be great to begin with.

If I see dates that I have doubts on, I can do a check and correct them when needed.
(I am already doing that with the ‘original dates’ Picard is providing)

Surely it would be bad if lazy or badly informed users would complain about the presented results, but I am guessing the chances on that are slim.
The necessity to be able to create and use scripts for this will filter out the biggest dummies and fast complainers.

And it won’t be hard to create a FAQ on this matter and post a shortcut to it?

5 Likes
7

I don’t think it really matters what the default is as long as both values are available as variables (which you have done). Having said that, since we’re talking about changing the contents of tags (as apposed to variables) I am leaning to having them contain the best (most accurate) information, which I believe is what you have proposed.

In those cases where naming scripts rely on a consistent %originaldate% or %originalyear% across all tracks as part of their path definition, this can easily be accomplished by adding one line of code to the top of the naming script as:

$if($or(%_releaseoriginaldate%,%_recordingoriginaldate%),$set(originaldate,%_releaseoriginaldate%)$set(originalyear,$left(%_releaseoriginaldate%,4)))

This can be added now (before Picard 2.6 is released) to essentially “future proof” the naming script from the upcoming change regardless of what is selected as the default value of the originaldate and originalyear tags.

In any case, since both dates will be available as variables, I don’t think that yet another UI option is needed. Pick a default (I suggest the “best” information), and we’ll document it in the Picard User Guide along with an explanation summarized from this discussion.

5 Likes
8

Have you seen what the Lazy Tagging Brigade does when artwork isn’t in place? All that needs is careful research to put in a correct image, but that doesn’t happen. When they get a bad date the “fix” will be a lot harder for them and we will get a few weird recording links.

I am thinking both as someone who spends hours adding correctly research data, and also as those external users who just use this place for rough information.

All I suggest is not to enable this by default. Someone has to really know they are turning this on and should be warned the data is not perfect and it can lead to some odd results. We have plenty of us mad editors here who dive in and correct this kinda stuff anyway for our favourite bands… we just have to make it easier for the noob to do so too with their 100 track collection CDs. :slight_smile:

Oh - and be careful at your reference to Recording dates as these are very different to the Release dates being discussed. Recording dates are another world of complexity as they are often set over a period of months as a band may be in a studio “Late Summer” and not have the exact dates that a Release can be set to.

I agree that it would be REALLY nice to get hands on those dates in the files as well as the Release date but don’t think the discussion should be confused too much yet. :smiley:

Release date, original release date, recording date - all would be nice to see in the files. What are other apps doing though? There are already some standards out there in the tagging world.

4 Likes
9

I already see an opportunity to add this to the FAQ list in the Picard User Guide. :wink:

3 Likes
10

Great!

I’m a noob re. scripting so I don’t quite understand if these are all new tags (great), or changing existing ones? releaseoriginaldate? Is that a new one, is it changing ‘Original Release Date’, or is it just a backend scripting variable?

If this is all about scripting variables then I have no input, if it is changing out of the box Picard behaviour/tags then I would add my 2 cents :slight_smile:

2 Likes
11

Have a look in the first link in the OP. It looks like a suggested Picard change to add an option in Picard to allow that “Original Release Date” to be optionally switchable between Album Release Date and Track Release Date.

I too don’t do scripting in Picard, so am looking at this as a “almost default” Picard user. Also as a user of KODI and knowing how that mob will try and use Picard with respect to a Media centre. I know they were talking about something like this which is interesting timing. BUT that does mean a huge mob of people many suddenly enable this, hence my thoughts above.

1 Like
12

I like this wording “Track Release Date” as it s indeed different than the “Recording Date” itself. Else could be “Recording Original Release Date”

Regarding the initial questions:

  • Default behavior should not be changed to avoid many returns or unseen issues

  • Yes an option should be created but it could be more generic: Switch from “Album” to "Recording/Track mode to define priorities for this field as other main ones: Rating, Genre, Retrieving Artist and Track names from recordings or albums,…
    In other words when data exist at both Recording and Release levels two variables should exist and this new option will define the priority to use for the generic tags.
    To explain this I would say that we have two types of users:

  • The ones who are scripting and as them I would like to have all the possible variables available (cf having original release year per album and per track, same for genre, rating,…)

  • But part of the community may like an easy mode and as them I would like to just have to tick one box and tagged my files. And I can still split the tagging between Albums/Compilations/Classical releases if I want to use a different behavior depending of release type.

  • Warning: I would prefer a detailed explanation in the help about all the changes implied by this option. Then definitly a warning if such option will support only date at start.

2 Likes
13

This looks great, from an end-user perspective:

image
image765×178 44 KB

As long as it defaults to the current behaviour. Changing data to something as granular, and often wrong (recordings have to be merged and linked correctly), as ‘original recording date’ would open a can of worms. I would expect to see a lot of forum posts from confused/unhappy casual or first time users if that happened.

Thanks :slight_smile:

2 Likes
14

Thanks a lot for all the details. This has been very useful. Some of the repeated core topics from above as I see it:

  • Having the date of a recording’s first release available is welcomed feature
  • The default should not be changed
  • It definitely should be available in scripting
  • There had been some concerns about data quality:
    • The recording first release date as it was implemented on the MB server only looks at a single recording. Recordings are often not properly reused. Also maybe sometimes you would consider the first date any recording of the work was released as appropriate?
    • If the date returned by MB server is not the correct one, fixing it is non-trivial editing (you need to do the proper research and merge recordings), which could lead to unwanted edits by users trying to force MB data to suite them
  • Some of you “don’t do scripting”
  • There are other dates one might want to use for the originaldate e,g. @hiccup would like to use the date of recording there for some genres.

So for now and for the next release we have decided for having the recordings first release available as a scripting variable %_recording_firstreleasedate%. For consistency there is also the corresponding %_releasegroup_firstreleasedate%. Both variables can be used in scripting. The tag originaldate will be untouched by default (so it by default is set to %_releasegroup_firstreleasedate%).

If one wants to have the recording’s first release date instead they can add a simple script like:

$set(originaldate,%_recording_firstreleasedate%)

But you can also do more sophisticated things, like e.g. using the recording’s first release date only for compilations, but otherwise use the release group’s first release date:

$set(originaldate,$if($inmulti(%releasetype%,compilation),%_recording_firstreleasedate%,%_releasegroup_firstreleasedate%))

For now there will be no GUI to change that, for several reasons:

  • Let’s see how this works out for you first before making this an option. If the quality of this data is not up to what user’s expect having this as a prominent option might lead to dissapointment
  • It is easy to add an option, it is more difficult to take it away again. If we see it is needed/wanted we can add it.
  • The option would change the default of originaldate. But it would have no effect if you set this to something different anyway with a script or plugin, and that could be confusing.
  • If one uses %originaldate% for creating a folder in file naming and they toggle this option it would likely break their folder structure. This might be unexpected if the option does not make this very clear.
  • I think even to those who don’t do scripting it is easy enough to explain how to add a simple script like $set(originaldate,%_recording_firstreleasedate%) (which is pretty much exactly what the option would do in code)

The change will be available for you to play with in our next release. We plan to have 2.6 beta release soon.

7 Likes
15

Looking good. :smiling_face_with_three_hearts: Thank you for this. Don’t take my points as negative, I just have head that sees holes.

I like the way it is will be available to scripters first. This allows the geeks to give the code a kicking and find the holes before the impatient masses get at it.

I have been merging a few Various Artists collections lately. It is noticeable that many editors who add the “100 greatest hits” collections are often the Hit n Run type editor. These are the people that will cause the most potential damage to the database once a feature like this comes online. Once the media centre’s pick up on this feature us editors will have to be ready to do a lot of checking of merges.

This is why I suggested giving these people an edit box to fill in for “approx release date” to keep them away from the quality data. Give 'em a quick box to fill in that lets a date be guessed\approx which gives the real researchers time to perform the correct merges.

Or “if no date, guess date from earliest recording of this work”… but that will be tripped up by the fact many tracks are not linked to works. Complex.

2 Likes
16

Yes, also my experience. I often wish there would be at least AcoustIds submitted so others have a chance to properly merge recording. But to be fair these types of compilations are often especially tricky. They are often cheaply made and the publisher cares more about having all the big names on them than for providing accurate data. Figuring out which previous recordings match can be a pain.

5 Likes
17

Hopefully this will encourage the ‘Hit’n’Run’ editors to be more careful with the track/recording information now that it’s more useful for generating playlists, etc. I for one will be checking all of my compliations and making sure that the original tracks are linked correctly in the database - and I hope that others that have requested this feature will do likewise.

3 Likes
18

2 posts were split to a new topic: How to handle recording’s first release date for rare recordings?

19

Okay - so now I have the beta (awesome work everyone!!!) and I thought I’d get a few of the compilations retagged to see how it went and I realise the apauling state of the links between compilations and the original release. This isn’t helped by the browser editor not being able to use advanced query syntax or an MBID when editing the release.

Does anyone have any pointer on how to clean up the data more easily (I can locate the original tracks, but I can’t get the editor to find them in the drop down list for the recording).

1 Like
20

Mass attaching Works is the easy bit, it is the linking of the actual Recording in use that can be more complex.

The biggest problems I find is trying to work out which version of a Recording is being used. A Single, the original Album, a re-edited version. With some artists it can be very difficult \ impossible to pin down.

I have also noticed that Spotify (and likely others) are changing tracks used in compilations. I have seen more than one occasion where a 1990 CD would use a Single version of the track, and then Spotify suddenly swaps to using an Album version instead.

All you can really do is make use of AcoustIDs. As you have these albums, pop them into Picard and let Picard go hunting into the database for you. With some fiddling of the matching to bias singles and albums and lessen the match to compilations it can often track down a large chunk of the album for you using the SCAN button.

This still leaves you with lots of “lookup in Browser” and manual merges of tracks, but it has been a handy trick I have often used. Also the more common the track has been used, the more compilations start popping up helping confirm you have the right track