FLAC Track Volume Setting

[ReaSoN]

Noticed a strange thing today. I've been re-ripping much of my collection to flac recently, and had got ~2500 tracks done. I kept the MM "automatically analyse volume" option on, and verified that it was doing it during the rips. I also checked each album afterwards, and did not notice any problems with the track volumes.

Unfortunately I ran out of disk so moved the entire library over to a new NAS today. I deleted the MM contents and re-loaded all of the tracks from the new NAS ... and it is now going through volume analysis on ~1000 of the 2500 files. I could imagine a few getting past me possibly, but 40% or more seems very unlikely. Scanning through the library then it appears that many (flac) tracks don't have track volume set.

Seemingly the replaygain value was never saved originally, or at least can't be retrieved. I couldn't find any other recent references to this in the forum, but hoping somebody may be able to shed some light.

Running MM 4.1.0.1692 on Windows 8.1 Pro.

Thanks

[nohitter151]

Maybe the tracks were set as read only on the disk so the tags couldn't be modified?

[ReaSoN]

Thanks for your thoughts nohitter, but no ... definitely not read-only. All other tags were set & stored correctly so that they migrated when I moved the library. My concern is that if this particular tag is not being set/stored reliably then it becomes hit and miss whether replaygain is working correctly.

[Lowlander]

A possibility is that auto-analyze isn't set (by developers) to update tags on scanning (haven't tested this) or that you closed MM with many tags to be written. I only use manual analyze and it does save the tags to the files.

You can always manually force tag write on selected files with Tools > Advanced Tag Management > Synchronize Tags. The Files to Edit > Unsynchronized Tag node in any Collection (like Music) may show files that haven't saved leveling tags tot he files (haven't verified this).

[ReaSoN]

Appreciate your input Lowlander. There are other issues with auto-scanning during rip, such as the fact that it apparently takes ~45 attempts to analyse a CD with 18 tracks, which doesn't make sense to me either. That said, in the absence of any corroboration then I will have to assume it was a one-off problem. I can (and probably will now) switch to manual analysis, but as the code that does the analysis and updates the tags in the file is likely the same then it leaves me concerned that there's still an underlying problem.

[fizzjob]

Not sure if it's related, but I've been seeing strange behavior with volume analysis in 4.1 as well.

[Lowlander]

Note that only few tags will be saved for ripped files (tags you tag on CD prior to rip). However I'd assume this wouldn't be the issue here.

[nohitter151]

Appreciate your input Lowlander. There are other issues with auto-scanning during rip, such as the fact that it apparently takes ~45 attempts to analyse a CD with 18 tracks, which doesn't make sense to me either. That said, in the absence of any corroboration then I will have to assume it was a one-off problem. I can (and probably will now) switch to manual analysis, but as the code that does the analysis and updates the tags in the file is likely the same then it leaves me concerned that there's still an underlying problem.

It's because the album volume is calculated every time a new track on the album is added to the library. So the whole set of tracks in an album must be re-analyzed every time a track gets ripped. I have already reported this to the devs but there hasn't been any action on it yet.

I have ripped probably over 300 albums to FLAC with MM but I never had any issues with the volume info being lost.