Command for managing album art filenames

[taylorthurlow]

This has been causing a bit of a headache for me. Originally, I made the mistake of using artwork.jpg as my standard album art image name. I changed it to folder.jpg by mass-renaming instead of changing my config.yml and then updating.

I finally managed to get everything back and stored as folder.jpg by renaming on a case by case basis so that the script was happy about files that used to be 'missing' (renamed).

Now the issue becomes I need to figure out how to force usage of folder.jpg and folder.jpg only. I absolutely hate having others like folder.jpeg, or folder.png. There should be an option to convert to jpg and force lower case on the file name (this isn't often an issue but I've once or twice downloaded something that had an uppercase file extension).

Beets also seems to have some of the files stuck with folder.1.jpg. If I rename it to folder.jpg, the next time I try and do anything with that particular album, it's going to whine and tell me that folder.1.jpg isn't there. Then I'm going to have to go back, rename it, and make beets happy again.

Are there any easy ways to solve this issue that I'm not seeing?

Thanks!

[sampsyo]

Thanks for writing this up. It sounds like what you want is something along the lines of what beet move does for music, which is rename the files to their canonical form according to your path formats. If you change your art filename from "cover" to "folder", for example, this would help track that change. (It would also get rid of needless ".1"s when the conflicting file has been deleted.)

There are two other issues you're describing:

• Normalizing file extensions. You don't like .jpeg and would prefer to rewrite everything to .jpg. (FWIW, I know some other people prefer .jpeg. 😃)
• Transcoding file formats. You want to avoid PNGs by converting to JPEGs.

Do these three features seem to cover what you're asking for? If so, I'm not completely sure how this should be implemented—these are actually three very different behaviors, so they probably don't belong under the same command, right? Do you have any ideas on how to organize all this into understandable components?

[taylorthurlow]

In regards to your first paragraph, that's spot on. An analogue to beet move would be great. I'm not up to speed on the inner workings of how beets organizes an 'album', but seeing as an album can have an associated artwork file, I feel like the easiest thing to do would be adding an extra command which takes a search query. Just like beet ls -a, it would search albums and albums only, and you would be able to edit the associated file, whether it be changing its name, file extension/type, what have you. Of course this would be preferable to tracking changes done to the filename with the OS's native file browser, just make the user rename everything through the beets command line.

For examples sake we could use beet artwork with a couple of modifiers:

• rename newname - Rename artwork without changing extension
• convert jpg/png - Option to convert to another format
  • -e - Embed new converted artwork into each album track

I'm not surprised that people prefer .jpeg, seeing as it's actually supposed to be the standard after Windows started allowing extensions greater than 3 characters, but it is definitely not the norm. Perhaps some sort of option in config.yaml that will let you select between the two? The aforementioned beet artwork command would probably default to .jpg (more widely used) and then if the preferred extension is set in config.yaml then it would use that.

I'm a huge fan of lossless images, but in the context of album artwork, .png files are infuriating. They're gigantic, and a near-lossless .jpeg does the job just as well.

I did describe 3 different issues, but we could solve all 3 using the same artwork manipulation command. Naturally this is just speculative and I haven't looked much at the source of beets, but it seems to be in line with how it operates currently.

[sampsyo]

This all makes sense; thanks for elaborating.

With the exception of file format transcoding, most of this seems to overlap with things that would be useful for generalized attachments (see #111, beets' Most Requested Feature™). If you're interested, we've got a wiki page where we're trying to design the interface for that feature—it could use some contributions in the CLI area.

It also seems like rolling the name standardization into the move command would be worthwhile. This requires someone to take a look at the code and decide whether it's a straightforward thing to add.