New plugin: Metadata override

[smichel17]

The main use case for this plugin is interacting with less sophisticated players.

In particular, the albumartist field is unfortunately still unsupported in many music players.

<rant>

I'm not totally familiar with the history of the tag, but my impression is that it wasn't one of the original tags. Therefore, people (understandably) used the artist field for the album artist. Then, when people realized the need for two separate tags, they tried to add albumartist and thus, retroactively redefine the artist tag.

The problem is, in a distributed, consensus-based system, redefining tags never works. At least, that's what I've learned from hearing about attempts to do so in the OpenStreetMap community. You get stuck with the "redefined" tag losing all meaning, because you can never be sure whether it means the new or the old thing. In order to do it successfully, you need to convince everyone to stop using the old meaning, update every old usage to the new one, and update every piece of software that assumed the old meaning to use the new one. Effectively impossible.

The winning strategy is to deprecate the tag, and introduce a new tag. In this case, that would mean introducing two new tags, albumartist and something like trackartist. The existing artist tag would stay as it was (something like "whatever is most appropriate if you only have one field"), and be used as a fallback if either of the new tags is undefined.

</rant>

I haven't yet found a FLO Android player that works properly with albumartist (mostly because the Android media store, aka the convenient way to get metadata info, doesn't report it).

In order to get mixes and compilation albums to work on Android, I would like to write the albumartist data in the artist field. However, I don't want to do that in the beets database!

My idea for this plugin, then, is to define a mapping (using the existing path format syntax), where I can change which tags are written to the file:

metadata_override:
  artist: $albumartist

So then when I run beet write, beets will replace whatever value is in artist with the albumartist.
And maybe also add a new field with the original value (e.g. _og_artist).

[smichel17]

Or maybe the rewrite plugin already supports this? Can you use template values on the value side? E.g.

rewrite:
    artist .*: $albumartist

/me tests

[smichel17]

Answer: it doesn't. So maybe I could implement that rather than write a new plugin?

[smichel17]

Hmm, although I guess the rewrite plugin updates what beets sees, so maybe that's not what I want after all. Unless we extend the rewrite plugin to handle metadata and paths, too (using a separate config section).

[smichel17]

If it would work to implement this feature into the rewrite plugin, then this would enable storing rewrite rules / overrides as flexible attributes instead in your rewrite plugin config! To duplicate the Jimi Hendrix example from the rewrite docs:

rewrite:
    artist: $my_artist

And then set the attribute for the relevant artists:
beet modify my_artist="Jimi Hendrix" artist::'.*jimi hendrix.*'

This would also enable you to use mbsync, but still have local overrides for some value where you prefer to use a different value.
beet modify -a my_album="1" album:"Peter Gabriel" year:1977

[smichel17]

An alternative, maybe more maintainable, design would be to invert the pattern, adding new template fields (or a more convenient syntax for adding defaults):

fallback: # more fitting name for this version
    my_album: $album

⇒ equivalent of %ifdef{$my_album,$my_album,$album}

…Maybe I can get away with just the ifdef…

[smichel17]

…Maybe I can get away with just the ifdef…

Won't work, obvious in hindsight, because templates only work in paths — the point of this plugin is essentially to enable templates in tags.

[smichel17]

…hold on. Am I reinventing the inline plugin?

edit: Okay, not. Because this still doesn't allow rewriting metadata.

[smichel17]

The reason I missed this on my first skim was that I thought the inline plugin was about adding "inline python snippets" to your template values— I didn't realize it was about creating new template values via python.

[smichel17]

Implementation-design wise, I think the sane way to do this is a single pass (no recursion). I think I'm going to try a PR to add template rewriting to the rewrite plugin as a first pass at this (it should be useful as a base for this plugin even if the PR is rejected).

[ibeex]

did you find any solution for this? I use an external script to rewrite albumartist to artist tag after import, but it is far from elegant.

[smichel17]

No, I changed jobs and moved and it will probably be a while before I have a chance to finally finish organizing my music collection properly :/

#4178 was as far as I got, which I think is quite elegant, if someone could fix the recursion issue.

[ibeex]

Plugin https://beets.readthedocs.io/en/stable/plugins/ftintitle.html covers 99% of the differences so I ended up using it.