Neatbo.

Embedded artwork bytes are not a screenshot

Why artwork recovery keeps exact payloads, provenance and duplicates, and how finite tag support affects the result.

Decide what you need to keep

AaronD wanted separate artwork from purchased FLAC and confirmed in his own answer that unchanged embedded data met the goal. MP3 questioner k0pernikus also wanted the cover saved separately and preferred a command line. These accounts support one recovery endpoint, without proving browser preference or market scale.

A player screenshot saves the display result, potentially with scaling or interface elements. Image export may change encoding or ancillary data. Exact payload recovery lets a later editor choose transformations while retaining a route back to the audio original.

Equal bytes need not be one record

Two ordinary FLAC PICTURE blocks may contain equal bytes at different source positions. Recovery keeps each number, description, type and offset. APIC descriptor uniqueness is a different rule: duplicate descriptors or icons are refused rather than silently deduplicated.

Declared dimensions and decodability are separate facts

Image and audio codecs are not decoded. A signature-matching damaged image is recovered byte for byte and may fail to open. FLAC dimensions/depth/colours are source declarations, not verified image dimensions; no audio CRC/PCM/playability claim.

Saving original image bytes does not repair an image. The original, payload hash and absolute offset let you audit the extraction location; an image reader determines whether it opens.

Choose a record for the question
QuestionRecord to inspectWhat it establishes
Where did this picture come from?Source name, offset and hash in pictures.jsonThe original payload and its extraction location
What dimensions did FLAC declare?Declared width and height in pictures.jsonSource declarations; no decoded measurement
Will the picture open?The extracted PNG/JPEG in an image readerWhether that reader decodes the original payload

Valid transformations can fall outside the profile

ID3 unsynchronisation can insert bytes on disk, and compression changes the relationship between stored bytes and logical payload. This tool refuses those valid features so that un-restored storage is never delivered as the original image. Unknown frames or a bad source refuse the entire queue, and cancellation leaves no partial ZIP.

Download originals, every numbered picture and full pictures.json/pictures.csv in one pictures.zip. JSON and CSV allow 4 MiB each, ZIP 128 MiB; stricter input limits dominate these protective output guards. CSV textual values receive an apostrophe; JSON/raw hex preserve exact values.

  • Use the original audio and complete JSON when auditing provenance.
  • Use pictures.csv to review the picture list; literal text remains in JSON.
  • Apply any repair or conversion to a separate copy after extraction.

References

Tools in this category

Expand a tool to see its steps, options and supported formats, then open its workspace.

Extract embedded audio picturesRecover every embedded PNG/JPEG payload from local FLAC/MP3 without reencoding, with originals and complete JSON/CSV ZIP.

Select audio originals with embedded artwork, recover every eligible picture in encounter order and download the complete original/picture/report ZIP.

Steps

  1. Select 1–4 audio originals.
  2. Run and inspect every picture type, description, offset and hash row.
  3. Download pictures.zip and open numbered pictures.
  4. Audit full JSON/CSV provenance and keep original audio.

Capabilities and limits

  • 1–4 native FLAC or MP3 files: 50 MiB per file and 100 MiB total; UTF-8 filenames up to 512 bytes. Preserve originals and use the files you own.
  • Native FLAC PICTURE and prepended ID3v2.3.0/2.4.0 APIC only; PNG/JPEG MIME and byte signature pairs. APIC png/jpeg shorthand is supported. Front/back and batch pictures share one extraction task.
  • At most 128 pictures, 4 MiB per payload, 16 MiB total picture bytes, 4096 metadata records, 4096 raw bytes per description and 262144 raw description bytes overall. ID3v2.3 descriptors also allow at most 64 characters.
  • FLAC descriptions use strict UTF-8. APIC supports Latin-1 and BOM UCS-2 in v2.3; Latin-1, BOM UTF-16, UTF-16BE and UTF-8 in v2.4. Literal text and description raw hex stay in JSON.
  • Unknown/reserved metadata, linked pictures, unknown frames, nested/extra tags, duplicate APIC descriptions or duplicate icons refuse the whole queue. Repeated ordinary FLAC pictures, including identical payloads, remain separate.
  • Unsynchronisation, compression, encryption, grouping, data length indicators, extended headers, experimental headers and footers are unsupported even when valid. No de-stuffing, repair or silently skipped tags.
  • Image and audio codecs are not decoded. A signature-matching damaged image is recovered byte for byte and may fail to open. FLAC dimensions/depth/colours are source declarations, not verified image dimensions; no audio CRC/PCM/playability claim.
  • Download originals, every numbered picture and full pictures.json/pictures.csv in one pictures.zip. JSON and CSV allow 4 MiB each, ZIP 128 MiB; stricter input limits dominate these protective output guards. CSV textual values receive an apostrophe; JSON/raw hex preserve exact values.
  • No upload, remote URI fetch, resizing or reencoding. Any malformed, unsupported or over-budget input produces no partial archive; cancellation discards unfinished output.
Open Extract embedded audio pictures →