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

Open
sampsyo opened this issue Jan 7, 2014 · 12 comments

Comments

Projects
None yet
10 participants
@sampsyo
Copy link
Member

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

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Collaborator

commented Jun 19, 2015

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

This comment has been minimized.

Copy link
Collaborator

commented Jun 23, 2015

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

This comment has been minimized.

Copy link
Collaborator

commented Jun 23, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Jul 15, 2015

+1, This would be really cool!

@GuilhermeHideki

This comment has been minimized.

Copy link
Member

commented Jul 22, 2015

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

This comment has been minimized.

Copy link

commented Jan 9, 2017

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

commented May 27, 2018

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

This comment has been minimized.

Copy link

commented Jul 9, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.