MPD
MPD copied to clipboard
MusicPlayerDaemon
Give `mpg123` decoder a higher priority than `mad` decoder.
Bug report
Describe the bug
mpg123 is still actively developed. mad has been unmaintained for many years.
In my direct experiences, mad decoder produces audible glitches at the end of playback of some mp3 files. mpg123 also does, but its glitches are far quieter. I had to use headphones to hear mpg123 glitches.
Even in 2014, https://www.runeaudio.com/forum/switch-to-mpg123-decoder-for-mp3-t171.html said
I'd suggest to switch to mpg123 as default decoder for mp3 files. The libmad decoder produces some low level noise, that can be heard (especially with good headphones) in silent passages of a track (or between two tracks). It's also easy to reproduce if you activate software mixer and turn down mpd volume.
You can disable any decoder in mpd.conf if you do not want to use it, for mad this would look like this:
decoder { plugin "mad" enabled "no" }
The mpg123 decoder plugin can only read files, not streams. It is not on par with the mad decoder feature-wise, therefore we shouldn't give it a higher priority. It would be possible to implement streaming in the mp123 decoder plugin (libmpg123 allows it), but nobody has implemented that. Maybe there's a volunteer to do that?
It does fall back to ffmpeg for streams if mad is disabled, no? (I think my build, 0.23.15, does and works fine with radio streams). Can you point me to the file where the priority order is defined? (Just out of couriosity).
Based on this commit https://github.com/MusicPlayerDaemon/MPD/commit/381934985a238b6d78357e511fc2cc40c4709dab I would say it is determined by the ordering in https://github.com/MusicPlayerDaemon/MPD/blob/master/src/decoder/DecoderList.cxx
