MP3 Metadata: How to View, Edit and Remove It Safely

The Two Metadata Families and Their Hard Limits

An MP3 file carries audio encoded per ISO/IEC 11172-3 and ISO/IEC 13818-3, but its metadata exists in a separate, optional layer that players parse independently. Two incompatible systems coexist in most files.

ID3v1 is a fixed 128-byte footer appended after the final audio frame. Its structure: a 3-byte identifier (TAG), then 30-byte fields for Title, Artist, Album, Year, Comment, and a 1-byte Genre index drawn from a predefined list of 80 values (later extended to 148). ID3v1.1 repurposes byte 125 of the Comment field as a Track Number, leaving 29 bytes for the comment. Hard limit: track numbers 0–99 only. Values above 99 are stored as zero. No Unicode support exists—characters are interpreted according to the player's system codepage, producing mojibake when a file authored on a Japanese system plays on a US device.

ID3v2 is a block-based header system placed before the first MP3 audio frame. Three major versions exist: 2.2 (uses 3-character frame IDs), 2.3 (4-character frame IDs, widely adopted), and 2.4 (adds synchronization-safe integers and multi-value fields). These versions are not fully backward-compatible. A player expecting v2.4 frames may silently drop v2.3 frames, or a v2.3-only parser may choke on v2.4's new footer feature. The header includes a 10-byte structure with a size field encoded as a 28-bit synchronization-safe integer—each byte uses only 7 bits, with the high bit always zero. A single bit error in this field causes the player to misread the tag boundary and skip valid audio frames.

Frame Types That Alter Playback Behavior

APIC (Attached Picture)

Stores embedded album art. Most players render only the first APIC frame and ignore subsequent ones. Adding multiple art frames does not provide fallback behavior—it wastes space and risks confusing parsers. The MIME type byte must match the actual image data. A APIC frame declaring image/jpeg (MIME type byte 0x03) that contains PNG data will cause the player to display nothing or, on some embedded systems, crash during track transition. Maximum safe image size is player-dependent, but 500×500 pixels and under 100 KB avoids decoder timeouts on automotive and portable hardware.

TXXX (User-Defined Text Frame)

Freeform key-value pairs stored as description\0value. Applications inject custom data here: foobar2000 writes replaygain_track_gain and replaygain_track_peak; MediaMonkey stores ratings as SDB:RATING; MusicBrainz Picard writes AcoustID fingerprints. A misspelled key is silently ignored. A value containing a null byte in the wrong position truncates the string at the break. If a smart playlist depends on a TXXX frame and the key case does not match exactly (e.g., REPLAYGAIN_TRACK_GAIN vs. replaygain_track_gain), the playlist engine will treat the track as unanalyzed and skip it.

COMM (Comments)

Carries a 3-byte language code per ISO 639-2, followed by a short description and the comment text. A language code of XXX (undefined) or raw bytes outside the a–z range causes strict parsers to reject the entire frame. Some tagging tools write eng by default; others leave the field null. A null language descriptor is technically invalid per the ID3v2.4 spec and may cause the tag block to be discarded.

USLT (Unsynchronized Lyrics)

Stores lyrics with a 1-byte content descriptor (0–255), a language code, and a description. If the descriptor byte is missing or the frame length does not account for it, the player may display raw binary as text or fail to populate the lyrics panel. Descriptor values are application-defined; no standard mapping exists.

Synchronization Hazards Inside the Tag

ID3v2.4 introduced an unsynchronization scheme that prevents the byte sequence 0xFF 0xFE (or 0xFF 0xFF) from appearing inside tag data, because these patterns can be misread as MPEG audio frame sync markers. When the unsynchronization flag is set in the ID3v2 header, any 0xFF 0x00 sequence in the tag is interpreted as a literal 0xFF. If a tool writes 0xFF 0xFB (a valid MPEG1 Layer III sync word) into the tag padding without setting the unsynchronization flag, some decoders will lock onto that offset as the start of audio, producing a loud click or burst of noise at playback start. This is not fixable by re-editing the tag—the entire ID3v2 block must be stripped and rebuilt from a clean source.

Viewing Metadata Without Modification

ffprobe (Read-Only Inspection)

ffprobe -v quiet -print_format json -show_format -show_streams file.mp3

Returns a JSON object with format.tags (ID3v2 frames) and streams[0].tags (per-stream metadata). If format.tags is empty but a TAG key appears in the raw output, the file has only ID3v1. No file writes occur. Duration, bitrate, and sample rate appear alongside tags, providing a baseline for later integrity checks.

exiftool (Full Tag Inventory)

exiftool -a -G1 -s file.mp3

The -a flag surfaces duplicate frames. The -G1 flag groups output by tag family: [ID3v2], [ID3v1], [MPEG]. This is the only reliable way to detect conflicts where ID3v1 and ID3v2 carry different values for the same field. A file with ID3v1 Title set to Track 01 and ID3v2 Title set to Actual Song Name will display differently depending on which tag family the player prefers.

Editing Operations with Observable Results

Removing Album Art Only

exiftool -APIC= file.mp3

This deletes all APIC frames while preserving text frames, replaygain data, and gapless metadata. Verify with exiftool -G1 file.mp3 | grep -i "picture"—the command should return nothing. File size will decrease by the total byte count of the removed images. Do not substitute -All= unless stripping every tag is the explicit goal.

Stripping ID3v1 While Retaining ID3v2

mp3info -d file.mp3

Removes the 128-byte ID3v1 footer. Confirm removal with exiftool -G1 file.mp3 | grep ID3v1—no output means the footer is gone. Audio data is unaffected because the footer sits after the last valid MPEG frame. Use this when a legacy player reads ID3v1 in preference to ID3v2 and displays conflicting values.

Writing a Track Number for Legacy Hardware

id3v2 -T 12 file.mp3

Writes track number 12 to both ID3v1.1 (byte 125) and ID3v2 (TRCK frame). To restrict the write to ID3v1 only, use id3tag --track 12 file.mp3. Test on the target device immediately—some automotive players require the ID3v1 Genre byte to be non-zero before they will parse the track number.

Data That Should Be Removed Before Distribution

URL Frames

The WXXX (user-defined URL), WCOM (commercial URL), and WOAF (official audio file URL) frames can contain arbitrary links. Some library managers fetch these URLs automatically for artist bios or cover art. A URL pointing to a tracking server exposes listener behavior. Strip all URL frames with:

exiftool -WXXX= -WCOM= -WOAF= -WPUB= file.mp3

Encrypted Frames

ID3v2.3 and v2.4 support per-frame encryption via a method byte and a registration identifier. If the encryption flag is set but the player lacks the key, behavior is undefined: the frame may be skipped, displayed as garbage, or cause the parser to abort the tag block entirely. Detect encrypted frames with exiftool -a -G1 file.mp3 | grep -i "encrypt". No standard decryption method exists for consumer playback; remove these frames or strip the entire ID3v2 block.

Post-Edit Verification Sequence

After any metadata change, run three checks:

1. Duration stability: ffprobe -v quiet -show_entries format=duration -of default=noprint_wrappers=1:nokey=1 file.mp3 before and after editing. A difference exceeding 0.01 seconds indicates the tool shifted the boundary between the ID3v2 header and the first audio frame.

2. Frame inventory: exiftool -G1 file.mp3 | grep -c "ID3v2" compared against a pre-edit count. Fewer frames means the tool dropped data silently.

3. Cross-parser playback: Open the file in VLC (uses its own tag parser) and foobar2000 (uses a different implementation). If one shows the title and the other shows "Unknown," a version mismatch or corrupted frame header is present.

Recovery from a Malformed ID3v2 Header

When the 10-byte ID3v2 header contains a size field pointing past the end of the file, or the header identifier bytes (ID3) are corrupted, no tool can extract the existing tags. The only path is to delete the entire ID3v2 block and rebuild metadata from external sources:

exiftool -ID3v2= file.mp3

This locates the first MPEG frame sync word (0xFF 0xFB or 0xFF 0xF3) and writes audio starting from that offset. The output file contains no ID3v2 data. If an ID3v1 footer was present, it survives the operation. The Library of Congress format description notes that the ID3v2 specification allows the tag to appear anywhere in the file, but in practice a tag placed after the audio data is nonstandard and will be ignored by all common players—this condition is effectively irrecoverable without manual hex-level reconstruction of the original tag offset.

Reference: Library of Congress, Sustainability of Digital Formats: MP3 (MPEG Audio Layer III), https://www.loc.gov/preservation/digital/formats/fdd/fdd000012.shtml