Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Formatted modify #488

Closed
sampsyo opened this issue Jan 7, 2014 · 14 comments · Fixed by #4095
Closed

Formatted modify #488

sampsyo opened this issue Jan 7, 2014 · 14 comments · Fixed by #4095
Labels
feature features we would like to implement

Comments

@sampsyo
Copy link
Member

sampsyo commented Jan 7, 2014

There are a number of cool things we could do if the modify command supported templates in the value part. For example, you could put the Echo Nest liveness into the comments field like so:

$ beet mod comments='liveness: $liveness'

It might also be nice to expose these rewritings in an import hook also.

@sampsyo
Copy link
Member Author

sampsyo commented Feb 5, 2015

It's becoming increasingly clear that people would like to apply format-like changes automatically to tags as well as manually, so this ticket should definitely include that.

As proposed in #1310, it would even be useful to apply transformations globally to all tags. That is, rather than configuring every tag separately to lower-case its value with title=%lower{$title}, artist=%lower{$artist}, etc., a global pattern would apply to every tag. Some people clearly also want to use %asciify{} the same way.

@Bercio
Copy link

Bercio commented Feb 8, 2015

Another nice use case (especially if implemented as an import hook) would be to default a field to something else in case of an Unknown value, e.g.:beet modify composer::^$ composer = $albumartist

@PierreRust
Copy link
Contributor

Hi,

following my recent mail, I've been thinking about this feature and I'll try to sum up how I see it :

Formatted tag modification would be usable with the import and the modify command

beets import  PATH tagName1='<expr1>' tagName2='<expr2>'
beets mod QUERY tagName1='<expr1>' tagName2='<expr2>'

where <expr> can contains

  • references to other tags value : beet mod comments='liveness: $liveness'
  • a template function : beet import /path/to/album title='%lower{$title}'

When importing, it would set the tag to the specified templatized value. If a variable is used in the expression, it's value would be the value produced by the import process (i.e. either from the file or form auto-tagging ).

It would also be possible to specify such transformation in the configuration file, with a plugin, to be applied to every import. A simple evolution of the (renamed) zero plugin is probably enough,

zero:
fields: genre 
genre: 
    match : [rnb, 'power metal' , 'Default Genre']
    value : 'Default Genre'

The only thing that does not fit (yet?) in this approach is the global pattern suggested by @sampsyo : it could be implemented with a * tag in the plugin configuration, but I'm not sure how that would fit on the commandline interface, may something like beet import /path/to/album *='%lower{$*}'

Additionnal note on implementation : it could probably be done in Model.setitem (db.py) : this path is used in all the aforementioned use-cases and template evaluation is already available.

@PierreRust
Copy link
Contributor

Ok, I just made a first pull request (only for the modify use case) , but it seems so trivial that I'm wondering if I'm not missing something obvious here...

@PierreRust
Copy link
Contributor

Now I working on the import use case and I'm considering where the tag manipulation should happen (that is, when should we execute tagName1='<expr1>' ). It seems to me it requires a new stage in the pipeline that would be placed just after the plugins stages and before the manipulate_files stage. Of course, as it's the first time I really have a look at the import implementation, it might be completely wrong ...

Any idea / comment on this ?

@l-t-k
Copy link
Contributor

l-t-k commented Jul 15, 2015

+1, This would be really cool!

@GuilhermeHideki
Copy link
Member

About the commandline interface, I think it would be better if we don't have to write %__{$*}. Something like:

beet import /path/to/album  *='lower,asciify' or --apply='lower,asciify'

@microcreators
Copy link

glad to see I'm not the only one maintaining lowercase tags here. indeed that would be 👍 for me.
alternatively, case-insensitive data comparison during auto-tagging would be a way out (so that I my tags aren't overwritten by discogs / musicbrainz data).
so either a parameter like mentioned above or a config entry to globally influence tags.

thanks!

@dinojr
Copy link

dinojr commented Mar 22, 2017

I'd also like modify to offer this capability to other plugins. For instance to allow the alternatives plugin (https://github.com/geigerzaehler/beets-alternatives) to put replace the artist field by the albumartist one for the mp3 players who sort the music tracks by the artist field.

@bviefhues
Copy link

bviefhues commented Dec 30, 2017

I would appreciate having a feature for assembling tags from content of existing tags.

Use case for illustration:

Album with some tracks where Musicbrainz returns several different artists for one album.

  1. I want $artist to be replaced with $albumartist (because I listen on devices which group by $artist)
  2. I want $artist to be appended to $title (to keep/show the information)

Template for this could be something like:

    artist: $albumartist
    title: $title%if{%compare{$artist,$albumartist},'', ($albumartist)}

Tricky thing here is that this is not idempotent, applying the second transformation rule twice on an imported element would possibly yield different results (the rule adds the albumartist again). This transformation would be safe only during imports, on tag data coming from Musicbrainz or another external source.

It may be most sane to have two distinct modes:

  1. transformation rules in config file are applied during import or update only
  2. transformation rules on command line are applied during modify or as part of a new command

@sljunkie
Copy link

Hi, I came here reading #1310.

It would be useful for beets to set the case for both filenames and tags; kid3 has this feature and in beets a global option for the user like:

tag_format: lowercase/uppercase/capitalize
file_format: lowercase/uppercase/capitalize

with:
lowercase -> all letters lowercase
uppercase -> all letters uppercase
capitalize -> capitalize words following title capitalization rules (default)

would be perfect.

@gregbert42
Copy link

Would certainly help with my issue....

https://discourse.beets.io/t/multiple-artist-i-just-want-the-first-one/416

@lems111
Copy link

lems111 commented Dec 23, 2020

Please add this feature to help with my issue:

Wife has over 2000 tracks that we got out of google music before they shutdown and the artist tags are set to the name of the playlist in google music which is not correct. The title of each track has the artist name and I would like to extract the first portion of the title to serve as the artist name. Each title is formatted as follows:

  • [Artist] - [Track]

@emanuele-virgillito
Copy link

Hi, what is the status of this feature? i need to copy the value of year tag onto original_year tag for many entries, seems that the formatted modify would be the way to go. or is there any other way to do that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature features we would like to implement
Projects
None yet
Development

Successfully merging a pull request may close this issue.