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

Use queries / flexible attributes to modify metadata on import #565

Closed
l-t-k opened this issue Mar 3, 2014 · 6 comments
Closed

Use queries / flexible attributes to modify metadata on import #565

l-t-k opened this issue Mar 3, 2014 · 6 comments

Comments

@l-t-k
Copy link
Contributor

l-t-k commented Mar 3, 2014

First of all, beets is becoming really great! I like to use it fully automatically when new albums coming in (with a cron-job). Between this new albums, a lot of them are 'various artists' albums. I like to sort and categorise these v.a. albums in a special way. For example, i'm collecting a dutch hit-list serie called 'hitzone', up to now there are 68 of them. With the latest album-name: Radio 538 Hitzone 68. I add 'Hitzone' in each album hitzone album to the comment metatag. Like hitzone i got a bunch of other 'various artists' album tagged in the same way.

Now, i want to be able to use queries and flexible attributes to add these values automatically on importing to the comment field. Something like this:
if album contains 'hitzone' then add hitzone to comment tag. Preferably i want to add a simple text file containing al these collections and tell beets to lookup the file on import and check if it can find, for example hitzone that matches with the album name and then add hitzone to the comment meta-data tag. Is this possible? I know i can get them in the right folder with the queries but i specially need this tags in the comment field for my media player.

Furthermore, some other little question. Tell me, if im not reporting this in the right or if i should open an individual ticket for it.

  1. Is it possible to use the fetchart plugin only to feed embed art plugin? That is, don't import a individual art file, but only use it for embedding.
  2. The embedart plugin is overwriting an eventually already existing embedded art. Can this be changed? For example, check if the existing embed art is of better quality than the one that is downloaded and then take the one of the best quality?
  3. The scrub plugin is also removing the embedart, this should not be default behaviour. Moreover, the ability to not scrub certain fields would be great, e.g. embedart.
  4. The logging should be extended. I know it is already pointed out, but i think this is very important for those people using the tagger without manual user input.
  5. Move to an alternative directory if the album can not be tagged? In that case, the should not land into the database but outside into another folder for further manual inspection.
  6. Finally, the ability to look up albums within the database that doesn't have a cover art embedded would be a great feature

Thanks in advance, and my apologies if im not reporting this in the right manner. If that's the case, correct me please;)

@geigerzaehler
Copy link

Hi @kooimens!

Now, i want to be able to use queries and flexible attributes to add these values automatically on importing to the comment field. Something like this: if album contains 'hitzone' then add hitzone to comment tag.

The modify command can be used to set the comments track only on items that match a query. I think you want something like

beet modify album:hitzone comments=Hitzone

You don't need flexible attributes for that. In fact, flexible attributes are not written into the tags of your files, so your music player won't be able to read them.

Note that the modify command will update all albums that contain the string "hitzone" and write the comment tag, even if it already exists. For this to be faster you may want to add the 'comments::^$' query. This will only update comment fields that are empty. You may also refine your album query with regular expressions, such as 'album::^Radio 538 Hitzone '. It is important to quote the queries so they don't get mangled up by your shell.

Preferably i want to add a simple text file containing al these collections and tell beets to lookup the file on import and check if it can find, for example hitzone that matches with the album name and then add hitzone to the comment meta-data tag. Is this possible?

Yes this is possible, but not with beets alone. You have to write your own little program that parses your text file with the collection tags and the runs beet modify. For example, assume you have a text file tags.txt like this.

hitzone: Hitzone
Another Collection: collection

You can then use the following two-line gawk script to update your beets library.

BEGIN { FS=": "}
{ system("beet modify 'album:" $1 "' 'comments=" $2 "'") }

Just run it as gawk -f /path/to/script tags.txt.

@geigerzaehler
Copy link

As for the rest of your questions:

Is it possible to use the fetchart plugin only to feed embed art plugin? That is, don't import a individual art file, but only use it for embedding.

I am not sure what you mean. Do you want the fetchart plugin to not save the cover art on the filesystem (that is in your album directory) but just embed it? This is not possible since the fetchart and embedart plugins don't know of each other. They only know of the art_path attribute in the beets database, so you really need a file.

The embedart plugin is overwriting an eventually already existing embedded art. Can this be changed? For example, check if the existing embed art is of better quality than the one that is downloaded and then take the one of the best quality?

The embedart command overwrites the tags no matter what. But you can use beet extractart to write the embedded cover to your album directory. Fetchart will then pick it up automatically.

I don't think quality checks would be a good idea: Firstly, it is hard to define, what constitutes better quality and secondly we should trust the user to know what he's doing and not refuse to write a tag. For example the embedded art might be of better quality but just be the wrong image.

Move to an alternative directory if the album can not be tagged? In that case, the should not land into the database but outside into another folder for further manual inspection.

The best way to tackle this would be a plugin. There are some workaround, though. Untagged tracks can be listed with the mb_trackid::^$ query. You can use this to specify a custom path in you configuration

paths:
  "mb_trackid::^$": "untagged/$artist/$album/$track $title"

However, this will move all the untagged tracks in you library to this location—even those for which no MusicBrainz entry exsists. To circumvent this you can specify this option in seperate configuration file and run beet --config untagged-paths.yaml import ... with your cron job. This will use the configuration only for that particular invocation of the command.

A simpler approach would be to just check your importer’s log to see the untagged tracks or run the beet ls mb_trackid::^$ command.

Finally, the ability to look up albums within the database that doesn't have a cover art embedded would be a great feature

Beets doesn't keep track of the contents of file tags. One reason is that reading the tags takes up a lot of time. Again, a plugin could do that, so feel free to contribute.

For 4. and 6. I'm pinging @sampsyo.

On an unrelated note: I'm sure your not the only one who has these questions and is looking for solutions. It would be nice to have a collection of recipes for that. Is there a kind of cookbook @sampsyo? As you can imagine a “beets cookbook” search didn't yield usable results 😀.

@l-t-k
Copy link
Contributor Author

l-t-k commented Mar 3, 2014

Thanks for your extended reply geigerzaehler!

Is it possible to use the modify in combination with the import command? In a way that it wil only modify the albums being imported. If not, what are other possibilities to do so? Because I prefer using the comment tag in my path format and this is of course impossible if I run the modify command after importing.

You was right about what you were thinking regarding the embed and fetchart plugin. Maybe this can be done by changing the ignore option on importing? For example, set fetchart option to save covert art as folder.jpg and then add folder.jpg to the ignore option to realise that beets is, in the end, not importing the cover file. At the moment this is not working, but maybe some small changes to program can make this happen? I think many beets users use the fetchart plugin only as a companion of the embed plugin.

The 'beet extractart' suggestion sounds great. I will try to implement it. Writing a plugin to make use of a external text-file sounds challenging so will try to dig into it one of these days.

What about point 3? It is already mentioned by other users and maybe @sampsyo can eloborate on how to fix this in future?

@geigerzaehler
Copy link

Is it possible to use the modify in combination with the import command? In a way that it wil only modify the albums being imported.

No, unless you write a plugin that hooks into the import process.

If not, what are other possibilities to do so? Because I prefer using the comment tag in my path format and this is of course impossible if I run the modify command after importing.

The modify command actually moves the files after updating, so this should work out of the box. Take a look at the documentation.

You was right about what you were thinking regarding the embed and fetchart plugin. Maybe this can be done by changing the ignore option on importing? For example, set fetchart option to save covert art as folder.jpg and then add folder.jpg to the ignore option to realise that beets is, in the end, not importing the cover file. At the moment this is not working, but maybe some small changes to program can make this happen?

Ok. Let me elaborate first, why it is necessary to store cover art on the filesystem and then give a solution how to circumvent this.

All the data beets uses comes from its database. Retrieving it from tags and storing it there instead of a database is just not feasible if we want it to be fast, support queries, and other fancy stuff. Beets interacts with tags only in two cases:

  1. Updating the database with values from tags. This is usually only used when importing files.
  2. Writing data from the database to tags. The goal is to let other software like music players that don't know about beets benefit from all the data it provides.

So: For beets to manage cover art it must be stored in the database. Since storing the image data directly would bloat the database, we store the images on disk and reference it with a path. As I explained above, managing the cover art from tags directly is not feasible.

If you don't want the image files on your disk, but embed them in your tags you can do the following.

  1. Use fetchart and embedart when importing. This will add the images to your albums’ directories and embed the into the tags.
  2. Remove the image files manually with something like rm **/*.@(jpg,png).
  3. Remove references to the files from beets’ database with beet modify art_path="".

But be aware that this eliminates the possibility of managing cover art with beets.

@sampsyo
Copy link
Member

sampsyo commented Mar 3, 2014

Is it possible to use the modify in combination with the import command?

See also #488, which proposes adding modify-like functionality as an import hook (along the lines of the hypothetical plugin that @geigerzaehler described). Seems like a good idea to me! 😃

The scrub plugin is also removing the embedart

It should not be. The plugin used to have that bug, but we fixed it some time ago—which version of beets do you have?

@sampsyo
Copy link
Member

sampsyo commented Mar 3, 2014

We can of course continue the discussion here, but I'm going to close the issue since there is no specific request/bug. You have lots of great feature requests up there, @kooimens, so please open separate (and more detailed) issues for those if you're interested in them. (Or comment on existing issues, such as in the logging request.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants