Empty "Comment" tag (flac) removed when saving

Empty "Comment" tag (flac) removed when saving. Is the program really designed to remove empty tags when saving? Because it's not consistent right now. Only the default (not removable) tags which are shown in the tag panel are being removed from the files if the tags are empty. Why?

E.g. I have FLAC file(s) with "discname" & "comment" tags empty (in the file) and when I save the selected files, the "comment" tag is removed from the file(s). The empty "discname" tag is NOT removed (just like I want it to function). Why the comment tag is removed?

I know that I can bypass this by selecting "< keep >" from the comment dropdown box.. but it's hardly ideal and slows things down very much (I've a tagging (+external tool launching with CTRL+1) job which includes ~250 albums) + the fact that it's easy to forget. If I select files (an whole album) and at least one of the files have a comment tag filled with info, the "< keep >" appears and all of the comment tags are retained, even if some of them are empty.

One might argue that it's not a big deal to lose an empty tag from the file(s).. but, A) Mp3tag is not working consistently right now, and B) to me it's important.

I hope I explained the situation clearly.

Thanks for the GREAT program!!


What's important? That Mp3tag retain your empty fields or that it be consistent?

Ok, if the Mp3tag is supposed to remove ALL the empty tags at save (not 100% sure about the ALL, but your YES would indicate this, btw, are you a developer of this program?), why is it that it only seems to remove the tags which are present in the tag panel?!? In my first post I made perfectly clear that e.g. my empty "discname" tags are NOT removed when saving. But my empty "comment" tags are removed UNLESS I choose the "< keep >" from the combobox.

Keep in mind that fundamentally the "< keep >" indicates that the VALUE of the tag is retained, not that it retains the TAG (tag name+value). So, to me this is a clear case of a unclear feature.

I just don't understand why:

  1. the program acts differently when it comes to tags which are present in the tag panel compared to the others tags.
  2. the whole tag is removed when the value is empty. (empty means something.. it's basically the same thing in (some) programming languages where "null" is SOMETHING even if it represents "nothing", right?)

Both, not OR.
I want Mp3tag:

  1. to be consistent on whether to delete empty tags on save or not (not mixed feature like it's now, read my first answer in this reply)
  2. to leave the empty tags intact!! If I save something, I'm not expecting it to remove something I've not touched!?

"Empty" means: "Nullstring", "Zero Byte length", "Tag field not filled with blank characters".
I think those empty tag fields can be removed because they carry no information.

If there exists an empty tag field in the unknown incoming file, then this empty tag field may be a relict by a bad working tagger application from before.

If all tag fields from a tag type container are empty, then it may a question if Mp3tag should remove automatically the complete tag, because of minimizing file storage size.
An empty tag container carries even no information for itself to the user.


You think!? That's your opinion of course but I'm not standing down on this issue just because you think that way. Sorry.

Here's one reason NOT to remove empty tags; "tag padding" feature which prevents the whole file to be rewritten when adding metadata. See: FLAC - faq - Why does it take so long to edit some FLAC files with metaflac?.

So, the empty VALUE is not the only one to think about. Leaving padded empty tags enables the user to edit those empty values later without rewriting the whole FLAC file.

Pleeeaase, think what you're saying! How can you jump in to the conclusion that the tagger that leaves empty tags is a "bad working tagger"?!?! Is metaflac.exe from FLAC project a "bad working tagger" since one can save empty tags with it?? Come on. You just started wrongly by thinking that empty tags are "BAD" (or of no use) and should be removed and continued from that to this next flawed conclusion.

I'm still waiting for someone to comment on the fact that some empty tags are removed (tags which are shown default in the tag panel) while other empty tags are NOT.

Florian? Can you chirp into this conversation please? Thank you.

You should make sure that your opinion of an "empty tag field" means that there exists only the tag field label with no existing physically tag field content (maybe one or two zero byte/s to indicate content is nothing).
But what is the information of this tag field label to the user?
That there was once a tag field of this name which had carry some now unknown content?
You may consider that there is no plausible reason to hold those tag field labels on living while their content has been removed.

To hold or promote or reserve a padded tag area stands not against removing empty tag fields.
Regarding a complete tag container it should be an option (if it is not implemented yet) in order to minimize file storage size to remove resp. in order to hurry up adding of new tag fields (maybe this counts for flac tag only) to reserve a n byte sized padded tag area.


Open your mind, don't try to feed "facts" to others with your limited capabilities of imagining different scenarios. Think about this: you say that the empty tag value is "ALWAYS" an end result of a removed content.. what if, the empty tag value is created "empty" when the FLAC file is encoded? I'm sure you ask why in the world. Well, empty tag value + padding = quicker saving of a new value for the tag in the future. It's that simple. Besides, how many percents a default padded empty tag take space in a FLAC file? Default is 8k, so ask yourself how much would, let's say, 10 empty tags padded take from a 35Mb FLAC file (~average FLAC file size)?? Yeah, not much.. in fact diddly-squat!

Listen dude, whatever, I hope you got it all out so you don't have to answer in this thread anymore. I still think that your "a bad working tagger application" (Mp3tag would fall into this classification) excuses are totally wrong.. try to back those claims somehow, not just because you think. Also AFAIK all tags are padded and entering an "empty" string as the value doesn't remove the padding. But, I'm not into the technical side of this issue, I'm more interested about the inconsistency of Mp3tag when it comes to removing different "empty" tags. End of story.

Again I feel that I must repeat: I'm still waiting for someone to comment on the fact that some empty tags are removed (tags which are shown default in the tag panel) while other empty tags are NOT when saving a FLAC file.

Should I open a new thread in the BUG forum to get some attention to this issue? I wouldn't like to do that because I'm not fully sure that this a bug.. just a intended feature.. thou inconsistent.

Florian? Can you chirp into this conversation please? Thank you very much.

Well, I think, yes, -I-do-think-, some of the FLAC experts should come in to speak some sort of 'Power Word'. :wink:

As I've learned from the FLAC documentation resource you've named, the FLAC format supports up to 128 kinds of metadata blocks; seven are currently defined. The two metadata blocks which play a role together with Mp3tag seems to be: VORBIS_COMMENT and PICTURE.

Because you are lamenting - still not traceable, because you did not support an example file yet - about empty or not empty 'tag field label' and/or 'tag field content' the maint point of the discussion seems to be how to use VORBIS_COMMENT within a FLAC file in a way to have comprehensible input/output behaviour resp. valid input/output data and further on to reach minimized consumption of time while tagging a FLAC file.

The document http://www.xiph.org/vorbis/doc/v-comment.html says, that there is 'no single or group of field names mandatory' in a VORBIS comment. Beside this statement there exist a 'minimal list of proposed standard field names'. 'Additionally field names are not required to be unique (occur once) within a comment header'.

So what the hell is a plausible reason to store empty tag field labels into a VORBIS comment metadata block?
(If it would be possible ..., because 'The comment vectors are structured similarly to a UNIX environment variable', and I've learned that one empty environment variable practically does not exist.)


@DetlevD: I think you have taken some pills coz I've a hard time to follow your last post.. or it was those weird looking mushrooms I took today. :smiley: Seriously thou, I think we're talking about different things right now. I'll try to explain the situation with an example since my description of how to reproduce the inconsistency I'm seeing is not getting thru (did you even bother to try it out? Or are you just arguing against how tags should be removed (or not)?).

Below is three listings from "metaflac.exe --list --block-number=2" command from one FLAC file (I removed some tags for this to be easier to read):


    METADATA block #2
    type: 4 (VORBIS_COMMENT)
    is last: false
    length: 157
    vendor string: reference libFLAC 1.2.1 20070917
    comments: 6
    comment[0]: artist=Corduroy
    comment[1]: album=Out Of Here
    comment[2]: Tracknumber=01/13
    comment[3]: discname=
    comment[4]: title=Don't Wait For Monday
    comment[5]: comment=

  2. Edited + saved from the tag panel (using ORIGINAL as base):

    METADATA block #2
    type: 4 (VORBIS_COMMENT)
    is last: false
    length: 153
    vendor string: reference libFLAC 1.2.1 20070917
    comments: 5
    comment[0]: discname=
    comment[1]: Album=Out Of Here
    comment[2]: Artist=Corduroy CHANGED
    comment[3]: Title=Don't Wait For Monday
    comment[4]: Tracknumber=01/13

  3. Edited + saved from the extended tags dialog (using ORIGINAL as base):

    METADATA block #2
    type: 4 (VORBIS_COMMENT)
    is last: false
    length: 144
    vendor string: reference libFLAC 1.2.1 20070917
    comments: 4
    comment[0]: album=Out Of Here
    comment[1]: ARTIST=Corduroy CHANGED 222
    comment[2]: title=Don't Wait For Monday
    comment[3]: Tracknumber=01/13
    So, do you understand why I'm writing these posts here? Splel this out: inconsistencies.

Summa summarum:
2) shows that the empty "comment" tag is removed, but the empty "discname" tag is retained. (The "comment" tag is also retained IF one chooses the "< keep >" from the tag panel "Comment" combobox.)
3) shows that both of the empty tags ("comment" & "discname") are removed.

I didn't know that the "extended tags dialog save" works differently from the "tag panel save" before.. even more minuses to Mp3tag. I've a hard time to believe that these inconsistencies are intended. Maybe this thread should be moved to BUGs forum?

Notice that metaflac.exe "--remove-tag=" command (which I used to remove some tags for this demonstration) did NOT remove empty tags from the file... this is how I would like Mp3tag to work, i.e. do NOT remove/change NOTHING unless I instruct Mp3tag to do so.

The "Remove fields" action is a relatively recent addition to Mp3tag. Prior to it being available I believe the only way to remove a field was to set it to a zero length string. For backward compatibility with existing user Action groups, it would seem that this behavior would need to be maintained.

------------  ----------------------------------------------------------------
[2005-07-09]  REL: VERSION 2.32
------------  ----------------------------------------------------------------
[2005-07-01]  NEW: action type 'Remove fields'.
[2005-07-01]  NEW: action type 'Remove fields except'.

Should this behavior change at some point? Perhaps. But I certainly have no use for empty tags. If I set something to blank, I'd just as soon have it removed completely. If this behavior was due to change, I'd want a Tags option stating whether or not to "Remove blank fields".

As far as the inconsistent behavior, if you think it's a bug, file it.

Well, you are right, there may be one or more small bugs in Mp3tag FLAC related code.

There are differences between example 2) and 3) in spelling resp. casing the tag field labels.

This should not happen.

It seems that Mp3tag does an alphabetical sort on the tag field label names.
Maybe the sorting algorithm lose the last resp. first element
(this might be something of Florian's peculiarities, struggling with zero based arrays ... hey Florian, don't worry :wink: )

T. A. G. Ger, I think you should make a note in the bug forum.


Yes, I realized that one of my custom field MOVEMENT was not removed after becoming empty, but I had no time to check the reasons. I thought my rather complex action script put a white space or something to that fields. As I see my script is OK, fortunately. I hate hunting for errors. :smiley:

Ok, finally had the time test with the latest beta and submit the bug report.

Check it out in case I forgot or misrepresent something wrong: Several inconsistencies & bugs in saving FLAC tags.