Okay, seems like lately I’m hitting random bugs while caring about other things.. with the last paid job I had, I started finding a bug in Umbrello, then I found in kdelibs with Modular X, and today I found one in glibc. This last one seems to be a threading issue with stdio and gcc4’s internal copy of printf and who else knows what.
But this is not enough, today I stumbled across a bug in Kaffeine while testing something else…
Now I wanted to listen to Japanaradio, but also to do so using the aacplus server… usually amaroK refused even to start playing, but 1.4_beta2 seemed to start… but then crashed within xine code, and lookin up that I found that xine was using faad code in a really messed up way.. I was able to fix it and it’s now in xine-lib-1.1.1-r5. This seems to fix all the problems with playing aac/m4a files on 64-bit platforms.
Still I can’t listen to japanaradio because they don’t seem to recognise xine as a simpler player and consider it a streamripper :/
I’m impatient to test xine-lib-1.1.1-r5 :)I also posted a feature request on Xine project Sourceforge page : http://sourceforge.net/trac…I ask to use external FAAD2 library instead of one internal which is old, broken and unmaintained.Faad2 library is already patched in Gentoo since faad2-2.0-r7.Another exemple with Ubuntu :faad2 (2.0.0+cvs20040908+mp4v2+bmp-0ubuntu1) breezy : 09_amd64.diff patch (from Gentoo patch)But xine-lib isn’t patched : no trace of amd64 patch on changelogs, so the AAC support is broken…I think to use an external in Xine will be beneficial for AAC files support in most distributions, which use already fixed Faad2 library for AMD64.What do you think about that ?(I hope you understand my poor English)
Oops, I forgot to tell you that you can also use the