Bug 176689 – xine fails to play musepack file

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Bram Verweij 2007-05-01 14:22:28 UTC]

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

[Comment 1 Łukasz Damentko (RETIRED) 2007-05-01 14:41:17 UTC]

Same here with media-video/xine-ui-0.99.5_pre20070303.

[Comment 2 Diego Elio Pettenò (RETIRED) 2007-05-01 16:30:21 UTC]

Let me take a look at the sample.

[Comment 3 Bram Verweij 2007-05-04 15:20:54 UTC]

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.

[Comment 4 Bram Verweij 2007-05-17 20:27:30 UTC]

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.

[Comment 5 Bram Verweij 2007-05-18 13:49:54 UTC]

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.

[Comment 6 Diego Elio Pettenò (RETIRED) 2007-05-18 14:00:28 UTC]

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.

[Comment 7 Bram Verweij 2007-06-01 09:05:56 UTC]

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

[Comment 8 Diego Elio Pettenò (RETIRED) 2007-06-01 09:48:30 UTC]

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.

[Comment 9 Diego Elio Pettenò (RETIRED) 2007-12-29 21:53:29 UTC]

Consider this fixed by upstream, as 1.1.7 (and 1.1.8) were released already.