Volume leveling issue with Boards of Canada's Geogaddi albums (ref#8BVACD)

Support
1

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· None of these quite match

Tell us what's going on

· Strange volume leveling issue related to the Album Gain value for two versions of the same album.

Two versions of the same album (Boards of Canada's Geogaddi and its Japanese import version) state the Album Gain in the file info is: -23db (1.6dBTP) and this appears to be incorrect, and driving odd behaviour via Arc, Roon Remote, or other endpoints.

Other albums don't appear to have this problem and behave as expected, but in these specific cases, adjustment of the 'target volume level' via Arc or Roon seems to create a negative db adjustment that is aligned directly to the LUFS value selected (e.g. if I select -19 LUFS as the target, the UI reports -19dB Volume Leveling, for -23 LUFS the UI signal path then reports -23dB, etc.) and none of these dB value adjustments correlate to the real gain adjustment that ought to be applied.

Track Gain appears to be fine, so this problem arises on Auto and Album volume leveling, and results in much quieter playback than ought to happen.

I have tried removing the files and adding them back in so far, but can't seem to force a rescan that corrects what appears to be some kind of sticky corruption of the Album Gain value.

Tell us about your home network

· Three Mobile 5G>Google Home MESH>Roon Server (Wired)

2

The screen shot above is the result of selecting -23LUFS.

Below is a screen shot of the file info for one of the tracks - they all state the same album gain value.

Screenshot 2026-05-06 at 17.14.27
Screenshot 2026-05-06 at 17.14.271428×1544 209 KB

For info., I often default to -23LUFS for volume levelling and have also noticed some lag behaviour in relation to background audio analysis (at present, for instance, set to ‘unscheduled’, this seems to be stuck on 1/17, despite having access to 4 cores).

Lastly, in case it’s useful, I suspect that the possible root cause may have stemmed from me tidying up and editing my Boards of Canada files (managed via iTunes/Music on my iMac), whilst the Roon Server was running.

3

Hey @Greg_Ince,

Thanks for writing in, and very sharp eye!

A fresh Roon Server diagnostic report confirms your suspicion precisely. The albumGainDb value for both Geogaddi versions is hardcoded at exactly -23 across all log entries, a round integer, not a real R128 analysis result like the -11.50 or -9.79 values you see for other albums.

This strongly indicates the album gain was never properly computed by Roon’s own analysis engine for these albums. Instead, Roon appears to be using a fallback value that happens to equal your chosen LUFS target, which is why the Volume Leveling display tracks your LUFS setting 1:1 rather than applying a meaningful gain offset.

The repeated “Track … was found in AudioAnalysis API, updating Track…” entries confirm Roon is fetching analysis from its cloud API for these tracks, so it’s pulling a cached result. That cached result at Roon’s end may itself contain the corrupted/missing album gain, meaning forcing a local re-analysis (not just a library rescan) is what’s needed.

Let’s force a full local re-analysis of both Geogaddi albums.

This is the most important step, and it’s different from what you’ve already tried (removing/re-adding files). In Roon:

  • Go to the album → click the three-dot menu → Re-analyze. Do this for both Geogaddi and the Japanese import version separately.
  • Alternatively: Settings → Library → Clean up library, then force audio analysis by going to Settings → Library → Audio Analysis Speed, temporarily setting it to Fast (not Throttled/Unscheduled), and watching whether these albums are queued.

It’s also worth considering, because your files were touched via iTunes/Music, there’s a good chance iTunes wrote REPLAYGAIN_ALBUM_GAIN or iTunNORM tags that are set to -23 dB. Roon may be reading these as authoritative. Use a tool like Kid3, Mp3tag (macOS), or fre:ac to inspect the .m4a files and check for any embedded loudness/ReplayGain tags.

If REPLAYGAIN_ALBUM_GAIN = -23.0 is present, delete it and let Roon recompute. The file info screenshot confirms the stored Album Gain is -23.0 dB (-10.7 dBTP) — the -10.7 dBTP true peak is plausible, but -23 dB album LUFS is unusually quiet for Geogaddi (which is a naturally louder master), suggesting this tag was written incorrectly.

Let me know if the above helps! :+1:

4

I’ve tried with a number of tag editors (including those above) and haven’t been able to expose the tags you mention in their UIs, so I’m uncertain if such tags are present or not, incorrect or otherwise.

I’ve also tried to Re-analyze both versions of the album route, as well as the Clean Up Audio>Analysis Speed, but don’t seem to be able to trigger Roon recomputing the stored value.

Any other suggestions as to what I can try?

5

@benjamin Still no luck cracking this problem - for now I’ve resorted to prioritising the FLAC from Qobuz that does behave more in keeping. Is there an option to completely erase the album from the library and trigger a refresh of the api data? I’ve even re-written the tags in case it helped, but it hasn’t worked.

PS I’ve seen my other thread relating to ARC shutdown was closed automatically, but that issue has just happened once again after several days when I thought the issue was solved. Alas not.

6

Hey @Greg_Ince,

Thanks for the update. Since the tag editors did not surface anything and Roon would not recompute the stored value, please send the files to our uploader for analysis and let us know once uploaded, so that we can check the files on our end. That will let us take a closer look at what Roon is reading here.

https://workdrive.zohoexternal.com/collection/nocvrfc5b2ddab55140af8640f1d7ce13291e/external

7

OK - thanks, @noris I’ve done that (23 files for the standard version of Boards of Canada’s Geogaddi, and 24 for the japanese import version).

Are you able to confirm that my other support thread about ARC crashing remains an open case, please?

8

I believe you can flag the last post there and ask the moderators to reopen the thread.

9

Thanks for the tip, @Arlen

10

Thanks for sending those over @Greg_Ince, our team will take a closer look, and we’ll follow up with more information as soon as possible. :folded_hands:

11

Thanks, @benjamin - I’m considering adding replaygain tags to all my local library files at some point, but I wonder if I added tags to these files, and then switched on the prefer tags option they might cause a refresh…?

12

Hi @benjamin - I think I’ve answered my own question. Toggling this on with updated tags present didn’t change the Roon leveling value referenced in ARC. Any other ideas about flushing these sticky cached API values that I could do / try?

13

Hi @Greg_Ince ,

You can try to make a Backup, remove the album from Roon, run a Roon Settings → Library → Clean Up Library function, and that may help. The team is still looking into this, but once we hear back we will update you, thanks in advance for your patience.

15

Thanks @noris I’ll try this.

16

@noris OK - this seems to have have worked after I did this tonight.

It would be great to find out what happened to trigger this, but if it happens again, at least I’ll know what to do.

The process was as you outlined, but as I manage my files via the Apple Music/Itunes app I also needed to have a simple option to swap files back in following the Roon deletion, so that the Apple Music library could still see/point at the files too.

17

Drat - this morning the albums appears to have reset / rewritten the values somehow. This is very odd and frustrating - any indications of the change that brought this about @benjamin @noris?

18

Hi @Greg_Ince ,

No new information yet, our team still has a task in their queue to take a closer look and attempt reproduction. Once this happens, we’ll have more info to share.

Thanks for your patience in the meantime :+1:

19

Thanks for the update @benjamin - luckily it’s not my only option. As I’m a subscriber to Qobuz, I can continue to prioritise the FLAC version on there. At least BoC will get some benefit! :grinning_face:

20

a little nugget to add…

Another odd thing about this is the very first track appears to have a play count ‘hard coded’, but the subsequent tracks do not.

I’ve removed re-added deleted the album through Roon itself, a lot now, and cleaned the library up over and over again, but once the album is added again (local files and qobuz), along with the hard coded volume levelling reappearing (only for the local files) Roon appears to always list 2 plays for track 1 Ready Lets Go.

This is a track that may or may not be stored with an apostrophe, as in, Lets vs Let’s. Anyway - as you can see, I’m still puzzling over this one! :slight_smile:

21

Be aware that for some time Roon has been storing play counts for non-library tracks, so in case you played it twice, this will stick: