MPD does not play concatenated mp3 files

[mxjeff]

I'm forwarding a bug reported on bugs.debian.org/990160.

Bug report

I've noticed that music players that use mpd,like cantata, do not play
concatenated mp3 files to the end but stop after the first part of the
concatenated file.

For example: cat mvmt1.mp3 mvmt2.mp3 mvmt3.mp3 > symph1.mp3
will play only mvmt1.mp3 on an mpd-based player when symph1.mp3 is
played.

This does NOT happen on music players that do not use mpd, like vlc or
elisa (or any android music player).

The only work-around is to use a non-mpd player for this.

Concatenated mp3 files are useful when one wants to create a single mp3 for
a classical piece composed of many movements, as above, and create a
playlist of several of these. Each symphony will then be played
completely but the next symphony to play can be a shuffle choice (but
without shuffling the individual movements within each symphony).

Version

Debian package from bullseye 0.22.6-1+b1

Log

No log provided

[naglis]

I have tested locally with mad, mpg123 and ffmpeg decoders independently, but could not reproduce (an MP3 combined using cat played all combined files just fine). We are missing some information in the bug report (mpd --version information and verbose log output). Also, a sample of the combined MP3 file that cannot play past the first file would be useful.

Lastly, I am not sure if the MP3 file combined using cat can be considered valid (e.g. the headers of the 2nd..last MP3 appearing in the middle)? IIUC, a more correct way to join the MP3s would be using e.g. ffmpeg.

[em2jacks]

I've attached 3 mp3 files:
cat wishing_you_were_here.mp3 linda_ronstadt__youre_no_good.mp3 > test-2-songs.mp3
test-mp3-concat.tar.gz
mpd-version.txt

Also attached is the output of mpd --version > mpd-version.txt. The attached test-2-songs.mp3 only played the first song in cantata and cycled back to that one when playing test-2-songs.mp3 in repeat mode.

Here is the only log output I saw (from the cantata player using mpd):
Jul 03 16:43 : player: played "http://127.0.0.1:33449/home/jack/mp3/Jack/test-2-songs.mp3?album=chicago%20best&artist=Chicago&title=Wishing%20You%20Were%20Here&genre=Other&year=1975&time=226&track=8&id=-1&cantata=song"
Jul 03 16:44 : player: played "http://127.0.0.1:33449/home/jack/mp3/Jack/test-2-songs.mp3?album=chicago%20best&artist=Chicago&title=Wishing%20You%20Were%20Here&genre=Other&year=1975&time=226&track=8&id=-1&cantata=song"
Jul 03 16:44 : player: played "http://127.0.0.1:33449/home/jack/mp3/Jack/test-2-songs.mp3?album=chicago%20best&artist=Chicago&title=Wishing%20You%20Were%20Here&genre=Other&year=1975&time=226&track=8&id=-1&cantata=song"
(END)

I am not sure if the MP3 file combined using cat can be considered valid

I believe this is valid and it works without issue for non-mpd players like vlc, as well as every player I have on my Android phone, including merged classical operas with dozens of individual movements.

It would not be correct to require a more complex method of joining mp3 just to use mpd; a quick google search shows concatenation is used in both Linux and Windows to merge mp3 files into one large one.

[naglis]

I could reproduce using a concatenated MP3 from the files provided by @em2jacks.

mad

Using mad decoder it does not play past the first file for me. The duration reported is of the first file. I could jump to the second file by seeking to a duration that would fall into the second file (e.g. at 4:40).

Log

Jul 04 01:27:58 playlist: play 0:"/tmp/test-2-songs.mp3"
Jul 04 01:27:58 decoder_thread: probing plugin mad
Jul 04 01:27:58 client: [5] command returned 0
Jul 04 01:27:58 mad: detected LAME version 3.92 ("LAME3.92 ")
Jul 04 01:27:58 mad: LAME peak found: 0.000000
Jul 04 01:27:58 mad: encoder delay is 576, encoder padding is 2196
Jul 04 01:27:58 decoder: audio_format=44100:24:2, seekable=true
Jul 04 01:27:58 client: [5] process command list
Jul 04 01:27:58 client: process command "status"
Jul 04 01:27:58 client: command returned 0
Jul 04 01:27:58 client: process command "currentsong"
Jul 04 01:27:58 client: command returned 0
Jul 04 01:27:58 client: [5] process command list returned 0
Jul 04 01:27:58 output: opened "PulseAudio" (pulse) audio_format=44100:24:2
Jul 04 01:27:58 client: [5] closed
Jul 04 01:28:02 client: [6] opened from local
Jul 04 01:28:02 client: [6] process command "seekcur "260""
Jul 04 01:28:02 client: [6] command returned 0
Jul 04 01:28:02 client: [6] process command list
Jul 04 01:28:02 client: process command "status"
Jul 04 01:28:02 client: command returned 0
Jul 04 01:28:02 client: process command "currentsong"
Jul 04 01:28:02 client: command returned 0
Jul 04 01:28:02 client: [6] process command list returned 0
Jul 04 01:28:02 client: [6] closed
Jul 04 01:28:19 player: played "/tmp/test-2-songs.mp3"
Jul 04 01:28:19 playlist: stop
Jul 04 01:28:19 output: closed "PulseAudio" (pulse)

mpg123

Using mpg123 decoder it does play past the first file for me. The duration reported is of the first file and seeking past the beginning of second file was not possible (playback after seek starts at the beginning of the second file).

Log

Jul 04 01:37:39 client: [41] process command "play"
Jul 04 01:37:39 playlist: play 0:"/tmp/test-2-songs.mp3"
Jul 04 01:37:39 client: [41] command returned 0
Jul 04 01:37:39 client: [41] process command list
Jul 04 01:37:39 client: process command "status"
Jul 04 01:37:39 client: command returned 0
Jul 04 01:37:39 client: process command "currentsong"
Jul 04 01:37:39 client: command returned 0
Jul 04 01:37:39 client: [41] process command list returned 0
Jul 04 01:37:39 decoder_thread: probing plugin mpg123
Jul 04 01:37:39 Warning: Xing stream size off by more than 1%, fuzzy seeking may be even more fuzzy than by design!
Jul 04 01:37:39 decoder: audio_format=44100:16:2, seekable=true
Jul 04 01:37:39 output: opened "PulseAudio" (pulse) audio_format=44100:16:2
Jul 04 01:37:39 client: [41] closed
Jul 04 01:37:41 client: [42] opened from local
Jul 04 01:37:41 client: [42] process command "seekcur "260""
Jul 04 01:37:41 client: [42] command returned 0
Jul 04 01:37:41 client: [42] process command list
Jul 04 01:37:41 client: process command "status"
Jul 04 01:37:41 client: command returned 0
Jul 04 01:37:41 client: process command "currentsong"
Jul 04 01:37:41 client: command returned 0
Jul 04 01:37:41 client: [42] process command list returned 0
Jul 04 01:37:41 client: [42] closed
Jul 04 01:37:41 Warning: Encountered more data after announced end of track (frame 10591/10591). Frankenstein!
Jul 04 01:41:44 player: played "/tmp/test-2-songs.mp3"
Jul 04 01:41:44 playlist: stop
Jul 04 01:41:44 output: closed "PulseAudio" (pulse)

ffmpeg

Using ffmpeg decoder it does play past the first file for me. The duration reported is of the combined file and seeking past the beginning of second file was possible.

Log

Jul 04 01:44:26 client: [9] process command "play"
Jul 04 01:44:26 playlist: play 0:"/tmp/test-2-songs.mp3"
Jul 04 01:44:26 client: [9] command returned 0
Jul 04 01:44:26 decoder_thread: probing plugin ffmpeg
Jul 04 01:44:26 client: [9] process command list
Jul 04 01:44:26 client: process command "status"
Jul 04 01:44:26 client: command returned 0
Jul 04 01:44:26 client: process command "currentsong"
Jul 04 01:44:26 client: command returned 0
Jul 04 01:44:26 client: [9] process command list returned 0
Jul 04 01:44:26 ffmpeg/mp3: Format mp3 probed with size=4096 and score=51
Jul 04 01:44:26 ffmpeg/mp3: invalid concatenated file detected - using bitrate for duration
Jul 04 01:44:26 ffmpeg/mp3: pad 576 2196
Jul 04 01:44:26 ffmpeg/mp3: Skipping 0 bytes of junk at 1043.
Jul 04 01:44:26 ffmpeg: detected input format 'mp3' (MP2/3 (MPEG audio layer 2/3))
Jul 04 01:44:26 ffmpeg/mp3: Before avformat_find_stream_info() pos: 1043 bytes read:8192 seeks:0 nb_streams:1
Jul 04 01:44:26 ffmpeg/mp3: demuxer injecting skip 1105 / discard 0
Jul 04 01:44:26 ffmpeg/mp3float: skip 1105 / discard 0 samples due to side data
Jul 04 01:44:26 ffmpeg/mp3float: skip 1105/1152 samples
Jul 04 01:44:26 ffmpeg/mp3: All info found
Jul 04 01:44:26 ffmpeg/mp3: Estimating duration from bitrate, this may be inaccurate
Jul 04 01:44:26 ffmpeg/mp3: stream 0: start_time: 0.0250567 duration: 503.552
Jul 04 01:44:26 ffmpeg/mp3: format: start_time: 0.025057 duration: 503.552 (estimate from bit rate) bitrate=128 kb/s
Jul 04 01:44:26 ffmpeg/mp3: After avformat_find_stream_info() pos: 22547 bytes read:24576 seeks:0 frames:50
Jul 04 01:44:26 ffmpeg: codec 'mp3'
Jul 04 01:44:26 decoder: audio_format=44100:f:2, seekable=true
Jul 04 01:44:26 ffmpeg/mp3float: skip 1105 / discard 0 samples due to side data
Jul 04 01:44:26 ffmpeg/mp3float: Could not update timestamps for skipped samples.
Jul 04 01:44:26 ffmpeg/mp3float: skip 1105/1152 samples
Jul 04 01:44:26 output: opened "PulseAudio" (pulse) audio_format=44100:f:2
Jul 04 01:44:26 client: [9] closed
Jul 04 01:44:29 client: [10] opened from local
Jul 04 01:44:29 client: [10] process command "seekcur "260""
Jul 04 01:44:29 client: [10] command returned 0
Jul 04 01:44:29 client: [10] process command list
Jul 04 01:44:29 client: process command "status"
Jul 04 01:44:29 client: command returned 0
Jul 04 01:44:29 client: process command "currentsong"
Jul 04 01:44:29 client: command returned 0
Jul 04 01:44:29 client: [10] process command list returned 0
Jul 04 01:44:29 client: [10] closed
Jul 04 01:44:34 ffmpeg/mp3float: discarding ID3 tag
Jul 04 01:44:47 client: [11] opened from local
Jul 04 01:44:47 client: [11] process command "seekcur "496""
Jul 04 01:44:47 client: [11] command returned 0
Jul 04 01:44:47 client: [11] process command list
Jul 04 01:44:47 client: process command "status"
Jul 04 01:44:47 client: command returned 0
Jul 04 01:44:47 client: process command "currentsong"
Jul 04 01:44:47 client: command returned 0
Jul 04 01:44:47 client: [11] process command list returned 0
Jul 04 01:44:47 client: [11] closed
Jul 04 01:44:55 player: played "/tmp/test-2-songs.mp3"
Jul 04 01:44:55 playlist: stop
Jul 04 01:44:55 output: closed "PulseAudio" (pulse)

This is just one test case, but it looks like the ability to play MP3 files combined using cat depends on the decoder, and using ffmpeg yielded best results. @em2jacks, could you try disabling mad and mpg123 decoders in MPD config file, restart MPD and check if that would work for you? The decoders can be disabled by adding the following blocks to the config:

decoder {
    plugin "mad"
    enabled "no"
}

decoder {
    plugin "mpg123"
    enabled "no"
}

[em2jacks]

I ran it with just mad disabled and cantata played both songs, where before it stopped at the first one.

Thank you! This was an important issue for playing classical music with mpd.

[MaxKellermann]

The file uploaded by @em2jacks contains a Xing header specifying the total song length and an encoder delay+padding. Delay means ignore this number of frames at the beginning of the file, padding means ignore this number of frames at the end of the file. MPD's "mad" decoder plugin does just that - if the given end position minus the padding is reached, it stops decoding the song.

I think MPD's behavior in the presence of a Xing header is correct, and the test file is broken. On the other hand, decoding past the end of the declared song length sounds like a bug - not one that really needs to be fixed, but it's not correct behavior.

The fact that some plugins/libraries/programs do play concatenated mp3 files doesn't prove that concatenated mp3 files are valid. It only demonstrates that some software apparently ignores the header settings.

Of course, we could hack MPD to scan the whole file for additional headers to support concatenation, but you can imagine that this would add considerable overhead, and since those files are broken, I don't think that's worth anybody's time. Let's not.

Each symphony will then be played completely but the next symphony to play can be a shuffle choice (but without shuffling the individual movements within each symphony).

Maybe MPD instead needs a feature "random/shuffle mode = any/album" - where consecutive songs belonging to an album remain together. (That, of course, needs a definition of what an "album" is.)

[em2jacks]

I hope any remaining discussion of this issue will focus squarely on what is  practical, easy to use and provides a valuable feature not easily available otherwise. Playing concatenated mp3 files meets the last 3 criteria brilliantly.   > I think MPD's behavior in the presence of a Xing header is correct, and the test file is broken. I think the test file of concatenated mp3 is a common, easy to create, extremely useful example and any decoder that plays it to the end has great applicability.

The fact that some plugins/libraries/programs do play concatenated mp3 files doesn't prove that concatenated mp3 files are valid.

programs that play concatenated mp3, not only decoders like ffmpeg and mpg123 but also music players on Android, allow much greater flexibility and prove that concatenated mp3 files are very useful. 

Maybe MPD instead needs a feature "random/shuffle mode = any/album" - where consecutive songs belonging to an album remain together.

So it would be impossible with this feature to create a single  album with all 5 of Beethoven's Piano Concertos, each concerto played in correct order but the next concerto chosen at random. No doubt other bells, whistles, pulleys and levers can be added to this proposed MPD feature to make the above case work, but concatenated mp3 + decoders that work with them are a much simpler solution (and one that is indeed proven to work even as I type this). thanks,--jack On Thursday, August 5, 2021, 7:41:24 AM EDT, Max Kellermann ***@***.***> wrote: The file uploaded by @em2jacks contains a Xing header specifying the total song length and an encoder delay+padding. Delay means ignore this number of frames at the beginning of the file, padding means ignore this number of frames at the end of the file. MPD's "mad" decoder plugin does just that - if the given end position minus the padding is reached, it stops decoding the song. I think MPD's behavior in the presence of a Xing header is correct, and the test file is broken. On the other hand, decoding past the end of the declared song length sounds like a bug - not one that really needs to be fixed, but it's not correct behavior. The fact that some plugins/libraries/programs do play concatenated mp3 files doesn't prove that concatenated mp3 files are valid. It only demonstrates that some software apparently ignores the header settings. Of course, we could hack MPD to scan the whole file for additional headers to support concatenation, but you can imagine that this would add considerable overhead, and since those files are broken, I don't think that's worth anybody's time. Let's not. Each symphony will then be played completely but the next symphony to play can be a shuffle choice (but without shuffling the individual movements within each symphony). Maybe MPD instead needs a feature "random/shuffle mode = any/album" - where consecutive songs belonging to an album remain together. (That, of course, needs a definition of what an "album" is.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.