Album art for singletons

[ghost]

This issue was automatically migrated from Google Code. Original author: adrian.sampson (May 08, 2011 22:46:16) Original issue: https://github.com/google-code-export/beets/issues/186

[udiboy1209]

For starters, we could directly embed the art found into the metadata of the music file, rather than storing it in an external file and worrying about the database. This could at least enable one to obtain art(in some form) for singletons.

PS Sorry for opening a new issue(778), didn't see this one!

[Sirove]

It's very disappointing to see that this is an issue since 2013 with multiple duplicates and it still isn't resolved... :( This really is the main reason for me I cannot switch to Beets yet although I honestly want to very much!

[sampsyo]

Hi, @Sirove—may I offer a little bit of etiquette feedback for how to interact with open-source projects?

It can be frustrating, as an open-source developer, to hear people say they're "disappointed" and to express sadness about how long issues tend to remain open. This kind of comment reminds me of what's appropriate to say when you're a customer of a service you're paying for: it's totally legitimate, for example, to say that you're disappointed that your hotel's elevator has been out of service for too long. But in open source, where we're all volunteering our time and trying to foster a sense of shared commitment, responsibility rests equally with everyone. So if you're disappointed that this feature hasn't been implemented yet, please don't be disappointed with the volunteer developers of the project—be disappointed with yourself for not making it happen already! Try to remember that no one "owns" beets, so every bit of progress—or lack of progress—belongs to the entire community.

If I may, I'd suggest phrasing this kind of thing differently. For example:

I would really like to see this feature implemented! It's the main thing keeping me from switching to beets. I also notice that there have been several duplicates since it was opened in 2013, which suggests that other people are interested in it too.

I would love to help get this implemented if I can! I am not a programmer myself, but I can help by creating a detailed design for the implementation or by sponsoring someone on Bountysource who's interested in doing the implementation.

[Sirove]

I understand and I'm sorry that my comment frustrated you! Didn't want to "blame" someone for something that's already as powerful as it is. Honestly, I understand how many hours the community and especially you must have put into Beets. I am truly grateful for that! Thank you for all your work and for taking the time to explain the situation as polite as you did.

[sampsyo]

No harm done!

[rain0r]

I'm trying to work out a solution. What would be the right way to tackle this task?

The fetchart plugin could look up the cover art of an album / ep that's containing the single track in question and download it. After that, the embedart plugin could save it into the file.

Could that be the way to go? If so, it would be great if these two commands don't have to be called manually.

[sampsyo]

I think the first order of business, before looking at the fetchart and embedart plugins, is to do some deep pondering about how to associate album art with individual tracks. We currently have an artpath field for Albums, and there's a bunch of logic in the Album class that helps generate the file path for the image—and to ensure that it stays in the right place when the music files move around.

Would the same approach be the right thing to do for per-track album art? If so, how will we abstract away the file handling stuff so we don't have to repeat it twice, once for Item and once for Album?

Once that's all squared away, I think the next step is probably to think about embedart (before fetchart). Commands like beet clearart need to be extended to work for both albums and items.

What do you think about diving into the code to start laying the foundation for those infrastructural changes?

[wisp3rwind]

Regarding @sampsyo's observations: I strongly believe that the correct foundation for singleton artwork (or in general supporting more diverse kinds of fanart than only front covers) is @geigerzaehler's attachment proposal.

[Behend]

I'm following this issue about a year now. Is there any progress on that?

[sampsyo]

Hello, @Behend—everything we do on this project is "in the open," so if there were any updates, they would be posted here. If you're really interested in seeing this feature implemented, please consider taking the lead!

[WhyDidIHaveToDoThis]

For anyone who is trying to search why using embedart and fetchart, here is the summary and my "solution":

It has never worked, because there is no consensus on how to attach images to music files, only albums. The question is "Would the same approach be the right thing to do for per-track album art?" and the only suggestion was incomplete and shelved. It is a unresolved issue because it is a complex issue. (Sorry if there has been any progress on infrastructural decisions, I couldn't find it on a cursory search.)

My music library is tied to beets now so there's no way I'm giving up on using beets lol. If possible, you can just use a compilation album to add the music and cover into beets that way. But what I did was just give up and use iTunes to embed the cover art.

I will take the advice "be disappointed with yourself for not making it happen already" and ignore it because my fix would be to butcher beets and have all files have images embed disregarding any hope of efficiently storing files, which I doubt would be helpful at all. If it were up to me it will never be fixed, oh well.