Misleading tag abstraction causes release of incorrect metadata

Support
1

I am raising this as a formal complaint, not a support query.

MP3tag’s current behaviour around tag handling is actively misleading and has caused me to publish files containing incorrect metadata, despite those files appearing correct within the application at the point of saving.

The core issue is this:

MP3tag presents a merged, logical view of metadata that hides the fact that multiple independent tag containers can coexist inside a single MP3 file (ID3v2.4, ID3v2.3, ID3v1, APE). The UI gives the clear impression that the metadata being displayed is authoritative, complete, and representative of what downstream consumers will read. That impression is false.

In practice:

  • MP3tag can write new values to one tag container
  • Leave legacy containers intact
  • Continue to display only the updated values
  • While other software and upload platforms read the untouched legacy tags instead

This results in a situation where:

  • The user saves the file
  • Reopens it
  • Verifies the metadata visually
  • Uploads it
  • And then sees old, contradictory information exposed publicly

This is not user error. This is a UI and design failure.

I am aware that MP3tag technically supports multiple tag formats. The problem is not capability; it is disclosure and verification. The application does not clearly surface:

  • Which tag containers currently exist in the file
  • Which containers are being written to
  • Which containers are being left untouched
  • That conflicting values may still be present and readable by third parties

The current “merged view” actively obscures risk. For anyone publishing or distributing files beyond their own playback environment, this is unacceptable.

Requesting example files is also not a reasonable workaround when:

  • Files are often large
  • Upload limits prevent sharing
  • External services require login
  • And the issue is structural, not file-specific

This problem does not require reproducing with a sample file to be understood.

What is required is one or more of the following:

  • A clear warning when multiple tag containers exist
  • A visible, per-container view of metadata (not a merged abstraction)
  • An explicit indicator of which containers are present and writable
  • Or, at minimum, a release-safety warning that the displayed data may not reflect what other software will read

At present, MP3tag makes it far too easy to believe a file is “clean” when it is not. That belief is reasonable based on the UI, and the consequences fall entirely on the user when the metadata is later exposed publicly.

I am not asking for new tagging standards. I am asking for honesty and visibility.

If a file contains metadata that I cannot see, verify, or intentionally remove, then the application should not present that file as safe to publish.

This is a serious usability flaw, not a niche edge case, and it deserves to be treated as such.

2

This is visible via the "Tag" column in Mp3tag's File List. The Extended Tags window also indicates different tag versions.

This is not going to happen. If you need this, please use a different app. I can recommend kid3, which offers direct editing of different tag versions.

Also, I'm growing tired of your repeating complaints, often posted as bug reports, where it simply doesn't offer the functionality you like it to have. Maybe Mp3tag is really not a good fit for you.

Moving this to Support

3

In my example file, MP3tag shows clean, correct ID3v2 metadata. MediaInfo also shows clean, correct semantic fields. Based on everything visible in both tools, the file appears safe to publish.

However, when the same file is uploaded to dnbshare.com, the site displays an old, human-written string: “3rd February 1996”.

That string is not being generated or reformatted by the site. It is not a date conversion. It is literal text that exists somewhere in the file.

After deeper inspection, the reason is that the file still contains a legacy Lyrics3 v2 block with human-written text inside it. MP3tag does not expose Lyrics3v2 in the UI, does not allow it to be shown as a column, and does not warn when it exists. MediaInfo normalises it away in the general view. But the upload platform reads it and displays it.

So from the user’s perspective:
• MP3tag shows nothing wrong
• MediaInfo shows nothing wrong
• The file is uploaded
• Old text appears publicly

This isn’t about recovering broken tags or importing non-standard metadata. It’s about visibility and release safety. There was metadata in the file that was readable by third parties but invisible in MP3tag, with no indication that it existed.

I fully understand that MP3tag only edits real tag containers and that Lyrics3 is deprecated. My point is simply that if metadata can still be read and surfaced by other software, then its existence needs to be visible or flagged before publication.

In this case, the only reliable solution was to strip Lyrics3v2 entirely using external tooling, because MP3tag does not currently provide a way to surface or columnise it.

Hopefully that clarifies the scenario. This isn’t a theoretical edge case or a single broken file. It’s a real-world failure mode when managing large libraries that have passed through multiple tools over time.

Thanks for taking the time to read, and for the work on MP3tag overall.

4

Thanks for clarifying, Florian. I appreciate the directness.

I understand now that Mp3tag’s design is intentionally a merged abstraction, and that per-container visibility (including legacy systems like Lyrics3v2) is explicitly out of scope. I also take the point that the presence of multiple tag containers is technically indicated, even if not in the way I was expecting.

My repeated posts weren’t intended as demands for new features, but as attempts to understand a real-world publishing failure I ran into and to work out whether I was misunderstanding Mp3tag’s guarantees. That part is clear to me now: Mp3tag is designed primarily as a tag editor, not as a release-safety auditor for all metadata layers that third parties might read.

Given that, your recommendation to use a different tool (e.g. kid3) for per-container inspection makes sense for my use case, and I’ll adjust my workflow accordingly.

Thanks again for the work you’ve put into Mp3tag over the years, and for taking the time to respond, even when the discussion became repetitive.

5

Existence of Lyrics3v2 tags is denoted in the aforementioned "Tag" column in Mp3tag's File List.

If you configure Mp3tag to remove all tag formats (incl. ID3v1), it will also remove Lyrics3v2, as it can only exist with an ID3v1 tag present.

6

With this configuration you can keep your ID3v1 und ID3v2 tags and get rid of the Lyrics3-Tag by Cut & Paste. Mark the file(s) and use CTRL-x to cut the tags and then CTRL-v to paste them again. As Mp3tag does not support Lyrics3 it will not write this tag again with the paste.

7

I wonder why you would be the one to "publish files" publicly, yet they have inherited some existing legacy tags buried deep within them. This would suggest to me that the files existed previously and were already in the wild, and potentially from long ago.

I would think as a professional your workflow should start with a completely blank slate. If you truly wish to own the information from the beginning there shouldn't be any risk this way.

A carpenter cannot blame their saw or hammer for building a crooked house. As it applies here mp3tag is just one tool in the box.

Edit: You may also want to check the Terms for this use case.

8

I hope by now you understand that your inability to prevent the "Release of Incorrect Metadata" was due to your lack of knowledge of Mp3tag.

Instead of assuming that Mp3tag could only give you results that were "incorrect", "flawed", "misleading", and "a real-world failure", you could have simply asked:

"How Can I Remove Old Tag Data That I Cannot See in Mp3tag?"

You would have been given the solutions provided by @Florian and @Poster, and all would have been well.