After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 600885 - banshee doesn't store cover art in metadata
banshee doesn't store cover art in metadata
Product: banshee
Classification: Other
Component: Metadata
Other Linux
: Normal enhancement
: 3.0
Assigned To: Banshee Maintainers
Banshee Maintainers
: atim 633858 661550 (view as bug list)
Depends on:
Reported: 2009-11-05 21:47 UTC by javiermon
Modified: 2020-03-17 08:16 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description javiermon 2009-11-05 21:47:38 UTC

Banshee doesn't seem to store cover art in the metadata info of the file, i've tried to do so with an mp3 file from an album with cover in my music collection and then opening the file with easy tag revealed no album art at all. I'm interested in this feature since it's more common to have media players reading this info from the file itself.

Thanks and keep up the good work, banshee rocks!
Comment 1 Bertrand Lorentz 2010-02-04 22:55:49 UTC
*** Bug 608954 has been marked as a duplicate of this bug. ***
Comment 2 springvark 2010-10-01 09:04:09 UTC
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!
Comment 3 Holger Seelig 2010-11-03 20:39:39 UTC
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!
Comment 4 Holger Seelig 2010-11-03 20:48:37 UTC
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.
Comment 5 Miguel Duarte 2010-11-21 18:51:25 UTC
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.
Comment 6 budo 2011-02-07 02:00:25 UTC
+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.
Comment 7 Matt Sturgeon 2011-02-07 02:08:41 UTC
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").
Comment 8 Thomas Leberbauer 2011-02-11 12:38:36 UTC
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)
Comment 9 Matt Sturgeon 2011-02-11 12:52:03 UTC
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.}
Comment 10 Michael Martin-Smucker 2011-03-01 15:28:43 UTC
*** Bug 633858 has been marked as a duplicate of this bug. ***
Comment 11 rbertran 2011-03-11 18:18:32 UTC
+1 to this feature
Comment 12 JohnC 2011-03-28 18:33:08 UTC
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.
Comment 13 priour.gaetan 2011-04-13 14:24:27 UTC
+1 Really needed feature
Comment 14 rob 2011-09-23 09:28:35 UTC
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.
Comment 15 Michael Martin-Smucker 2011-10-12 13:36:37 UTC
*** Bug 661550 has been marked as a duplicate of this bug. ***
Comment 16 percherie 2011-10-27 10:35:31 UTC
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.
Comment 17 priour.gaetan 2011-10-27 12:41:08 UTC
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)
Comment 18 Felipe 2011-11-25 15:29:29 UTC
(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.
Comment 19 priour.gaetan 2011-11-25 17:11:40 UTC
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.
Comment 20 Felipe 2011-11-25 17:27:43 UTC
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.
Comment 21 Felipe 2011-11-25 17:36:44 UTC
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 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.
Comment 22 rbertran 2011-11-26 11:24:37 UTC
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.

Comment 23 Felipe 2011-12-06 05:35:05 UTC
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?
Comment 24 Andrés G. Aragoneses (IRC: knocte) 2014-02-21 14:39:00 UTC
This would be a nice thing to see as a goal for Banshee 3.0. But no promises.
Comment 25 Rubin Starset 2014-08-06 22:47:07 UTC
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.
Comment 26 André Klapper 2020-03-17 08:16:50 UTC
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 for more info.