When playing a certain musepack file with xine or amarok, no output is heard. Both mppdec and mplayer are able to play the file just fine. I.e.: - xine http://thelonious.dnsalias.com/bla.mpc does not produce sound. - xine http://thelonious.dnsalias.com/bla.wav plays wonderfully. - mplayer http://thelonious.dnsalias.com/bla.mpc plays wonderfully as well The problem occurs both on my athlon-xp (CFLAGS="-O2 -march=athlon-xp -pipe") and on my pentium3 (CFLAGS="-Os -march=pentium3 -pipe"). There are *many* musepack files that do play correctly; it is just this specific one that doesn't. Reproducible: Always Steps to Reproduce: 1. xine http://thelonious.dnsalias.com/bla.mpc 2. 3. Actual Results: no sound Expected Results: sound, like with mplayer or with mppdec Packages installed: media-libs/libmpcdec-1.2.2 media-libs/xine-lib-1.1.4-r2 media-video/xine-ui-0.99.5_pre20060716 media-video/mplayer-1.0_rc1-r2 media-sound/musepack-tools-1.15v
Same here with media-video/xine-ui-0.99.5_pre20070303.
Let me take a look at the sample.
I found another song with the same problem. The first 10 seconds of it are at http://thelonious.dnsalias.com/bla2.mpc. Again, mplayer, mppdec, and even xmms play it just fine, but xine (and hence amarok) fail.
The problem seems to be that xine erroneously selects the MPEG audio demux plugin instead of the musepack demux plugin. This is printed out by xine --verbose bla.mpc. Also, when specifying the demux plugin explicitely (xine bla.mpc#demux:mpc), the file plays correctly.
Created attachment 119594 [details, diff] don't let mpgaudio demuxer handle musepack It turns out that the sniff_buffer_looks_like_mp3 function in demux_mpgaudio.c on a small number of musepackfiles decides erroneously that it has an mp3 stream, based upon some internal headers it finds (or thinks to find). I don't understand exactly why a file that starts with a musepack fourcc code ('MP+' and 0x07, if I'm not mistaken) get's subjected to mp3 treatment. I also don't understand why demux_mpgaudio.c doesn't use the fourcc codes to decide whether it has an mp3 stream or not. Having said that, attached is a patch that let's the sniff_buffer_looks_like_mp3 function check the fourcc code for the file being musepack, and return the appropriate return code if so. This fixes the problem for me.
Your patch is not suitable. The correct fix would be to change the priorities of demuxers so that the musepack demuxer gets always checked first. I'll see to fix for 1.1 series of xine-lib as soon as I have time. xine-lib-1.2 already handles it correctly.
Created attachment 120855 [details, diff] Adjust musepack demuxer priority Diego, I understand that you are a busy man. I believe the attached file implements the fix you suggest in comment 6. I tested it and it also solves the problem. Could you be so kind as to commit it? Thanks in advance. Bram
Thanks, this patch is good, and I've committed it (without comments) on xine-lib (the comments on priorities would deserve a separate file, for now I'd leave that to ChangeLog and hg log). Somebody from media-video should now apply the patch (with comments is easier to know why it got applied); anyway it will be in 1.1.7 that should be released soon enough.
Consider this fixed by upstream, as 1.1.7 (and 1.1.8) were released already.
