From the deadwax

Replace the Front Cover. Keep the Booklet.

By Keynell
artworkmetadataformatspreservation

The front cover is small and blurry. The back cover is a good scan, and a booklet page has the recording credits you occasionally want to read. You only came here to improve the front image. Losing the other pictures would turn a simple repair into another collecting task.

A music file can contain more than the one cover a player shows. The visible thumbnail tells you which picture that player selected, not how many pictures the file holds. Before you replace artwork, it helps to know what the format can distinguish and what the editor actually replaces.

Private Press treats a front cover press as a targeted artwork change. On supported structures, it keeps the other embedded pictures. The details differ between formats, especially when a file has duplicate front covers or no explicit picture roles.

A picture can have a job

ID3, the tag format commonly found in MP3 files, stores attached pictures in individual APIC frames. Each can carry an image, a description, and a picture type. The specification distinguishes front cover, back cover, leaflet page, media image, and other roles. It also permits a picture entry to hold a link rather than image bytes. ID3v2.4 attached picture specification.

Those distinctions make a narrow replacement possible. An editor can identify a front cover without assuming every attached image is expendable. A booklet scan stored with the leaflet role has a different purpose from the album's front image.

FLAC also has a PICTURE metadata block with a picture type. The official FLAC definitions include front cover, back cover, and leaflet page types. FLAC picture type definitions.

These structures do not create a booklet browser in every player. A player may show one image, expose several, or ignore a type it does not use. Keeping a picture in the file and displaying it in an app are separate capabilities.

What a front cover press replaces

For MP3 artwork, Private Press replaces the embedded front cover while retaining non-front pictures and picture links. When a tag contains several embedded pictures labeled as front covers, pressing replaces them with one new front. That is a deliberate change: competing old front covers do not remain alongside the replacement.

If there is no embedded front cover, the editor adds one and keeps the existing non-front pictures. Its artwork reader prefers a front cover when one exists, with a fallback to another picture when it does not. That fallback explains how an album can appear to have artwork even though the tag never labeled any image as its front.

AIFF files with supported ID3 artwork use the same picture replacement rules through their ID3 chunk. FLAC pressing likewise replaces front-cover blocks with one new front while retaining the other picture blocks. It edits the metadata and copies the encoded audio payload; a cover repair does not need an audio conversion.

For a hypothetical album with a front, a back, and two leaflet pages, the intended result is one new front plus the existing back and leaflet pictures. If all four were incorrectly marked as front covers, the labels would tell the editor a different story. Accurate picture roles are part of a carefully tagged file.

M4A needs a different rule

M4A artwork does not give Private Press the same front-versus-leaflet type distinction. In the supported MP4 metadata structure, pictures are carried in cover artwork entries called covr. Private Press treats the first data picture in the first covr entry as the front image to replace.

The editor keeps the later pictures in that entry, later cover entries, and their order. This is a defined editing convention, rather than proof that the first image depicts the front of the packaging. If you inherited an M4A containing unusual picture ordering, inspect a copy before applying a large batch.

That difference matters when judging preservation. MP3 and FLAC have explicit roles the editor can use. In M4A, position supplies the choice. Calling every image “the cover” hides information that a replacement operation needs.

Keep the promise within the format's limits

The current editing paths validate the structures they need to rewrite. Some malformed or unsupported structures cause the press to refuse the change. That is useful behavior when the editor cannot establish a supported interpretation of what it would rewrite.

There are also legacy limits. An ID3v2.2 tag is upgraded when edited, and frames without a corresponding supported ID3v2.3 mapping can be omitted. The artwork rules therefore should not be read as a promise that every piece of metadata from every historical tag survives. If a file has rare legacy data you value, keep an original copy and examine the proposed workflow on a small selection.

For ordinary multi-picture files, the practical check is straightforward: inspect the pictures before the press, replace the front, and use a reader that exposes multiple images to inspect the result. A single thumbnail can confirm the new cover looks right. It cannot confirm the back and booklet pages remain.

Private Press's benefit here is specific. You can improve the front image without treating the rest of the album's embedded artwork as disposable. A collector's file may hold the cover you recognize and the credits you need. A careful repair gives each its own place.

Private Press preserves other embedded pictures during supported artwork edits.

See the format-specific editing notes