Hi,
As you see in this case, there is always a simple answer.

As for tools I am never afraid to get dirty if I want o archive something. All those fancy tools make us .... sometimes it is good to go all nature and be in a suite you are born in

THX for confirming.

Another note: When I tested changing the title of a file, I used Mp3tag. That app must also "fix" the case of those tags, so that would explain why changing the title fixed the Track volume.

Confirmed, I used HxD20 to change the case of that tag for another file, re-scanned, and the track volume was shown.

Throughout my whole metadata-cleanup project I've been annoyed to not find any tools that just tell me everything about the actual tags. Most apps try to provide friendly names and translations, leaving me wondering what is *really* there.

It's also interesting that I managed to get a mix of cases there, even within the same album. That's puzzling, as I thought I used the same tool for everything. But I have used different tools in the past (mainly MP3Gain), so that's possibly a factor.

tsaylor wrote: ↑Mon Jul 15, 2024 6:42 pm 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.

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

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

This is strange issue, thx for reporting.

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]

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..

rusty wrote: ↑Mon Jul 15, 2024 3:00 pm

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.

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

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).

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.

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.

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).

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).