Album Art Missing After Converting Audio

Embedded cover art is stored as a picture stream inside the audio file, not as a text tag, and most converters drop picture streams when they re-encode. Text fields such as title, artist, album, year, track number and genre travel separately, and they usually survive the trip. That is why a converted track so often shows the correct song name next to a blank grey square. Our own [browser-based audio converter](/convert-audio) behaves the same way: the ffmpeg command it runs includes the `-vn` flag, which tells ffmpeg to ignore every video stream, and an embedded cover counts as a video stream. We confirmed that by hand, and the numbers are in the next section. If your file lost the text fields too, that is a different problem with a different cause, covered lower down, because the usual reason is that the source file never carried those fields in the first place.

We built a FLAC file carrying a 1400 by 1400 JPEG cover plus six text tags (title, artist, album, date, track, genre), then ran it through the exact arguments our converter passes to ffmpeg for each of its four targets. The cover was gone from the MP3, WAV, OGG and M4A outputs every time. Every text tag came through. We repeated the test with an M4A source carrying a cover, converting to MP3, and got the same result: art gone, tags intact. Two caveats we will not paper over. We ran ffmpeg 6.1.1 on the command line with the same arguments the tool uses, rather than driving ffmpeg.wasm inside a browser, so this is the engine behaviour rather than a click-through of the live page. And we did not check how any particular player renders the result, so we cannot tell you whether Apple Music or your car stereo shows the tags that survived.

In our test, all six text tags reached the MP3, WAV and M4A outputs intact. The OGG output was the odd one out in an interesting way: the tags were there, but ffprobe reported them as stream-level Vorbis comments rather than in the container-level metadata block where it lists MP3 and M4A tags. Any tool that only reads container-level metadata will therefore call a perfectly well-tagged OGG file untagged. If you are choosing a target format partly for metadata, that is worth knowing before you convert a whole library. WAV deserves its own warning: ffmpeg wrote the tags into the file, but WAV's tagging support is an afterthought bolted onto a container that predates it, and plenty of software ignores it. We did not test which players read those WAV tags.

The `-vn` flag means no video. It exists so that converting the audio out of a video file gives you audio, not a stalled job trying to re-encode a thousand frames of picture you did not ask for. That matters when you are pulling an MP3 out of an MP4, where the video stream is genuinely unwanted. The side effect is that ffmpeg cannot tell the difference between a feature film's video track and a single still image flagged as attached cover art, because at the container level they are the same kind of stream. Drop one and you drop the other. This is not a bug specific to any one tool. The forum threads blaming individual desktop converters for losing artwork are usually describing the same mechanic, reached through a different interface.

Here is the part the forum threads do not mention. We converted the same tagged FLAC to MP3 three ways and compared bytes. With `-vn`, dropping the art, the MP3 came to 283,605 bytes. Simply removing `-vn` kept the art but let ffmpeg re-encode the JPEG cover as PNG, and the file ballooned to 1,687,835 bytes: the artwork was then about 83 percent of the file. Adding `-c:v copy` kept the cover in its original JPEG form and landed at 547,888 bytes. So the lazy way to keep your artwork added roughly 1.4 MB to a one minute track, more than five times what copying the picture across cost. If you are converting a library to save space, as people usually are when they [convert FLAC to MP3](/blog/flac-to-mp3), that difference is worth more than it looks.

You do not have to convert the file again. Artwork can be attached to a finished MP3 without touching the audio, so there is no second generation of lossy compression and no quality cost. On the command line, feed ffmpeg the converted MP3 and the cover image, map both, and copy both streams rather than re-encoding them. We did exactly that with our art-less 283,605 byte MP3 and a 1400 by 1400 JPEG, and got a 585,953 byte file with the cover attached as an untouched JPEG stream. If the command line is not your thing, a desktop tag editor such as Mp3tag does the same job by drag and drop, and music players including iTunes and MusicBee let you paste artwork onto a track directly. Any of these is faster than re-running the conversion and hoping for a different outcome.

A good share of missing-artwork reports start with a source file that never had embedded art. In a lot of music libraries the cover is a separate `folder.jpg` or `cover.jpg` sitting beside the tracks, and the player composes the two at display time. Convert the audio and that loose image stays exactly where it was, pointing at files that are no longer in that folder. Open your original in a tag editor and confirm the picture is actually inside it before concluding anything about the tool. The same confusion shows up with photos, where people assume an image carries data it never held, which is the territory [EXIF metadata](/blog/what-is-exif-data-and-why-strip-it) covers. If the source has no embedded cover, no converter on earth can carry one across.

Convert first, then re-attach the artwork, because attaching a picture is free and re-encoding the audio is not. Expect your text tags to come through; expect the cover not to. Before you start a batch, run one file through and inspect the output in a tag editor rather than trusting what a player shows you, since players cache artwork and will happily display a thumbnail for a file that no longer contains one. If you are moving a library between formats, settle the format question first, since bitrate and container choice are harder to undo than artwork is: [what bitrate actually controls](/blog/what-is-bitrate) and the practical notes on [M4A to MP3](/blog/m4a-to-mp3) and [WAV to MP3](/blog/wav-to-mp3) cover the trade-offs worth deciding up front.