Replaygain ID3 tag encoded in UTF-16 BOM is not recognized

Support
1

Issue description:

I found out that when I turned on track replay gain, only some of my songs got replay gain, and some didn’t. But on the server side (navidrome) all those files show replay gain info, and from id3tag all the source files include replaygain_track_gain and replaygain_track_peak.

Digging further it seems that some of my files have the replaygain_track_gain tag encoded in ASCII which replaygain works (frame type $00 in id3 spec), and some of my files have it encoded in UTF-16 with BOM which replaygain doesn’t work (frame type $01 in id3 spec)

(id3 spec I’m looking at ID3 tag version 2.4.0 - Main Structure — Mutagen Specs 1.0 documentation)

Logs:

Upload description: Darkpi

Additional information:

 
Screenshot 1 is the file header for one song that replaygain failed (and has UTF16 with BOM “01FFFE” frame type)
Screenshot 2 is the file header for one song that replaygain works (and has ASCII frame type)

If it’s helpful for debugging I can provide the two .mp3 files.

(I’ll normalize my songs to all use ASCII tags for now as a workaround.)
 

Reproduction steps:

 

 

Media provider:

Subsonic

Screenshots:

 

Screenshot 1
Screenshot 11139×401 57.2 KB
 
Screenshot 2
Screenshot 21139×401 64 KB
   

2

In need the files seems ExoPlayer needs patching.

2024-01-06 04:41:31.726 Verbose/ExoPlayer:     TXXX: description=replaygain_track_gain: values=[ⴀ㤀⸀㐀㘀 搀䈀]
2024-01-06 04:41:31.727 Verbose/ExoPlayer:     TXXX: description=replaygain_track_peak: values=[㄀⸀㄀㄀㄀㐀 㐀]
3

Uploaded the two mp3 (good.mp3 bad.mp3) via https://upload.symfonium.app/

The uploaded description contains https://support.symfonium.app/t/replaygain-id3-tag-encoded-in-utf-16-bom-is-not-recognized/4061.

4

So the tags are invalid don’t know how you filled them.

VLC and FFmpeg also fails to read them:

Incorrect BOM value
Error reading frame replaygain_track_gain, skipped
Incorrect BOM value
Error reading frame replaygain_track_peak, skipped

I can add a workaround but you definitively need to fix them.

5

Ah that explains why…
I’ve already fixed the song files so consider the issue solved for me.

About the need of adding a workaround:

I tried to find where the broken tags originate from, but I cannot reproduce how those tags are written now. I assumed it’s some old ruby library that I used but rerunning them doesn’t seem to produce the broken tag, so maybe some old music player that I no longer use now?

Looking through more files I had before I fix them, some of them are missing BOM in value part of TXXX:replaygain_track_gain, and some are using UTF16-BE for the value part but still using BOM FFFE… So it was really a mess and I still have no idea where that came from…

Interesting enough that mp3tag on Windows / id3info / foobar / navidrome all reads them correctly, so I guess they also have seen many non-spec-compliance tags in the wild and have heuristic for those :rofl:

6

If you want to quickly recreate replay gain tags for your entire library I recommend using rsgain. It’s a command line program that can recursively add replay gain tags to your entire library. It’s also the default replaygain plugin in musicbrainz picard as far as I know.
It supports multithreading. I managed to get 100% load on my 5950x AND my 980 Pro 1TB SSD at the same time while running it on 6000 tracks with 32 threads on the nvme SSD. However if your music is on conventional hdds I would not run it with multiple threads as that would likely reduce performance.