Display all tag fields in a file

Hey Florian...

Can it finally after 11 YEARS be added to Mp3tag that ALL fields/Tags within a file (i.e. MP3) are able to be seen?
I mean, I only just discovered that one file had Synced Lyrics in it when I happened to play the file within MusicBee. Neither Mp3tag nor Picard shows these. So, I had no idea this tag was even in the file.

I find this a big problem, for example, I also discovered that MusicBrainz Picard would not show some WWW or something tags, but Mp3tag DID show them.

I mean, there shouldn't be "hidden" information within music files, that's part of the whole purpose of using these programs like Mp3tag and Picard, is to see what Tags are in our files and edit/remove/add them as we like.


It's still not planned to make all tag fields available via the UI. Some of the fields have binary content (e.g., many of the application-specific ID3v2 PRIV frames) which breaks the flexible tagging with placeholder approach which is used throughout the app.

I suggest to simply let Mp3tag remove all fields except the ones of your liking via an action if you get music from sources out of your control.

And as a side-note to your post: I don't love the "finally after n years" phrasing. It implies that nothing happened in the meanwhile, where the contrary is true.


No offense was intended, just was addressing it had been a long time and it seemed odd the program/or other ones wasn't showing everything.

So, is there no way to even "show" all these other tags, even if Mp3tag doesn't allow editing etc.?
I just find it crazy that "hidden" Tags can be in our files doing who knows what and we have no way of knowing about them.

Like I mentioned above, Picard wasn't showing tags that had Web Addresses in them. I mean yuck... :frowning:
So, I just found all this concerning...

Thanks again...

Oh, and any pointers on how I would "remove all fields" with Action?
And you mentioned maybe I shouldn't, due to application-specific info? Is that stuff really needed?

Just want to give my 2 cents as a Picard developer. It really isn't that simple as to "just show all the tags" for various reasons:

  • As Florian said above many tags, depending on the tagging format, are not simple text fields but have a specific binary structure. In ID3 this is especially true, just look over the list of defined ID3 frames. Without implementing specific support for such a tag it is not usable. In many cases that does not only mean supporting reading and writing this structure, but also providing appropriate UI to display and edit the values.
  • Both Mp3Tag and Picard are tagging software that support multiple different file formats, and they strive to standardize tagging those files. That means if I want to add support for a specific ID3 frame I also must consider if and how this data can be supported for MP4, Vorbis, WMA, APE etc.
  • The goal of tagging software is to get data into the files that can be used by other software, mostly playback tools. That means when adding support for any tag one must also consider if and how this tag is already used in existing software. Often there are differences in how software makes use of specific tags and this must be considered also.
  • A lot of the way the tags are used is actually defined by existing implementations, less so by specifications. That is very true for a lot of ID3 frames, where the usage was basically cemented by some of the most widely used playback tools (iTunes and Windows Media Player mostly), which often did not follow the spec by the word.
  • A lot of the frames defined in ID3 are rarely used in existing software. Or there are specific features that are rarely used and supported.

The bottom line is that of course increasing the support of different tags is a goal. But IMHO it can only be done step by step. And even then not all tags really warrant the effort needed to fully support them.

There are tools that can just dump the tags in a file as some text output. E.g. the mutagen Python library used by Picard comes with a command line utility mutagen-inspect which will just output all the tags it can find (and knows) in a file. There is likely also some Windows GUI tool that does something similar (I don't use Windows much, so I don't really know).


If these “hidden” fields are unsupported by your players, then they are irrelevant. But if there are concerns about other nefarious reasons for their existence, perhaps you may want to consider a better source?


Thanks all, I understand... Just found it odd and concerning, but I get it.

Appreciate the info and all you do...

As to "sources", YouTube and Spotify generally, so not so much concerned about that.
I just don't like "unknowns"... So, was wondering. Thanks again.

These are proprietary sources and aren’t available to download and use outside of those platforms. So the files are not open for tag manipulation.

LOL... Obviously, I'm downloading/recording the files using 3rd party tools, thus my files DO have tags in various degrees.

Anyway, I now understand that these tools aren't able to see/address all tags, and so there's going to be tags I can't see in certain tools or in any as I mentioned above.

Thanks again all...

So I go back to my previous comment about suspect tags. In this case I will revise that to refer to the tool(s) you are using. Since these tags are unlikely to be coming from the original source in these cases, it is not a stretch to assume the "invisible" tags are being inserted by these tools. I still suggest you reconsider your sources.