[quote=jiri post_id=473665 time=1602754947 user_id=15747]
I wonder, if MM updated the mp3 header with correct leveling value (i.e. not only read it, but also write), would it cover your case?
[/quote]
Not really.
I have tens of thousands of files with this replay-gain headers and as far as I know there is no software other than MM that cares about this header-infos. I think most users are not aware of this lame-feature and as the writing of replaygain-values in the header is the deafult behaviour of lame, most users also probably have these headers in their files.
I also don't know if a player uses this header-infos at all. Does MM do? If so, why create additional tag-values? But perhaps MM only uses it's database-values for playing.

The only reason why I have not removed these informations in the header so far is that, in my opinion so far, it did not cause any problems and that there is no workable software to remove it. To have all headers rewritten with Foobar seemed too time-consuming.

So far I had just wondered why I kept having unwanted replay gain tags in the files until I found MM to be the culprit for writing these tags.
Now that I have found the cause and understand the connections (header-> tags), I can [b]personally[/b] manage to delete the unwanted tags afterwards or edit the database with the clean-fields-script beforehand. Anyway, I personally would also not like if MM itself writes (possibly changed) information in the header.

Generally I believe that MM should change this behavior. I do not consider it appropriate to change the tags over the user's head.

I wonder, if MM updated the mp3 header with correct leveling value (i.e. not only read it, but also write), would it cover your case?

I'd like to avoid introducing another option, particularly since it'd apply only to a very few users.

Jiri

[quote=MiPi post_id=473638 time=1602672573 user_id=27459]
Not reading already existing value in this header would be bug.
[/quote]

I have nothing against reading existing information. But an [b]option[/b] against reading the header would certainly not be a bug.

However, this option would also be a measure that only affects the core problem in a detour.
The main problem is that Mediamonkey - without any possible influence on the part of the user - later writes a value read in the header from its database into a tag.
In this way, the user's data is changed, in a number of cases - as with me - certainly without the user's will.
In my opinion, this is a [b]conceptual[/b] bug.

This is by design: https://www.ventismedia.com/mantis/view.php?id=2687
Not reading already existing value in this header would be bug.

@Lowlander
@Erwin Hanzl
Thanks for your explanations.

I now made another more detailed investigation of the behavior I noticed and came to further insights.

The main cause is the consideration of the replaygain value in the Lame(Xing)-Header by Mediamonkey, which I was not aware of. Lame knows a parameter (--noreplaygain) to prevent an analysis value from being saved in the header, but unless you set this parameter the default behaviour with analyzing is active and so most of my MP3s have this value in the header .

So when new files are scanned with Mediamonkey, Mediamonkey reads these values into its database and then saves them in tags when synchronizing (or in my case when using the lyricator). So it does not only read existing replaygain-values in the [b]tags[/b] but also in in the [b]heade[/b]r of the file.

The only way I can see at the moment to prevent this behavior of Mediamonkey is to remove the value from the Lame header, which e.g. through a "Fix-mp3-vbr-header" in Foobar is possible. Of course, you can also use the "Clear field" script to delete the value from the Mediamonkey database and thus prevent the subsequent writing of the tag. However, when the database is updated, Mediamonkey reads these values again.

So my statement that Mediamonkey analyzed this value again and again was wrong. Instead of analyzing again, Mediamonkey just reads the header values over and over again.

[b]In my opinion, Mediamonkey should have an option to leave out existing replaygain values in the header when reading into the database.[/b]

@gibbon

With the add-on "Clear Field 1.3" you can set the adjustment coefficient to "not analyzed" again.
https://www.mediamonkey.com/addons/browse/item/clear-field/

Field: Leveling
Field: LevelingAlbum

After installation: restart MM
Select files ... Tools> Scripts .. Clear Field

Yes, that's the option and the only option that controls this. You may want to enable it, restart MediaMonkey and then disable it again.

Note that if files have this data in the tag already that MediaMonkey will read this when scanning files.

[quote=Lowlander post_id=473480 time=1602257385 user_id=262]
Tools > Options > Volume Leveling and disable the option to automatically analyze volume of analyzed files.
[/quote]
Do you mean the option:
"Automatically analyze volume of unanalyzed files"?
This option is disabled.

My files are unanalyzed and I want Mediamonkey not to care about this.
I use one instance of Mediamonky together with the Lyricator-script on new files.
Because Mediamonkey anaylyzes the files, when I add them, the analyzed results are written to replaygain-tags as soon as I tell Lyricator to save the found lyrics.

Even if I delete the written replaygain-tags, clear the Mediamonkey-library and add the files to the library again, the loudness is obviously analyzed again.

There seems to be no way to tell Mediamonkey to completely ignore loudness-analyzing.

Tools > Options > Volume Leveling and disable the option to automatically analyze volume of analyzed files.

When I add files to the library Mediamonkey does an automatic scan for loudness.
I don't want this but I don't find a way to tell Mediamonkey no to do that.
The settings don't seem to contain a fitting option to completely avoid loudness-scanning.
I tried every option in the loudness section (which don't fit - when I look at the explanations - anyway).