Description of problem: flac files are not playing, though (using "aaxine -d") xine-lib seems to load the correct plugin (/usr/lib/xine/plugins/1.1.6/xineplug_flac.so) it doesn't seem to load the demuxer. Version-Release number of selected component (if applicable): 1.1.6-1 How reproducible: I've used both amarok (w/ xine-lib engine) and xine itself. Steps to Reproduce: 1. 2. 3. Actual results: flac files do not play. Expected results: flac files do play. Additional info:
Created attachment 153288 [details] output of: aaxine -d 'file.flac'
Works fine here on x86_64 with both amarok and xine, can't test i386 at the moment. Posting the first let's say 100kB of a FLAC that doesn't play could be beneficial for testing purposes.
Alternatively, here's some FLAC's for testing - 1.flac and 2.flac do play here. http://ff123.net/samples.html
Interestingly, albeit unrelated, "aaxine -d test.flac" gives: dlopen() failed: libX11.so: cannot open shared object file: No such file or directory main: video driver aa failed and installing libX11-devel fixes the dlopen error, but not the main one.
(In reply to comment #4) > and installing libX11-devel fixes the dlopen error, Something like this (for xine) could work: libx11so=$(ls -1 %{_libdir}/libX11.so.? | tail -n 1) if [ -n "$libx11so" -a -f "$libx11so" ] ; then sed -i -e "s/\"libX11\\.so\"/\"$(basename $libx11so)\"/" src/aaui/main.c fi > but not the main one. "The main one" being FLAC's don't play? On which arch? Any FLAC's you tried with available somewhere online?
(In reply to comment #5) > "The main one" being FLAC's don't play? Never mind, you probably meant "main: video driver aa failed".
OKay I tested with the files pulled down from ff123.net and they worked fine, so I looked to figure out what the difference is and it had an ID3v2 tag. I stripped that and it works fine. So it's the fact there is an ID3v2 tag on the file that causes xine not to play it. Maybe this should be a feature enhancement and not a bug. (Summary changed to reflect actual problem)
Thanks for investigating. It seems to be a matter of exactly how the files are tagged - for example tagging with id3tag from the id3lib package results in the tag being at the beginning of the file and screwing xine, while when tagging with kid3 the tag ends up somewhere after the FLAC header in the file, and xine seems happy with that. From http://flac.sourceforge.net/faq.html: "Out of convenience, the reference decoder knows how to skip ID3 tags so that they don't interfere with decoding. But you should not expect any tags beside FLAC tags to be supported in applications; some implementations may not even be able to decode a FLAC file with ID3 tags." Based on that and because I don't see this being a consequence of xine-lib packaging, I think this bug report/RFE would be better off filed against upstream xine-lib instead of the Fedora package. Thoughts?
Seems to be fixed/implemented in upstream 1.1.7 which will be available in devel really soon now, and probably as an update to at least F7 a bit later as well.
Reassigning to Aurelien to decide whether FC-6 will be updated to 1.1.7 or patched to include this fix.
I'll update FC-6 to 1.1.7, I still have an FC-6 box to test it on.