Open Freso opened 9 years ago
We do collect artist_credit
and albumartist_credit
fields (separate from artist
and albumartist
). Is anything missing about that piece of functionality? (That is, you can use $albumartist_credit
in your path formats.)
But I don't want to use it in the path - I want to have it in the file's metadata. That's the point. :)
Ah! Sorry for being slow. So if I understand correctly, this would work like original_year
, in that the purpose is interoperability with other software. So the credit would go in the $artist
field, and the "true" artist name would probably go in a separate flexible attribute like $artist_canonical
in case you want to put it in a path.
This would be a great feature. Currently I have some tracks that have the artist [unknown]
but have a more interesting credited name. Currently they just get tagged as [unknown]
.
It's obviously useful to tag with the canonical artist name, as that makes it possible to group tracks by artist and search, but with artist names like [unknown]
there's no real downside to just using the canonical name.
+1
Out of my 4029 albums only 97 have differing albumartist and albumartist_credit values (~2.4%). I checked about a dozen of these albums manually against Discogs, iTunes, Amazon and Google Play. All sites use the artist credit over beets' "canonical" version.
A few examples:
"Margaret Antwood - Virtuous.scr" on MusicBrainz but "Antwood" on Discogs and iTunes
"MF DOOM - Born Like This" on MusicBrainz but just "DOOM" on Discogs and iTunes
"Wu‐Tang Clan - The Saga Continues" but just "Wu Tang" on Discogs and iTunes
It seems like MusicBrainz treats the artist field as the artist's current name, which can change and cause large, unexpected metadata changes to existing files (e.g. when Jay-Z was renamed to "JAY-Z" on MusicBrainz).
Given the above, it might make sense to prefer artist credit as the default for future imports (although I don't mind one way or the other if it's at least user-configurable).
+1 on this.
I reported it earlier (as #2854) because my GitHub issue search skills were lacking at the time.
@sampsyo What can we do to make progress on this feature? How do you think it could/should be implemented?
It seems like adding a config option is the right thing! As I said above, a motivated implementor could model it after the way the original_year
option currently works.
Here’s a possible implementation for an artist_credit
configuration option: #2870.
After playing around a bit with the artist_credit
option from https://github.com/beetbox/beets/pull/2870, I can confirm that it doesn't solve the premise of this ticket:
Use Artist Credits for tag data, but "actual" artist data for filenaming
Setting the artist_credit
option will use the Artist Credit both for the tag data (👍) but also for the file naming (👎). Reopening.
Ah, I see. I think it's too confusing (and probably too messy to implement) for beets's $artist
field to contain one thing with respect to file tags and another thing when it appears in filename template strings. As an alternative, I propose that the artist_credit
option additionally "move aside" the "actual" artist into a different field. I'm terrible at coming up with names, but it could use $artist_noncredit
or $artist_name
or something. Then users are welcome to refer to those fields in template strings instead of plain $artist
, which now contains the credit.
I guess this could actually be done with item_fields
too, maybe? I'll try and play with that a bit later. If so, no new functionality may be needed! 🙌
@Freso any luck?
I'd love to see an $albumartist_noncredit
for use in directory names, at least.
Currently beets will always normalise artist credit data to the current artist name. However, I want to see when playing the music when, e.g., Orgi-E was credited as Klamfyr, but I still like the normalisation for file tree organisation purposes. This should probably be an option though, as other people will likely want to always normalise the name (and others might want to not normalise the name in the path as well).
(Somewhat related morituri issues: thomasvs/morituri#80, thomasvs/morituri#48)