Don't forcibly write ENCODER tag when saving any settings in a file

[SonicRings]

3.5.8072 P

The encoder tag serves no purpose and is redundant. MusicBee already knows the encoder without it being saved as a tag, so I'm unsure why it forcibly writes it to a tag. When I edit the properties of a file, such as volume adjustment, I expect the tags to be left untouched, and thus the file to be left unmodified.

Below is a copy of the OP of my post in the bug reporting forum: Saving any settings in a file, even just a volume adjustment, writes ENCODER tag:

I've been noticing this issue ever since I started using MusicBee where adjusting the volume of a track would update its date modified value. I didn't know how or why, since the audio data remained the same.

I just now realized that the reason for this change in date is because MusicBee forcibly write an ENCODER tag (in this case with a value of "reference libFLAC 1.2.1 20070917") any time you save the properties of a file.

I don't want it to save or modify any tags if I don't tell it to save or modify any tags.



Doing the above will replicate this behaviour: open a track's properties, then adjust its volume before hitting save.

Below are my settings for Tags (2):

This bug report thread is pretty popular, as it has gained over 7k views since being posted 5 months ago, in November 2021. It is the 34th most viewed thread in the entire bug reporting forum and growing, and was only posted 5 months ago.  (Topics sorted by views, descending)

[hiccup]

+1

(no, just kidding)
 

[psychoadept]

+1, I think I ended up finding a way to work around this in Picard but still not a fan.

[hiccup]

+1, I think I ended up finding a way to work around this in Picard but still not a fan.

What actual problem is this causing for you?

[psychoadept]

What actual problem is this causing for you?

It breaks perfect matches in Picard when it gets re-added.

[hiccup]

It breaks perfect matches in Picard when it gets re-added.

I'm not sure I understand what is going on there.
Surely MusicBrainz doesn't have 'encoded by' entries?
What am I missing here?

[ma_t14]

+1

I don't feel strongly about this but the mere fact that the current behaviour is unintuitive and wouldn't be immediately clear to a user why it happens, is enough of a reason for an argument against having it. I think this request is sensible enough and I can see why someone would not want it. I'd still be interested to hear Steven's reasoning for why it happens though for some perspective that I'm probably missing, as I said earlier in the other thread.

[vzell]

+1

[hiccup]

To me this comes across as some OCD issue.

It causes no actual problems, and the current behaviour probably benefits many users that are not even aware MusicBee is doing this for the sake of being consistent in trying to provide useful metadata information, regardless of the audio-format.

I don't understand the support for having a feature removed that causes no problems, and most likely has good reasons to function as it does.

[psychoadept]

To me this comes across as some OCD issue.

Isn't this the place for people who are a little OCD about their tags?   

[hiccup]

Isn't this the place for people who are a little OCD about their tags?  

Yes. Sure. Absolutely.
But it would be best to put that to use to improve things.
Being ocd for the sake of ocd isn't productive.
(I'm not talking about you, I'm still interested in the Picard thing you mentioned earlier)

[psychoadept]

I'm not sure I understand what is going on there.
Surely MusicBrainz doesn't have 'encoded by' entries?
What am I missing here?

Picard can read the tag, but since it's not metadata from MusicBrainz (and I don't want to "protect" it), that means whenever it's there it shows up as a change because Picard has to remove it again.

[SonicRings]

To me this comes across as some OCD issue.

the current behaviour probably benefits many users that are not even aware MusicBee is doing this for the sake of being consistent in trying to provide useful metadata information, regardless of the audio-format.
 

You've dodged the question to the point of getting the previous thread locked. Seeing as you continue to say this: please explain what is beneficial about having the encoder written to a tag.

[Bee-liever]

+1 - as this currently only duplicates what is already in the file header (or footer).

Now if it did contain extra info like the actual settings used when file was encoded (as when I ripped the CD to Musicbee), it would be a different matter.

[purplebee]

+1, as long as it's not too difficult to implement