MP3 Tags: Do Title, Artist and Cover Art Change the Transcript?

One file, nine rewrites

Each variant below kept the audio frames byte for byte. Only the metadata block in front, or the bytes after the last frame, changed.

• Base file: 75,024 bytes, 160 characters, 31 words, 2.50 s.
• Title, artist and album tags: 75,331 bytes, 160 characters.
• 200 KB of comment padding: 275,053 bytes, 160 characters.
• 1200-pixel cover art: 82,176 bytes, 160 characters.
• 2400-pixel cover art: 82,176 bytes, 160 characters.
• ID3v1 tag appended: 75,152 bytes, 160 characters.
• 500 KB of trailing zeros: 575,024 bytes, 160 characters.
• Filename with spaces and brackets: 75,024 bytes, 160 characters.

The text was identical in all nine

Not just the same word count - the same 31 words in the same order, with the same digit conversions. "10:15" came back as "10.15" in every copy, because that is what the model does with times.

So the metadata block is a header the decoder skips. The model gets the audio frames and nothing else. A 200 KB comment does not slow the transcription down into a wrong answer, and a cover image does not get described.

We planted a sentence in every frame we could

To be sure nothing leaks, we wrote "PURPLE ELEPHANT SEVENTEEN" into the title frame, the subtitle frame, a custom text frame and the comment frame at once. The file returned 160 characters and the phrase did not appear.

• TIT2, TIT3, TXXX and COMM frames all carrying the phrase: phrase absent.
• A CHAP chapter frame carrying the phrase: phrase absent.
• Output was the same 160 characters as the plain file.

That is the answer to the obvious worry. People add titles and notes to their recordings all the time, and none of it gets read as speech.

The one version that failed had no audio

We built a file that was 31 bytes: the three letters ID3, a version, some flag bytes and one title frame. No audio frames at all.

• 31 bytes, 0.75 seconds, success: false, 0 characters.
• That is the correct answer. There was nothing to transcribe.
• It failed fast, which is how you can tell a structural problem from an audio problem.

Compare that to a file with 15 minutes of silence, which returns text. The endpoint does not refuse quiet audio. It refuses files that carry no audio at all.

Big tags cost upload time, not accuracy

The 500 KB of trailing zeros took 9.80 seconds to upload against 2.50 seconds for the base file. Same text, four times the wall clock, because the connection had four times the bytes to push.

• 75 KB base: 2.50 s.
• 275 KB with padding: 3.04 s.
• 575 KB with trailing zeros: 9.80 s.
• Every one returned 160 characters.

That is worth knowing if your uploads feel slow. A tag block does not add much. Cover art and padding do. A 2 MB album cover on a 75 KB memo makes the file 27 times bigger for zero words gained.

Unicode tags are fine too

So there is no encoding trap here. Whatever language your tags are in, they are skipped the same way.

Why a tag would ever be a problem

A tag block sits before the first audio frame. Decoders read the 10-byte header, skip the stated size, and start looking for sync words. That works until the size field is wrong.

• A tag that claims more bytes than it has: the decoder skips into the middle of the audio and finds no sync.
• Two tags stacked, as happens after editing a file twice: some decoders read only the first.
• A tag written by a broken editor with the wrong version byte: the block is skipped as garbage.
• A tag pasted in front of a non-MP3 file: the file looks like an MP3 and is not.

None of these showed up in our nine files, because every tool we used wrote a correct size field. They are the reason a file that plays fine can still be refused, though, and the fix is always the same: re-encode rather than re-tag.

When to bother editing tags at all

Tags matter for your own library and for anything that reads metadata: a podcast player, a music app, a DAM system. They do nothing for transcription.

• Rename and tag for your own filing - it costs nothing and helps you find the file later.
• Do not add a cover image to a file you are about to upload. It only adds bytes.
• Do not strip tags hoping for better accuracy. Nine rewrites produced the same text.
• If a file is refused, look at the audio, not the tag block.

The size arithmetic that matters

Now put a 2.2 MB cover on it and the file is 30 times bigger. The 16 MB upload cap is about audio time, and cover art eats into it. A 30-minute recording at 6 KB per second is 10.8 MB. Add a few large covers and you are at the cap before the audio is.

Tag size, measured

An ID3v2 block can legally be megabytes. Ours were small, and the size of the block showed up only in the upload time.

• Base file with no tags: 75,024 bytes.
• Title, artist, album: +307 bytes, one extra tenth of a second.
• 200 KB comment: +200,029 bytes, 0.54 s slower.
• Cover art at 1200 px: +7,152 bytes, actually faster than the base file on that run.
• 500 KB of trailing zeros: +500,000 bytes, 7.30 s slower.

Two identical runs of the same 12.5-second audio took 2.50 and 2.03 seconds. Upload time on this endpoint moves by a second between runs on its own, so do not read a 0.5-second difference as the cost of a tag.

Tags, chapter markers and lyrics frames

Beyond the four text frames, ID3 supports lyrics, chapters and pictures. We tried a chapter frame carrying a line of text and it was ignored like the rest.

• USLT lyrics frame: not read as audio, no appearance in the text.
• CHAP chapter frame with a title and a description: same 160 characters.
• TXXX custom frame: same 160 characters.
• APIC picture frame: same 160 characters at two resolutions.

The pattern held for every frame type we could build. The decoder looks for the first audio sync word after the tag block and starts there. Frames in front of it never enter the pipeline.

What a tag can still break

That is the honest boundary. A tag block is skipped, but a file made only of a tag block has nothing to skip to. If your editor ever writes a file that ends up smaller than the tag it contains, that is the case you would hit.

Should you strip tags before uploading

No. Stripping costs a re-encode or a rewrite and buys nothing measurable. The one reason to touch tags is size, and size only matters when the file is close to the cap.

• Under 5 MB: leave the tags alone.
• Cover art over 1 MB: remove it, it is the only tag that weighs anything.
• Close to 16 MB: convert to a smaller bitrate rather than stripping tags.
• Refused file: check the audio stream, not the metadata.

What happens to the file you send

It leaves your browser and goes to our transcription endpoint over an encrypted connection. It is decoded in memory once, the text is returned, and the file is dropped. Tags are not stored, not indexed, and not used to name anything. There is no account and no copy kept.