I would like to be able to view the raw data of tags in mp3 and flac files.
I am guessing you need a hex editor for this, but it will take some trial and error for me to see what would work best.
I am curious what tools other members are using for this?
Are there perhaps dedicated tools, or other ways for viewing raw metadata?
I use Notepad++ with the plugin “Hex-Editor” (downloaded and installed within the Plugin Manager.)
Sometimes this plugin get deactivated. Here you can find a newer version for this Hex-Editor-Plugin .
I highly recommend to NOT CHANGE tags directly in any hex editor. 
Thanks, I am a notepad++ user, and that’s a useful plugin indeed.
But for this purpose I found HxD that seems to have some additional display options that I like.
Looking at the raw data of a flac file, I noticed something that I have a question about.
(and also have no clue whatsoever what I would do with an answer)
Most tags seem to be delimited by four dots. (full stops)
(why four dots? I was expecting something like ‘/’)
But quite a few don’t have four dots, but another character followed by three dots.
(I highlighted these in red)
Does anybody know what these characters represent here?
If you use the view in Notepad++ hexeditor, you can see the value for every single character, including the dots and the red colored characters.
Which value do you see for this characters?
I just used the option to hide the hexdata columns. (HxD can do that)
When I show them, they display the exact same content as the notepad++ plugin.
I am just wondering why e.g. some performers are separated by ‘…’ others by ‘!..’, others by ‘)…’, etc.
(edit, Discourse is mutilating/removing some dots from the example I typed above. Some separators have four dots, others have some character and three dots)
If you answer my question above (what [HEX/DEC-]values do you see?), maybe we can help you 
It is common in many hex to character dumpers/translators to show a dot (".") where there is no commonly available character to display for that hex value. For clarity you need to show the hex values to know for sure they are actually dot’s.
Thanks for replying (both of you)
For what it’s worth, the dots (full-stops) have hex value 0 (null)
But it looks like I am not clear about what I am trying to understand.
I don’t care if it are dots, symbols, or numbers as limiters between the tags.
What I am wondering about is why there are differences in the delimiters between e.g. performers.
As I said before, some have just four dots, but other have an exclamation mark with three dots, or a plus sign and three dots, or a hyphen and three dots, etc. etc.
I am wondering if that has some relevance that might be reflected in tagging programs such as Picard.
I am not able to deduct any pattern with these delimiters here.
I’d have to look at the specification again, but as far as I remember those 4 bytes that you see as some random character and 3 dots are used to encode the length of the next field. So those 4 bytes are actually one 32 bit integer, but since the hexeeitor displays byte by byte the first byte just shows up as a random character. And the remaining 3 fields are usually indeed 0 since the fields are short enough that only the first byte is needed (the bytes are ordered as Little Endian)
The 32-bit integer appears to be a count of the characters that follow. If the first byte of the this 32-bit integer does not have a displayable character translation it will be displayed as a dot. Look at an ascii table, it will show the decimal number for “>” is 62, then starting with the first character past the last dot count all the characters. I only looked at a couple so I could be wrong. This is how you can search through a variable list of strings of variable size. Remember it is not a character and 3 dots, it is a 4 byte integer with only the first byte “sometimes” having a printable ascii value depending on the character count. I hope that makes sense.
Care needs to be taken when dumping and interpenetrating raw data that combines both binary and character data types. The only accurate way to do this is to display both hex and the printable character at the same time other wise you are only guessing since a non-printable character will be displayed as a dot. I use linux “od” to dump raw data since I can tell it how to format the data output.
Ah yes. That seems to be it. It’s indeed a character count.
So it has nothing to do with how tags are handled or displayed.
Thnx, learned something.