Cover Art: not recognizing jpg nor png data

Tags: #<Tag:0x00007f4d5bf60ab8> #<Tag:0x00007f4d5bf60950>

Dear all:

I am trying to contribute to the effort by scanning at least the front page of my CD.

And Musicbrainz seems to set up to discourage people from participating.

I painstakingly scanned the front page with 200dpi resolution (944x944, 8bit RGB).

when I tried to upload to the, it says "unrecognized file."
when i tried to drag and drop to picard locally, it says “Can’t load image: Unrecognized image data

I am using Linux to scan the file. I tried both JPG and PNG format (all are 2.7MB in size). None of them worked.

What have I done wrong?


1 Like

I have never had this error before. What is the exact file name (including the extension)? Perhaps you can upload the image at an image hosting site such as imgur so we can have a look.

I regularly scan in 300dpi PNG format, and upload to MusicBrainz / Cover Art Archive with no problem. In addition to giving us a peek at the images in imgur, maybe move the images to a different system and see if they are recognised as standard-format PNG or JPG. Good luck!

I apologize if this is a stupid question, but it wasn’t clear (to me) how you were trying to upload the image to MusicBrainz. You were trying to add the image on the release page as illustrated below, and it was failing?

I don’t think Picard can upload album art. If I recall correctly, when you drop an image file in Picard it only adds to (or replaces) the image that will be saved in the files being tagged.

The size you mentioned (2.7MB) is quite reasonable and shouldn’t be causing the problem.

Otherwise, I have nothing to add to the suggestions already made by @mfmeulenbelt and @Jim_DeLaHunt. Sorry.

1 Like

By the way, thanks for your efforts!
Cover (and packaging) scans are the best :heart:


Dear all:

I finally figured out what went wrong.

I am using Linux OS to do this kind of work. and due to limitation of this old laptop (the only laptop I have which has a CD player built in), I only have 8GB of RAM. Split between musicbrainz picard, file manager, browser, I don’t have much memory left. Thus, I tried to use command-line based application as much as possible.

For ripping CDs, I uses this thing called abcde. I deliberately set to use freedb to rip info just for comparison sake.

For scanning, i use this commandline called scanimage.

And apparently, there is a bug in scanimage. Eventhough I specified the format to PNG, but the output end up being a bitmap file.

The reason why it took me so long to figure out that the output file is in an incorrect format is because ALL my picture viewing software on Linux is smart enough to show the picture file I scanned despite the extension doesn’t reflect the actual file type.

I only found out about it by trying to display my scanned files in a Windows machine. The software there told me that the file is in different format.

So, everything worked. My first ever uploaded cover art is here:

By the way, the only reason why I use 200 dpi is also because this silly scanimage command: when I specified 300dpi, it automatically changed to something different. what make it worse that x dpi and y dpi are different thus result is actually an elongated rectangle. Only 200 dpi and 600 dpi would remain the same.

Let me know if you think there is room for improvement in terms of resolution, contrast, brightness, etc. I am doing this in a commandline thus I can do this relatively consistently


That could definitely make things difficult. I’d almost expect you to run into CPU bounds with how you described your laptop, but since you say that’s not the problem, I do wonder what DWM you’re using – I only have 8GB RAM on my computer as well, and I only very rarely run into memory issues on Windows (while I dual boot Linux, I keep it to terminal programs as well, though for different reasons, and almost have more memory than I know what to do with over on that side of things). Unless you have several hundred tabs open in Chrome or some other memory-heavy browser, it’s actually kind of impressive.

Just as a note, the extension-not-reflecting-file-type thing is typical on Linux: most things built for it look at file headers (or, often, MIME types derived from them) as the primary means of determining file type, and the file names aren’t usually expected to be more than hints. Windows actually feels a bit archaic to me in how changing a reference to a file can change how it’s (attempted to be) parsed.

Glad to hear you got it sorted out. The image that you uploaded looks good to me. Thanks.

Gnome Shell with Gnome/3.20

And this thing has a memory leak thus I need to log out and log back in every couple days or my computer will grind to a halt…

it is easily for me to mount my NAS using nfs and it is easier for me to look for a specific file using “find” command on Linux.

be able to use command line means be able to do things consistently. scanning CD cover, for example, turned out to be a lot easier using commandline than using anything that has a GUI.

Ah. Memory leaks. Those are always “fun”. And I’m a big supporter of the command line; it often feels more comfortable, and is definitely quite a bit more powerful. But, yeah, glad you’ve figured out how to get around that (particularly sneaky) bug!

I use 600dpi. It’s overkill right now, but I think in 20 years time I’ll be glad I did.
No complaints from the Cover Art Archive yet, and they can always make things smaller :slight_smile:

1 Like

What options did/do you pass to scanimage? Maybe you had a space too much or too little or you said “PNG” and it only understands “png” etc. The file utility (used like file path/to/file) is handy for giving you more information about what a file is and should be able to tell you whether an image is JPEG, BMP, PNG, or something else, regardless of its file extension. :slight_smile:

Do you know/use tmux (or screen)? They will allow you to keep a terminal session going even when you’ve logged our of your graphical desktop environment.

Veering a bit offtopic, consider checking out whipper. It only supports MusicBrainz, so no FreeDB lookups, but aims to be a bit-perfect ripper (ie., you can write your ripped files to another disc and get a disc identical to the one you ripped).

1 Like
  1. it turned out that scanimage only support bitmaps or tiff as output. this doesn’t pose a problem since I use imagemagick to trim the bottom and right as part of process anyway

  2. i vaguely remember something similar to tmux. but it looks a bit complicated thus I probably will not look into it, and focusing on ripping CDs instead.

  3. there is a reason why i deliberately uses freedb to rip CDs. Yes, I am aware that freedb data quality is questionable at best. but, bad quality data, during ripping process, is actually better than no data at all: having some data means I can go back and look at the file name and figure out which album are these flac files from. and so far, slightly less than 40% of my CD collections are NOT in the musicbrainz database.

whipper looks interesting. but it doesn’t have existing package for my distribution. do I really want to distract another hour try to compile it? or should i just go with whatever available and knowing that the quality of ripping is, for most part, insignificantly less than I could of done? I am not sure.

Mind you that I am still on picard/1.3x for the same reason: the newest version is not yet available on my system. The dangerous of using Linux is that all these incremental things may become distraction and prevent me from doing the actually work I need to do.

If there is a 64bit deb file somewhere for my distro (ubuntu 16.10 x64), let me know. otherwise, I will try to focus get as many CDs as possible, while uploading cover art when I can.

Running python programs from source is usually straight forward.
Clone the repository and follow the instructions in README or INSTALL should let you know what requirements you need to install first and how to compile and install the program.

If you want to run picard clone the repository, use pip to install python packages (as your user or root).
You can then run picard from the source directory or install this to /usr/local/ by running install

You really only need a couple of commands to use screen or tmux. screen uses Ctrl-A to go into "command mode’, tmux defaults to using Ctrl-B. Once in command mode d will detach your current session, and you can then resume using screen -r (for screen) or tmux attach (for tmux). And that’s really all you need to know to get started with either.

I figured that would be the reason. Have you considered adding them to MusicBrainz first, before ripping them? That way the information would both be in MusicBrainz for your ripping, but it would also be in MusicBrainz for the ones coming along next. (I usually use for this, but it can be done via Picard as well. I like because it also allows me to submit ISRCs…)

whipper is a Python program and as such doesn’t require compilation, as @dns_server says. Version 0.5.1 was released recently which removed one of the dependencies blocking adoption in some distributions, while another possible distribution block has been removed in the latest git code, but hasn’t been released yet. Anyway, what I want to say is that it might soon become packaged for you. :slight_smile:

Anyway, to run it from source, check out the installation part of the README:

/me tries really hard to not comment on the horrors non‐rolling release distributions…

straight forward, huh?

$ whipper cd -d /dev/cdrom rip
Traceback (most recent call last):
  File "/usr/local/bin/whipper", line 11, in <module>
    load_entry_point('whipper==0.5.1', 'console_scripts', 'whipper')()
  File "/usr/local/lib/python2.7/dist-packages/whipper-0.5.1-py2.7.egg/whipper/command/", line 30, in main
    cmd = Whipper(sys.argv[1:], os.path.basename(sys.argv[0]), None)
  File "/usr/local/lib/python2.7/dist-packages/whipper-0.5.1-py2.7.egg/whipper/command/", line 101, in __init__
  File "/usr/local/lib/python2.7/dist-packages/whipper-0.5.1-py2.7.egg/whipper/command/", line 101, in __init__
  File "/usr/local/lib/python2.7/dist-packages/whipper-0.5.1-py2.7.egg/whipper/command/", line 88, in __init__
  File "/usr/local/lib/python2.7/dist-packages/whipper-0.5.1-py2.7.egg/whipper/command/", line 297, in handle_arguments
    raise ValueError("Drive offset is unconfigured.\n"
ValueError: Drive offset is unconfigured.
Please install pycdio and run 'whipper offset find' to detect your drive's offset or set it manually in the configuration file. It can also be specified at runtime using the '--offset=value' argument

Seems like it’s working perfectly, but you haven’t configured it as per

i have been using Linux on and off since 1990. but not familiar with python.

it is NOT straight forward for those who are not familiar with python.

when something is missing, I expect simply install the missing packages from my distribution’s package manager. pycdio can not be found in my package manager.

this thing require to compile and install some forked version of accuraterip and installed it manually, which I usually try to avoid because while “make install” is easy, UNINSTALL them is next to impossible and as time drags on, my system will be littered with all sort of junk that I can’t get rid of. In this regard, package management system is far more superior from a maintenance point of view.

i have no idea what egg file is, and where to put it. a quick search using easy_install complains that it can’t find rest of python libraries which i installed via package manager (libcdio, libiso9660, etc). obviously, i need to define some sort of library path for python.
and… i have no idea what swig is.

this is precisely the rabbit hole i want to avoid: i want to focus on ripping CDs. but any of these things, each step may take 5 minutes, but soon hours will be spend for those who are not python developers and not have the python development environment setup.

so, no, whipper is not ready for the prime time unless you are a python developer. stop wasting my and every one else’s time and pretend it is easy and straight forward. most people in the world has better things to do other than getting familiar with python development environment.


It might not be straight forward, but it’s also not as complicated as you’re making it out to be. The last line of the error is pretty clearly stating what you need to do: ensure you have pycdio, and then run whipper offset find.

Maybe Ubuntu (which I assume you’re using, given your package-manager-only mentality) doesn’t include pycdio in the official repositories, but a quick search of the two distros I’ve used gives me the packages I’d need for it – not helpful for you, but a lack of a release on one distro doesn’t mean its support is deficient in any way. More immediately, even if I didn’t have some experience in Python (or notice when @dns_server mentioned pip), I can figure out how to install packages natively from the first result of a basic search.

Moreover, nobody is saying that this is “select-from-package-manager ready”. The fact that all the links have been to GitHub makes that clear. That does not mean it’s “not ready for prime time” and certainly not that people are trying to waste your time. Some source-based installs are pretty involved; this is almost as simple as you can get without a package manager.

1 Like

I encountered the same error message when uploading a PNG file. I fixed it by importing it into GIMP and exporting it.