I cannot replicate this. Do you still get the same error? Which plugins do you have installed? Do you have any particular kind of tagger script?

I've tried with the flac you uploaded, tagging against http://musicbrainz.org/release/5f7fe622-0646-4f06-acf1-69bcf7c11ac4 with release+track relationships; no plugins enabled and no tagger script - rename+move disabled.

Unfortunately I can't replicate this. Please re-open if you can still reproduce this problem on 0.16 and I'll try and replicate it again.

Sorry for the late response. It does seems to be working now in 0.16.

Not late, no worries I tried in 0.15.1 as well and couldn't replicate it there either Not sure what's up...

Managed to recreate this bug (or something that looks an awful lot like it) in Picard 0.16 with only the Local Cover Art plugin enabled. No tagger scripts.

FLAC file: Here temporarily
Offending jpg: Here

1) Drag & drop FLAC file into Picard.
2) Lookup (it should load up this).
3) Save.
4) Same error I first reported.

Just appears to be that particular jpg that does it. Resaving that jpg in an image editor and using it again results in the the FLAC saving just fine though.

I had the same error & trace, same setup (FLAC files, JPG, local album art plugin) (on Arch Linux, however).
The problem was solved by renaming the 'cover.jpg' to 'cover.jpeg'.
I don't know anything about the jpeg file format, or whether this was even relevant, but renaming the cover was the only change I made.

Which particular local cover art plugin are you talking about? There were quite a few variations.

(Deleted earlier comment - sorry, appears the mediafire download had become corrupt; can replicate now)

OK, so the problem here has multiple causes; and multiple possible solutions.

That image has EXIF format data. This means it has a different header (\xff\xd8\xff\xe1 vs the \xff\xd8\xff\xe0 that Picard is expecting) It looks like it was created directly from a scanner without post processing. The reason re-saving it works is probably that it re-encodes it as JFIF metadata.

It causes a problem because FLAC requires the mime type, and the local cover art plugin is relying on Picard to detect it based on looking at the data. Picard's current test does not detect this as a jpeg.

This means that it cannot get a mime type for the image which FLAC needs to save the file; so it fails.

Two possible actions; both should probably be done:
1) Josh Sanders' Local Cover art plugin could pass the file name as a secondary parameter on line 61; this means it at least has a fallback if it can't work it out from the data itself

mime = mimetype.get_from_data(data, fileName)

2) It should probably fail more gracefully if it cannot work out the mime type as well, rather than passing an empty type through.
3) I'm not super familiar with JPEG, EXIF, JFIF etc but I believe the test for JPEG could be changed to only check for \xff\xd8\ff and ignore the application segment. I will follow up on this.

I made this change locally and saved this directly from the EXIF-JPEG: http://www.mediafire.com/?yd5szuifeuff5gz - can you guys see whether it works/renders correctly on your players/tools? It looks fine to me in VLC and MediaMonkey - that's all I tried.

Review/discussion at https://github.com/musicbrainz/picard/pull/45

can you guys see whether it works/renders correctly on your players/tools? It looks fine to me in VLC and MediaMonkey - that's all I tried.

I can confirm the cover art is displayed okay in Winamp

Merged in 538453484ed84c395dbadca3415b4f4a53715cad