Configuration option to use specific release date

[GoogleCodeExporter]

As it stands, beets tags a release with the year of the earliest one in its 
release group. This behavior is leads to confusion in some situations.

As an example, if a user has in its library two releases of the same album - 
the original release and a later remaster - they end up being tagged with the 
same year, preventing the user from correctly identifying them.

Original issue reported on code.google.com by goncalopp on 28 Sep 2012 at 8:35

[GoogleCodeExporter]

One possible solution proposed by goncalopp is to (optionally, of course) 
maintain the following invariant:
- If the library contains only one release from a release group, it is given 
the "original" release date.
- If the library contains multiple releases from a release group, each album is 
given its specific reissue date.

This requires, on every album import, checking whether the number of albums for 
the particular release group are increasing from 1 to 2. Furthermore, on 
deletions, you'll probably also want to detect the opposite condition and 
revert the release year to the original date.

The feature will probably entail adding fields for the original and reissue 
dates so these can be stored alongside the current date. (This, of course, 
suggests a different solution in which both dates are always stored and it's up 
to the user to decide which to look at.)

Original comment by adrian.sampson on 28 Sep 2012 at 10:57

• Changed state: Accepted
• Added labels: Type-Enhancement, Priority-Medium, Component-Importer, Component-Tagger

[GoogleCodeExporter]

Seeing that description, it looks like a lot of work, and the solution will add 
a significant amount of complexity to the importer, perhaps unnecessarily.

Your original proposed solution ("provide a manual command that changes the 
release date to the reissue date") seems simpler to implement, and especially 
to maintain.

I'd like to contra-propose, though :)

If instead of providing a command for "changing to the reissue date" we do the 
reverse (that is, revert the current importer behavior and provide a command to 
tag "Albums [...] with their original release date rather than the date of any 
reissue"), possibly in a plugin, there are two clear advantages:

1- The implementation is much simpler, easier to maintain, and probably more 
robust. There's no need to handle this type of thing in the importer.
2- All the releases have their correct (musicbrainz) release date UNLESS the 
user specifically asks otherwise.

Original comment by goncalopp on 29 Sep 2012 at 1:29

[GoogleCodeExporter]

Cool; it's sounding like we're converging on a better solution. I think a 
consistent policy (with a command to switch) is indeed simpler both 
conceptually and in implementation.

But, personally, I always want my albums to have the original release date 
(i.e., the current behavior). So all this should be configurable: the date used 
by the importer and the change made by the manual adjustment command.

Original comment by adrian.sampson on 30 Sep 2012 at 12:10

[GoogleCodeExporter]

Yep, this is just wrong behavior (or at least opposite to what everything else 
does)
Pretty much every other tagger (Picard, foobar, Jaikoz, Ex Falso — the list 
goes on) uses date to mean the date *of this release*, and originaldate (or 
similar, depending on mp3/flac/mp4) to mean the date of the original release. 

It might be a tall order, but would it be feasible to have some sort of 
scripting similar to what Picard does, so people who want to use non-standard 
tag keys can just do something like %set{date,$originaldate} if they want that?

Original comment by ha...@hawkesnest.net on 2 Feb 2013 at 6:09

[GoogleCodeExporter]

Thanks for reviving this issue, hawke. I'm prioritizing this for the 1.1 
release since the proposed configuration option will now be straightforward to 
add.

There are two things to do here:
- Add a new field so we can store both the release date and release group 
(original) date
- Add a configuration option to "cheat" as we currently do and use the original 
release date exclusively

Original comment by adrian.sampson on 2 Feb 2013 at 4:13

• Changed title: Configuration option to use specific release date
• Added labels: Milestone-1.1

[GoogleCodeExporter]

I totally forgot about this issue (I haven't had the time to mess with my 
library lately), but that's excellent news! Thank you for all the hard work

Original comment by goncalopp on 3 Feb 2013 at 2:20

[GoogleCodeExporter]

Will the release date be stored in the regular date field that most players 
will display, and an additional field for original or earliest release date? Or 
just store one date in one field, and allow the user to select which date is 
stored there?

I personally would prefer to just use the actual release date all the time.

Original comment by real.hu...@mrmachine.net on 5 Feb 2013 at 12:36

[GoogleCodeExporter]

The design I plan to implement is "original_date: (yes|no)", affecting a single 
date field on each album. No separate original (or specific) date field will be 
created.

Original comment by adrian.sampson on 5 Feb 2013 at 2:32

[GoogleCodeExporter]

That's unfortunate, given that so many players use the originaldate key. Is 
there a way to script it to set the fields correctly so I can use it? 
(personally I use Quod Libet so that's my preference but I know foobar uses it 
as well.)

Original comment by ha...@hawkesnest.net on 5 Feb 2013 at 3:14

[GoogleCodeExporter]

Interesting; I did not realize that the originaldate field was popularly 
implemented. In that case, I think it does make sense to go with hawke's 
preferred design: separate date and originaldate fields, with a config option 
to "cheat" and make them equal.

Thanks for bearing with me and explaining the situation, everybody.

Original comment by adrian.sampson on 5 Feb 2013 at 3:26

[GoogleCodeExporter]

original_{year,month,day,date} fields added, specific release date used for 
unadorned fields, and "original_date" configuration option added as of 
aab7f92a1762. The default for "original_date" is off, which is a change from 
previous versions of beets.

Original comment by adrian.sampson on 8 Feb 2013 at 9:46

• Changed state: Fixed