Working ONLY with FLAC files — A Simple Question

First let me apologize for this rather lengthy post. I don't know how else to describe what I view as unwelcome treatments applied to our FLAC music library content by an otherwise well-meaning library co-manager.

I am (or was) an original contributor to this very large digital music library comprising albums encoded exclusively in the FLAC file format. At the beginning of this project, we created a reasonable set of Vorbis comment FIELDNAMEs to describe the most significant metadata typically found in a CD's liner notes, in related documents and in promotional "one-sheets" that often accompany new releases. It is my understanding that such entries should be simple and brief and in the following form, where the "Value" in the example below can be expressed in any international character set that is UTF-8 compliant. We also understand that the FIELDNAME necessarily comprises characters from a subset of the ASCII English character set, also illustrated below: The latter restriction ensures global compatibility regardless of the native languages used for the Value entries.

TITLE=Don't Step Over An Old Love

When pressing ALT-T to display the embedded metadata (Vorbis comments) we have added, how can we be certain that all of the tags that are displayed are actually in the file's Vorbis Comments container and not in another location or container in the bit stream?

I ask this question because at least one media management/music player application used by another individual with access to this library takes the initiative when used to open, edit, play and/or move FLAC file in the same library. In doing so, this application generates a significant number of "unexpected tags" that are not included in our original family of FIELDNAMEs.

It is significant in my opinion that some of these unexpected tags appear to be generated analytically by the unwelcome application, resulting in questionable results that fall outside of our simple FIELDNAME=Value album metadata format. Here are a few examples:

PEAK LEVEL (R128)=2.63578598

This is a small sample of about 16 or more of these "rogue" tags. Their inclusion varies from track to track and album to album.

Are they in the Vorbis comments container? Don't they belong elsewhere in a different block? We hope to develop (or find) an application that can run in a Windows or Macintosh platform to selectively display desired Vorbis comments while the track is being played. Unfortunately, at least in my opinion, these unsolicited tags are troublesome.

I forgot to mention that multiple FIELDNAME entries, such as this example which follows, are rearranged under one FIELDNAME when a track is handled by the "rogue" application. Thus this outcome:

Desired Tags:
PERFORMER=Jake Blount (Lead Vocals, Fiddle)
PERFORMER=Jerry Douglas (Resophonic Guitar)
PERFORMER=Sam Bush (Harmony Vocals, Mandolin)
Unwelcome Result:
PERFORMER=Jake Blount (Lead Vocals, Fiddle);Jerry Douglas (Resophonic Guitar);Sam Bush (Harmony Vocals, Mandolin)

I would appreciate your comments and suggestions. Thank you!

Where do you see that unwelcome result?
The vorbis comments as tags for flac files allow any kind of tag fields. It is up to the application to interpret these.
If you want to keep only a set of fields consider the use of

an action of the type "Remove fields except" in which enter a list of fields to be kept.
As long as the

follows the rules of how tag fields have to be constructed, the fields are valid.
I think it would be down to organizational means to avoid other people add fields that you do not want. Yet, they do no harm.

Yes, and they're most likely the result of an interpretation of the audio stream by this other application.

Yes, Mp3tag displays every field from the FLAC metadata block (i.e., VorbisComments) via extended tags. Mp3tag doesn't perform any interpretation of the audio stream to create artificial tag fields.

Unfortunately, there don't exist a way of separating release metadata from such technical metadata.

It seems to be their preferred way of handling multiple field values, but a poor choice to perform this automatically imo.

Consider Making Your Library Files Read-only

After tagging your library files as you want them tagged, consider making them read-only. If someone removes that attribute on certain files, you can easily detect the change through Windows Search by searching against the read-only and archive attributes:


32 is the Archive flag plus 1 for Read-only.

You can also display file attributes in explorer as a column. In that column RA indicates read-only. If a file in the column does not show an R, then that file is not read-only.

Attribute query details are found here:

You might also want to warn library users against removing the read-only attribute from the library originals. If they really need to add their own tags, then they should make local working copies of the files.

UPDATE: additional (more complete) references kindly provided by LyricsLover in the German discussions: Attrib - Edit file attributes - Windows CMD -