I'm not understanding the ReplayGain tag behavior [#21084]

[tsaylor]

I wanted to use ReplayGain 2.0, so I used a plugin within MusicBrainz Picard, and after much effort my entire library now has tags REPLAYGAIN_TRACK_GAIN/REPLAYGAIN_TRACK_PEAK with values. But with the full library imported into MediaMonkey (version 2024.0.0.3033 if that matters), I'm seeing some unexpected behavior.

Checking the "Track volume" column it seems to be filled randomly (maybe 40% of my tracks, not even consistent within an album). Checking the file properties it seems that a value either shows up under "Track volume" or under Custom / Extended tags (as REPLAYGAIN_TRACK_GAIN/REPLAYGAIN_TRACK_PEAK), but not both. And it seems to me the the files which show as extended tags (and an empty Track volume) are playing louder, as if their track volume adjustment is 0db. It's as if those replaygain values were ignored for over half of my files. I've also tried deleting some files from the database and re-syncing but the behavior is the same.

How can I understand what is going on here? When I look at those same files under Picard (and also under Mp3tag), I see ReplayGain values for every file. But MM has that mix of track volume / no track volume values. What can I try?

[Peke]

Hi,
Best would be to create support ticket and send us DL links to two files that were scanned with MusicBrainz Picard eg. one that shows in MM and one that do not show in MM.

Also note that if files were in M Mlibrary before scanning replay gain in MusicBrainz Picard the data will not be imported automatically you need to rescan files.

[rusty]

Hi,

The reason why the track volume might be filled for some tracks and not others could be:

- the tags aren't saved in Picard for certain audio formats in a format that is understood by MediaMonkey. Does MM show the volume leveling coefficient for some file formats (e.g. MP3) but not for others (e.g. M4A)?
note: you can see the volume leveling tags supported by MMW at https://www.mediamonkey.com/wiki/WebHel ... erties/5.0

- MMW, by default (see Options > Library), only updates tags if the timestamp has been modified. So if some of the tracks were already in the MM library, and were then updated by Picard with the new volume leveling information without updating the timestamp, then MM wouldn't update the metadata. Could this have been the case?

Looking forward to your feedback!

-Rusty

[tsaylor]

Thanks for the replies. I'm referring to only .mp3 files, and it seems random as to which ones process the track volume. Even within a single album/directory there is a mix. When updating the files I believe the timestamps were updated, and then I did a scan in MM to import the changes.

I also tried copying two files to a different directory and then rescanning and see the same behavior (one shows track volume and the other does not, same as the original copies). Or does MM recognize that those files have duplicate content to existing files and skip some steps?

I've also tried removing a few files from the db and scanning again, with the same results. Does MM "remember" any details from before?

I'm happy to try other tests if you have thoughts on that (and/or I can provide some example mp3 files if the support route would work better).

[tsaylor]

I've just found important clues! It appears that the files missing "Track volume" are the ones with older modification dates. As a test, I changed the "title" for one of those files and saved. After re-scanning, MM had the missing track volume. But not only that, the other "duplicates" of that file were also updated.

This makes me think that the MM database not only recognized partially-duplicate files and shared information (even with a different title tag, in this case), but it also makes me wonder if it is remembering past data in this way [recall the test where I deleted and re-scanned but was still missing track volume].

Another relevant bit of information: Prior to cleaning up all my meta tags I had these same files in MM in a different location. So when I imported these "cleaned" files, I'm thinking they shared the data of the older files somehow, and that older data seems to still persist even after the original location was removed from the db.

To help clarify, here's the sequence of operations I recall:
1) Location 1 added to MM db (probably with a mix of missing track volumes and other junk)
2) Big Picard project to clean, add ReplayGain everywhere, and copy to new Location 2 with new naming (but preserving old timestamps on the files in the new locations)
3) Import Location 2 and remove Location 1 (I think it was done in that order)
4) Many files still missing track volume
5) Remove/add a few files, but still missing track volume

So I think that explains part of the issue, but if you can explain more about the database management it would help (like how/when that data seems to be shared between files, and how I can sever that link to the past and get everything current with the source mp3 files now).

[Lowlander]

By default MediaMonkey only rescans tags for files with a new modified date. You can disable this in the Options, but this will make scanning slower.

[tsaylor]

I don't mind that behavior (rescan only when modified). It makes sense.

But in my case I'm suspecting some information actually came from different-yet-similar files, because the new set of files should have had ReplayGain info from the start (even though the older copies in a different location did not). There seems to be some information sharing or retention that I don't understand.

[tsaylor]

Another test: I tried turning off the "Only for files with changed timestamp or size" option (setting under "Update file info from tags when rescanning files"), then scanning some files, but this didn't update the Track volume values either (again just leaving that REPLAYGAIN info listed as extended tags).

[rusty]

Hi,

As a test, I changed the "title" for one of those files and saved. After re-scanning, MM had the missing track volume. But not only that, the other "duplicates" of that file were also updated.

Can you clarify what you mean by this? i.e. did you ever see duplicate entries for the files in the library (I know that you wrote that you weren't sure whether you deleted Location 1 before scanning Location 2, in which case there would certainly be duplicates for a short period of time, by that doesn't explain why there'd be duplicates _after_ you deleted the files)?

Thanks!

-Rusty

[tsaylor]

As a test, I changed the "title" for one of those files and saved. After re-scanning, MM had the missing track volume. But not only that, the other "duplicates" of that file were also updated.

Can you clarify what you mean by this? i.e. did you ever see duplicate entries for the files in the library (I know that you wrote that you weren't sure whether you deleted Location 1 before scanning Location 2, in which case there would certainly be duplicates for a short period of time, by that doesn't explain why there'd be duplicates _after_ you deleted the files)?

Yeah that wasn't clear. First I had tried copying two of the files to a parent directory (thus creating duplicates). The duplicates were the same as the originals (one pair having a track volume and the other not). Those are the dups I was referring to.

Then I changed the title tag on one of the duplicates, and after rescanning found that it had track volume, and unexpectedly so did the original source file.

Other than that test, I don't have duplicates (other than some special cases like compilations with the same track also under an artist folder). The original "location 1" still exists (before cleaning up all of my tags), but is not listed as a MM location and not included in "All Files" at this point.

Happy to run more tests if it is helpful.

[Peke]

Hi,
Having some tags in extended tags means that tag is saved according to tag format standards, but not in the field recognizable by MM. So it is listed there.

As I said the best would be if you can find file that do not have REPLAYGAIN tags in any off apps (If you open support Ticket I can supply you test sample file), then pass it thru Picard that would result in MM show the same file replaygain in extended tags and not in Volume.

Again, it would be great if you can send us DL links few files from same album eg. one with correct replaygain and one with replaygain showing in extended tags..

[tsaylor]

Sure, I can provide some files. I almost did so previously, but after finding more clues I started thinking it is not the files themselves, but some sort of data sharing/memory that the db seems to have, or a state it is in. Like the fact that changing a title in one file caused the replaygain to be recognized in two files. Anyway I'll send some files and see if you can reproduce anything with them.

[Update: support case created]

[Peke]

Hi,
Success, added as https://www.ventismedia.com/mantis/view.php?id=21084

This is strange issue, thx for reporting.

[tsaylor]

Oh, a tag case sensitivity issue! Interesting, glad you found it.

[Peke]

Oh, a tag case sensitivity issue! Interesting, glad you found it.

Me too.

FYI You can test/confirm it works on some other files by RAW hex edit files in https://mh-nexus.de/en/downloads.php?product=HxD20 and follow replace instructions from bug.