*** Bug 608954 has been marked as a duplicate of this bug. ***

Any updates to this? I noticed that 1.8 does not include this bug as a fix. It would be great if artwork could be copied to metadata tags. Thanks!

I am interested  in this feature too. Besides the option "save metadata in files", there should be an option to store the cover in the audio files. There should additionally be a button or menu point or so, to update the audio files with the covers stored in ~/.cache/... so that everything is up to date. And in the context menu point "edit metadata" (i guess its so named in english) dialog of the audio files, when selecting multiple files, there should be such button (as known from the artist entry) besides the cover to update all files (assigning the cover to all selected files).

Thank you!

A story from me:
A folder name .cache is for a not important folder, so I deleted it. And what happened banshee had no cover arts at all. To my luck a had a backup and restored it. I think it not the best idea to store the covers only in there, in a hidden folder far away from the music library.

I just started using Banshee and this problem is also irritating me. If it doesn't save the cover art on the file, at least, Banshee should use by default the album art that exists (if exists, of course), on the album folder.

I've multiple computers and it doesn't make sense to have to replicate the banshee cache directory to change the album art in all of them.

+1 to add this feature please.

Hi, could you tell us if something is planned to sort this out ?
It is really anoying especialy when you sync your songs to a portable device and then you get no album art since everything is located in some cache directory inside your home computer :-(
So far, we have to use another tool to update our album art inside the music file itself: not practical at all and might be dangerous.

I don't get it ? Is there a technical difficulty to save the album art inline ? or is it just a "choice" to not do so ?

Thanks for your work anyway. Tried a lot of other mp3 players and i find Banshee to be more straightforward to use and yet powerfull.

From France.

I think regarding why no ones working on this: time.
It really is that simple, Banshee is developed by a bunch of volunteer developers, who each choose, as individuals, which bugs/features to work on: i.e. no one's getting paid to fix all the boring bugs.

Obviously, a feature/bugfix is more likely to be implemented if most of the design work is already done for the developers, so all they do is quickly knock up some code to implement a design idea and commit a patch.

It should be fairly simple for someone experienced with meta tags on various formats, C# and banshee's code to add a function to do this, and then add checkboxs in the Preferences to enable/disable this in a couple circumstances (like "enable when synchronizing with portable media devices" and "enable").

This is definately an important feature that needs to be added, but it should not be limited to saving album art in files. Many people save the album cover as a JPEG in the album folder. 

Consequently this propably fits best in "Sources" > "File organisation" as a list where you can select one of these:
  * Save album art in files
  * Save album art to directory

For the second option there should be a text field to enter the desired filename (this is where most people would probably put 'folder' or 'cover', which makes them perfect candidates for a default value)

I think for ID3 tags, it is possible to set the Album Art field to a reletive URI, for example "Cover.jpg". If this is the case, this should be default behaviour for "Write metadata to files".

Saving the image embedded in the file should be a seperate option.

Also, it would be neccisary to sync album art with music if the Album Art tag is a URI/URL.

And it should be an option to save Album Art embedded within files, only when syncing.


...In an ideal world. But all thoes options would make the interface way too complex, so, to pick a few:

Anything sync-specific should be in the menus that you get when a sync-able device is mounted.

If("Write metadata to files" == true){tag the album art URI in the Album Art field.}

Make a new checkbox: "Embed albem art within files (may make files fairly large)"
If("Embed albem art within files (may make files fairly large)" == true){Embed the album art in the Album Art field.}

*** Bug 633858 has been marked as a duplicate of this bug. ***

+1 to this feature

Ubuntu 10.10 64bit
Same issue. On a clean installation banshee has to fetch all the songs' cover art despite me saving them into metadata with banshee.

+1 Really needed feature

i think we really need this feature, i mean if banshee already does the job downloading all the artwork, why not store in the metadata of the audio files. s

please consider that as an option for future releases if possible.

*** Bug 661550 has been marked as a duplicate of this bug. ***

The report is open for a long time and the development does not seem important for the team. May be that you lack ideas for this feature.

One idea would be to offer options in the recording of album art:
  * .cache Folder / media-art
  * This is the folder where the file (problem if large pouch)
  * The tag mp3 (keeps information)

In the meantime, I disable the automatic search of covers, it filled my drive and unnecessary mess false search to fill the bag tag.

I can see pros and cons for each of those 3 options, so I think it would be nice to have it as an option and able to chose between:

- Have banshee manage the cover art (.cache or in .local/...) [default]
- Save the cover with the file (would this work with FLAC/WAV though?)
- Save the cover in the folder where the file is (my preferred option)

(In reply to comment #17)
> I can see pros and cons for each of those 3 options, so I think it would be
> nice to have it as an option and able to chose between:
> 
> - Have banshee manage the cover art (.cache or in .local/...) [default]
> - Save the cover with the file (would this work with FLAC/WAV though?)
> - Save the cover in the folder where the file is (my preferred option)

I like your suggestion, it might not work for FLAC/WAV like you said, but as long as you put a small note or warning for the user it shouldn't be a problem. I prefer saving the cover inside the file, since the majority (if not all) of my music is in mp3 and ogg. This way when I move a file or even share it with somebody, I don't have to be sending a cover file just so the picture can be displayed.

The only drawback of saving the picture cover in the file itself is that it takes quite a lot of extra space, compared to having it stored in the folder where the file is. I'm taking the example of a randomly selected picture cover in my library, 166k, if saved in the folder, that's all it adds, but if saved within each files that's an additional 2822k. I doubt all picture cover will be so big but I have 1469 folders in my library so the effect would be quite significant.

Wow, those are big pictures. You are right that cover files are that big (really wow! that's too big)
I never use high quality pictures, mine are max 25k (they are usually 10k) so only a max of 25k (usually 10k) are stored inside the file.
That is less than the cover file store in the folder.

On another subject, wouldn't this be best implemented as an option?
Like percherie said, maybe developers don't have a clear path of what to do.
Letting the user decide is the best way.
I know sometimes there are many different ways user like there's stuff so developers can't address all of those. But I think in this case there are only three clear options and those options were explained by priour.gaetan@gmail.com post 17th.

Is there anything that we could do to help the developers accomplish this? besides programming since I don't know how to.

PS: I meant "cover files aren't that big" in my previous post.

After reading the recent comments, it looks like there is not a clear path to follow. So, I think the best solution is to implement this feature as an option. But, as Felipe pointed out, the user should be warned about some format incompatibilities. Regarding the cover file size issues, why not to apply the same solution? just warn the user. Another option could be to add an option to choose the size/quality of the embedded pictures. 

I'm interested in embedding the cover to the files because, in my opinion, is the most portable/general/self-contained solution. Having a cover picture per folder is not applicable when the user mix songs from different albums in the same folder and as a result forces the user to use a particular file organisation. The other option, letting banshee to manage the cover art, forbids the user to change the media player unless he/she wants to fix all the cover art. So, please consider this features for upcoming releases.

Thanks,

I've notice that under the community plugins of Banshee there is one called "Album Art Writer" which writes the Album Art from the cache to the folder containing the music files.

One of the options has been implemented, so for everybody that was looking forward to this, there is an option. However, the other option (the one I'm rooting for) hasn't been implemented yet.

Is there a way that Banshee can write the Album Art to the ID3 tag?

This would be a nice thing to see as a goal for Banshee 3.0. But no promises.

I just wasted a few days adding cover art to a library of around 20k songs only to find out that none of it is written into the ID3 tag of any of the tracks even though I have the tick box set to save all metadata into the file. Please fix this or correct the text for that sitting to state it doesn't consider album art as metadata. Thanks.

Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Please feel free to reopen this ticket (or rather transfer the project
to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the
responsibility for active development again.
See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.