MPD
MPD copied to clipboard
MusicPlayerDaemon
MPD 0.24.4 does not respect ReplayGain tags on .mp3 files even when enabled in config
Bug report
Describe the bug
Replaygain tags on .mp3 files are ignored.
Expected Behavior
Replaygain tags should affect the output gain of .mp3 files when played.
Actual Behavior
.mp3 files are played as if there were no replaygain tags and are played at the original volume, even with other replaygain related settings (like "preamp").
Version
Music Player Daemon 0.24.4 (v0.24.4) Copyright 2003-2007 Warren Dukes [email protected] Copyright 2008-2025 Max Kellermann [email protected] This is free software; see the source for copying conditions. There is NO warranty; not even MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Database plugins: simple proxy upnp
Storage plugins: local udisks nfs curl
Neighbor plugins: upnp udisks
Decoder plugins: [mpg123] mp3 [mad] mp3 mp2 [vorbis] ogg oga [oggflac] ogg oga [flac] flac [opus] opus ogg oga [dsdiff] dff [dsf] dsf [faad] aac [mpcdec] mpc [wavpack] wv [openmpt] mptm mod s3m xm it 669 amf ams c67 dbm digi dmf dsm dtm far imf ice j2b m15 mdl med mms mt2 mtm nst okt plm psm pt36 ptm sfx sfx2 st26 stk stm stp ult wow gdm mo3 oxm umx xpk ppm mmcmp [modplug] 669 amf ams dbm dfm dsm far it med mdl mod mtm mt2 okt s3m stm ult umx xm [mikmod] amf dsm far gdm imf it med mod mtm s3m stm stx ult uni xm [sidplay] sid mus str prg P00 [wildmidi] mid [fluidsynth] mid [gme] ay gbs gym hes kss nsf nsfe rsn sap spc vgm vgz [ffmpeg] 264 265 266 302 3g2 3gp 4xm 669 722 aa aa3 aac aax abc ac3 ac4 ace acm act adf adp ads adx aea afc aiff aix al alias_pix alp amf amr amrnb amrwb ams anm ans apc ape apl apm apng aptx aptxhd aqt argo_asf argo_brp argo_cvg art asc asf asf_o ass ast au avc avi avif avr avs avs2 avs3 bcstm bethsoftvid bfi bfstm bin bink binka bit bitpacked bmp_pipe bmv boa bonk brender_pix brstm c2 c93 caf cdata cdg cdxl cgi cif cine codec2raw concat cri_pipe dash dat data daud dav dbm dds_pipe dfa dff dfpwm dif digi dirac diz dmf dnxhd dpx_pipe dsf dsicin dsm dss dst dtk dtm dts dtshd dv dvbsub dvbtxt dvdvideo dxa ea eac3 ec3 evc exr_pipe f32be f32le f4v f64be f64le fap far ffmetadata film_cpk fits flac flic flm flv frm fsb fwse g722 g723_1 g726 g726le g729 gdm gdv gem_pipe genh gif gif_pipe gsm gxf h261 h263 h264 h265 h266 h26l hca hcom hdr_pipe heic heif hevc hls hnm iamf ice ico idcin idf idx iff ifv ilbc image2 image2pipe imf imx ipmovie ipu ircam ism isma ismv iss it itgz itr itz iv8 ivf ivr j2b j2k j2k_pipe jacosub jpeg_pipe jpegls_pipe jpegxl_pipe jv jxl kux kvag laf lc3 lmlm4 loas lrc lvf lxf m15 m2a m4a m4b m4v mac mca mcc mdgz mdl mdr mdz med mgsts microdvd mid mj2 mjpeg mjpg mk3d mka mks mkv mlp mlv mm mmcmp mmf mms mo3 mod mods moflex mov mp2 mp3 mp4 mpa mpc mpc8 mpeg mpegts mpegtsraw mpegvideo mpl2 mpo mptm msbc msf msnwctcp msp mt2 mtaf mtm mtv musx mv mvi mxf mxg nfo nist nsp nst nsv nut nuv obu ogg okt oma omg osq paf pam_pipe pbm_pipe pcx_pipe pdv pfm_pipe pgm_pipe pgmyuv_pipe pgx_pipe phm_pipe photocd_pipe pictor_pipe pjs plm pmp png_pipe pp_bnk ppm ppm_pipe psd_pipe psm psp psxstr pt36 ptm pva pvf qcif qcp qdraw_pipe qoa qoi_pipe r3d rco rcv rcwt rgb rka rl2 rm roq rpl rsd rso rt rtp rtsp s16be s24be s24le s32be s32le s337m s3gz s3m s3r s3z sami sap sb sbc sbg scc scd sdns sdp sdr2 sds sdx ser sf sfx sfx2 sga sgi_pipe shn sln smi smk smush sol son sox spdif sph srt ss2 st26 stk stl stm stp str sub sunrast_pipe sup svag svg_pipe svs sw swf tak tco tedcaptions thd thp tiertexseq tiff_pipe tmv tta txd txt ty ty+ u16be u24be u24le u32be u32le ub ul ult umx usm uw v v210 vag vapoursynth vb vbn_pipe vc1 vidc viv vividas vmd voc vpk vqe vqf vql vt vtt vvc w64 wa wav way wc3movie webm webm_dash_manifest webp_pipe wma wow wsaud wsd wsvqa wtv wv wve xa xbin xbm_pipe xl xm xmd xmgz xmr xmv xmz xpk xpm_pipe xvag xwd_pipe xwma y4m yop yuv yuv10 rtp:// rtsp:// rtsps:// [sndfile] wav aiff aif au snd paf iff svx sf voc w64 pvf xi htk caf sd2 [pcm]
Filters: libsamplerate soxr
Tag plugins: id3tag
Output plugins: shout null fifo pipe alsa ao oss openal solaris pipewire pulse jack httpd snapcast recorder
Encoder plugins: null vorbis opus lame twolame wave flac
Archive plugins: [bz2] bz2 [zzip] zip [iso] iso
Input plugins: file archive alsa qobuz curl ffmpeg nfs mms cdio_paranoia
Playlist plugins: extm3u m3u pls xspf asx rss flac cue embcue
Protocols: file:// alsa:// cdda:// ftp:// ftps:// gopher:// hls+http:// hls+https:// http:// https:// mms:// mmsh:// mmst:// mmsu:// nfs:// qobuz:// rtmp:// rtmpe:// rtmps:// rtmpt:// rtmpte:// rtmpts:// rtp:// rtsp:// rtsps:// scp:// sftp:// smb:// srtp://
Other features: avahi dbus udisks epoll icu inotify ipv6 systemd tcp un
Configuration
music_directory "/home/public/music"
playlist_directory "~/.config/mpd/playlists"
db_file "~/.config/mpd/database"
pid_file "~/.config/mpd/pid"
state_file "~/.config/mpd/state"
sticker_file "~/.config/mpd/sticker.sql"
bind_to_address "any"
bind_to_address "~/.config/mpd/socket"
port "6600"
restore_paused "yes"
password "redacted@read,add,control,admin"
input {
plugin "curl"
}
audio_output {
type "pipewire"
name "PipeWire Sound Server"
format "48000:*:2"
}
audio_output {
type "fifo"
name "Visualizer feed"
path "/home/stephen/temp/mpd.fifo"
format "44100:16:2"
#buffer_time "100000"
}
replaygain "track"
replaygain_preamp "-1.5"
replaygain_missing_preamp "-1.5"
Log
Verbose log: https://paste.debian.net/1376213/ Backup paste link: https://seodisparate.com/static/uploads/mpd_verbose_log_0.24.4.txt
The "Log" section does not ask for crash logs.
Should I then post some of what it logs? I use systemd, and there isn't much other than startup logs and when songs have started playing and have finished playing.
EDIT: I've added the startup logs and a little of status log that shows up when playing.
This log is incomplete (or not in verbose mode, as was requested from you).
This log is incomplete (or not in verbose mode, as was requested from you).
Sorry, I seemed to have missed that detail when submitting the bug report. I had to let MPD play in a tty environment because my desktop has a script that queries MPD to get the status to put on my systray/bar.
I pasted it onto paste.debian.net for 90 days for this bug report.
EDIT: and it seems I will have to change my MPD password now, but it isn't that big of a deal.
In the meantime, I did a git-bisect to find the commit introducing the bug. It was commit b9488d0f3569c52f42334ee55e20acadd917a869 . This was done by git-bisect'ing between the latest two releases/tags (since it is known to me that the release before the latest release doesn't have this bug).
Your log shows that replay gain is indeed being used (scale=0.84). What scale would you expect instead of 0.84?
To be sure, I did some tests again with a build of mpd disabling id3tag ( meson configure -Did3tag=disabled ), and the scale output with and without this is different.
The song I used was Splatoon_Full_Sleeve_InK_Me_uP_OC_ReMix.mp3 and I gave it replay-gain tags using rsgain: rsgain custom -s i -c p Splatoon_Full_Sleeve_InK_Me_uP_OC_ReMix.mp3. I cannot redistribute this song as per the terms-of-use for OCReMix since songs with modified tags cannot be redistributed. This particular song starts loudly and one can determine if replay-gain is working withing seconds of playing.
With id3tag defaulted to enabled, the logs with "scale":
2025-05-27T11:42:28 replay_gain: scale=0.84139514
2025-05-27T11:42:28 replay_gain: scale=0.84139514
With id3tag disabled, the logs with "scale":
2025-05-27T11:43:03 replay_gain: scale=0.84139514
2025-05-27T11:43:03 replay_gain: scale=0.19724225
2025-05-27T11:43:03 client: [pid=7493 uid=1000] process command "status"
2025-05-27T11:43:03 replay_gain: replay gain mode has changed off->track
2025-05-27T11:43:03 replay_gain: scale=0.84139514
2025-05-27T11:43:03 client: [pid=7493 uid=1000] command returned 0
2025-05-27T11:43:03 replay_gain: scale=0.19724225
So for this particular song, a scale of 0.84 is apparently incorrect.
EDIT: I realize disabling the id3tag option breaks parsing MP3. I tried a build by reverting just commit b9488d0f3569c52f42334ee55e20acadd917a869 and that also happens to fix replaygain not working properly.
"Apparently" is not good enough here. You claim that what MPD is doing is wrong, but that requires specifying exactly what behavior you expect.
Your logs show that MPD already does what your "Expected Behavior" text describes. Therefore, I must assume that your problem does not exist. But you insist it exists, yet all you come up with is "a scale of 0.84 is apparently incorrect".
But what is correct, and why do you believe that value is the correct value for your MP3 file? What are the ReplayGain tags in your file? Can you upload it somewhere?
"Apparently" is not good enough here. You claim that what MPD is doing is wrong, but that requires specifying exactly what behavior you expect.
I was trying to be polite.
Your logs show that MPD already does what your "Expected Behavior" text describes. Therefore, I must assume that your problem does not exist. But you insist it exists, yet all you come up with is "a scale of 0.84 is apparently incorrect".
But what is correct, and why do you believe that value is the correct value for your MP3 file? What are the ReplayGain tags in your file? Can you upload it somewhere?
I guess on Github, people need files instead of statements about the bug to prove it exists.
The tags on the file in question according to ffmpeg -i ...mp3 -f ffmetadata out.txt:
https://paste.debian.net/1376844/
(Backup link in case the previous one goes down: https://seodisparate.com/static/uploads/mp3_mpd_issue_2308_metadata.txt )
This particular song with this particular metadata does not get adjusted by MPD. Do I have to make a video of my computer (via obs) to demonstrate this?
You omitted the answer to the first (double) question. That is not very polite.
You omitted the answer to the first (double) question. That is not very polite.
You mean this question?
But what is correct, and why do you believe that value is the correct value for your MP3 file?
I'm certain that information directly correlates with the bug this issue was opened for. I've already posted additional logs with the scale=... lines. My earlier statement about "So for this particular song, a scale of 0.84 is apparently incorrect" is directly associated with the answer of the question you seem insistent for a response for. So I guess I'll make it clear:
The value of scale=0.19724225 is what I believe to be the correct value for this particular MP3 file. This is clear to me as day due to this scale value only appearing on the previous release of MPD with this particular MP3 file (which is when the song has replay-gain correctly applied), whereas the bug shows itself in the latest release of MP3 and does not mention scale=0.19724225, but rather scale=0.84139514 and the song is much louder in comparison.
This issue should concern the bug that this issue was created for. Arguing whether or not the issue reporter is "polite" besides the point, especially when the reporter has been compliant with giving needed additional information. If you just decide to play with details like this, well it's not a good look.
I'm trying to help improve this software by reporting a bug, such that fixing this bug will benefit everyone that uses this software. All I ask is that we put aside snide comments and just focus on getting this verified and fixed.
I have several files that also exhibit this issue, it seems that id3_tag_parse fails to parse the tag data in some cases, causing it to return a null pointer. This is definitely a bug with libid3tag, I'm not sure if it would make sense for MPD to fall back to libmpg123 in the event of a parsing failure.
I checked one of the file's tags using mid3v2 --list-raw, and saw that it contained some UTF-16 tags:
% mid3v2 --list-raw 'HoneyComeBear - Natsuzora (Synthion & YUKIYANAGI Remix).mp3'
Raw IDv2 tag info for HoneyComeBear - Natsuzora (Synthion & YUKIYANAGI Remix).mp3
TIT2(encoding=<Encoding.UTF16: 1>, text=['Natsuzora ナツゾラ (Synthion & YUKIYANAGI Remix)'])
TPE1(encoding=<Encoding.UTF16: 1>, text=['HoneyComeBear'])
TRCK(encoding=<Encoding.LATIN1: 0>, text=['1/1'])
TALB(encoding=<Encoding.UTF16: 1>, text=['Natsuzora ナツゾラ (Synthion & YUKIYANAGI Remix)'])
TDRC(encoding=<Encoding.LATIN1: 0>, text=['2019'])
TCON(encoding=<Encoding.UTF16: 1>, text=['J-Core'])
TBPM(encoding=<Encoding.UTF16: 1>, text=['170'])
TXXX(encoding=<Encoding.LATIN1: 0>, desc='_custom_rating', text=['8'])
TXXX(encoding=<Encoding.LATIN1: 0>, desc='REPLAYGAIN_TRACK_PEAK', text=['1.000000'])
TXXX(encoding=<Encoding.LATIN1: 0>, desc='REPLAYGAIN_TRACK_GAIN', text=['-13.70 dB'])
TENC(encoding=<Encoding.UTF16: 1>, text=['LAME in FL Studio 20'])
...
Rewriting the tags in UTF-8 encoding using eyeD3 fixed the issue: eyeD3 --encoding utf8 --force-update 'HoneyComeBear - Natsuzora (Synthion & YUKIYANAGI Remix).mp3' (I had to rerun rsgain on the file again because the null byte at the end of the replay gain tags goes missing during the encoding conversion; EDIT: This is actually another bug with libid3tag, see below). I also tried re-encoding them as utf16 and utf16-be, but neither of those are successfully parsed by libid3tag.
I haven't checked any of my other files, but it's very likely the same issue where libid3tag fails to parse the tags and returns an empty/null list of frames.
@Stephen-Seo Could you post a dump of the tags of the file that has this issue for you? (using mid3v2 --list-raw)
@Stephen-Seo Could you post a dump of the tags of the file that has this issue for you? (using
mid3v2 --list-raw)
It took some time to find mid3v2. I assume it is provided by a Python package named mutagen.
I pasted the output here:
Gist: https://gist.github.com/Stephen-Seo/3ab8c90cc49cd02f0ab2ab1683c6eac0
Self-hosted: https://seodisparate.com/static/uploads/mp3_mpd_issue_2308_mid3v2_raw_output.txt
(Because of the image metadata, the text is too large for paste.debian.net .)
The metadata on this file is in UTF-8, so that may not be it. This is a guess, but maybe it's because there's a lot of data embedded due to the album art?
EDIT: I tried playing the song without album-art metadata and stripping some other metadata like "comment". This didn't fix the replay-gain issue.
The album art tag being UTF-8 instead of LATIN-1 is a bit strange, but that doesn't seem to cause the bug. However, I noticed that your replaygain tags are UTF-8, but rsgain writes LATIN-1 tags. This is actually a different bug from the one I was having, since your file is parsed successfully...
UTF-8 replaygain tags are valid, as user defined text frames can have any encoding: https://mutagen-specs.readthedocs.io/en/latest/id3/id3v2.4.0-frames.html#txxx
So, it seems to be a bug with how libid3tag is parsing the description and value for UTF-8 TXXX tags.
If I place a breakpoint where the replaygain is parsed from the id3 tags that libid3tag has returned, here: https://github.com/MusicPlayerDaemon/MPD/blob/cf7b9e06bd7e1b877e5c5243a22efe938b0036f2/src/tag/Id3ReplayGain.cxx#L32
then I can read out the description (key) and value for the TXXX tags as they are being checked:
No idea what's going wrong in libid3tag for it to combine the key and value for a UTF8 TXXX frame, but this means my idea of falling back to libmpg123 won't always work, perhaps mpd should consider using a different library?
Anyways, if you retag your file with rsgain it should write a LATIN-1 replaygain tag, which should work fine (also I hit this bug earlier when I had to retag my file after converting all the tags to UTF-8, nice).
Also, the incorrect replay_gain: scale=0.84139514 that you were getting comes from you setting the preamp for files with missing tags to -1.5 dB (the formula to convert dB to a linear scale is 10^(0.05 * x dB), and 10^(0.05 * -1.5) = 0.84139514.
Also, the incorrect
replay_gain: scale=0.84139514that you were getting comes from you setting the preamp for files with missing tags to -1.5 dB (the formula to convert dB to a linear scale is10^(0.05 * x dB), and10^(0.05 * -1.5) = 0.84139514.
I had a feeling that was the case, though I didn't test for it directly, since I knew that the value should be much lower for the song/mp3 I was testing.
The album art tag being UTF-8 instead of LATIN-1 is a bit strange, but that doesn't seem to cause the bug. However, I noticed that your replaygain tags are UTF-8, but rsgain writes LATIN-1 tags. This is actually a different bug from the one I was having, since your file is parsed successfully...
This was because of my paranoia. I had rsgain run on a copy of the mp3 file, then used ffmpeg to transfer the tags from that file to a third file identical to the original. I actually did another test and tried playing the file directly modified by rsgain, and MPD still has issues with replaygain. The original file uses UTF-16 and LATIN-1 tags, and rsgain preserves this, while ffmpeg seems to convert tags to UTF-8 when processed.
I think the UTF-16 issue might already be fixed (just not merged yet), my guess is that it bails out of the parsing when encountering a string it deems invalid. https://codeberg.org/tenacityteam/libid3tag/pulls/19
Assuming most distros use the tenacity fork instead of the audacity one, I could have a look at what's going on with the TXXX tags. But I do not know how quickly they review and merge code, or when it'll make it into a release.
Just found this when searching on why some large number of my MP3 files are suddenly playing fantastically louder than they did before upgrading to 0.24.4. Is there a workaround besides "retag possibly thousands of files" or "revert to 0.24.3"? Can do the latter, I guess, but if there's anything I can do to help with this bug, I'd be glad to. Thanks!
I have the same problem that suddenly some songs in a playlist are louder then before. The proposed solution to use rsgain to rewrite tags has only worked for one out of three problematic songs.
For now I am using MPD main with https://github.com/MusicPlayerDaemon/MPD/commit/b9488d0f3569c52f42334ee55e20acadd917a869 reverted.
FWIW, I just updated my libid3tag to the latest git release from Codeberg, and it didn't fix the volume problem. I guess it might be necessary to open a bug with them instead. I'd posit, though, that mpd's move to using this slightly-broken library is itself still sort of a buglet over here.
I believe the bug isn't actually with libid3tag, but likely in libmpg123.
When using the mpg123 plugin, MPD uses mpg123's mpg123_id3_raw function to obtain the raw ID3 data, and then parses it with libid3tag.
This function can return that differs from what's on-disk. I was able to produce an example using the original MP3 mentioned in this ticket (without modifying tags).
I've reported the bug to mpg123 - which has an example C program to extract ID3 data using libmpg123. For convenience I also have the program available as a gist in case anyone is curious.
Using said program (here as extract and the original MP3 from https://ocremix.org/remix/OCR03853):
curl -o demo.mp3 https://ocrmirror.org/files/music/remixes/Splatoon_Full_Sleeve_InK_Me_uP_OC_ReMix.mp3
md5sum demo.mp3 # verify this matches the website - 9c4c00c4052b6c34fee4698ab7160e39
./extract demo.mp3 # should write out 87435 bytes to demo.mp3.id3
dd if=demo.mp3 of=orig.id3 bs=1 count=87435
xxd demo.mp3.id3 mpg123_id3.txt
xxd orig.id3 orig_id3.txt
diff orig_id3.txt mpg123_id3.txt
I'm not 100% sure if this is causing replaygain tags to be corrupted when read into libid3tag but - at the end of the day libmpg123 is returning data that differs from what's on-disk.
It looks like commit https://github.com/MusicPlayerDaemon/MPD/commit/6d333c77573c685a0ac4c82cfbf1c22f27c942c9 fixes this issue for me (I used git-bisect just to be sure). This is included in the master branch as well as tag v0.24.5. Can someone else also check against either one of these branch or tag to confirm that it is fixed?
This confirms @jprjr's theory that it's the libmpg123 corruption bug.