GNOME Bugzilla – Bug 614783
iTunes fails to handle flac correctly under DAAP
Last modified: 2018-05-20 06:15:39 UTC
I am able to convince iTunes (Mac only) to play FLAC's/oggs locally. Two components have to be added into separate system folders. You can read more about that here: http://www.soundunreason.com/InkWell/?p=928 However, when iTunes connects to a DAAP share from my Ubuntu/Rhythmbox machine, flacs or oggs are seen but misunderstood. The playback solution from my disorganized post above gives QuickTime the ability to play FLAC's and oggs. The problem is that iTunes won't use QT for FLAC/ogg playback unless you add some metadata to the resource fork for an individual file. That's not going to happen over DAAP. There is a possible solution to this dilemma involving some additional slight of hand. If the DAAP share were to lie to iTunes about which MIME type it was sending (masking FLAC's and oggs as QT movie files for instance), the aforementioned solution should allow playback of FLAC's and oggs across DAAP through iTunes. I understand there is already a functional DAAP plugin for Rhythmbox. It just needs to lie to iTunes so that when folks using Macs visit we Ubunutu cats they can connect to the DAAP share too. As such, this additional functionality may be best added as a switchable option (check here for Mac FLAC Compatibility Mode or some such). This is a positive inroad for Ubuntu and FLAC/ogg usage. To this point, this is probably more likely to apply pressure to Apple than anything else (it would encourage a consumer demand for FLAC/ogg within their own user base--ie those people who give them money). I'm happy to answer any questions.
Have you actually verified that your proposed solution works? If so, how? You seem to have gone into this in a fair amount of detail in the comments you linked to, but I'm not seeing anything that points to this as a definite solution. I recall messing around with this a few years ago and coming to the conclusion that itunes pays no attention to what we tell it. If you haven't tested this at all, well, I'm not going to do that for you - I don't run itunes anywhere, and I'm not about to start - but I can show you roughly what a patch for this would look like.
Thanks for taking an interest in my feature request. I am basing my assessment that this will work on a suggestion from one of the developers (arkadini) at xiph with whom I chatted (IRC) about this exact issue: "[arkadini:] the problem is the only way to make iTunes paly non-itunes supported files through daap seems to be for the server to send different mime types if the client is iTunes" There is also some evidence to suggest this will work from iTunes itself. A flac from a local (OggS touched) flac file will display as “Kind: QuickTime movie file” (which plays thanks to the two QT additions mentioned in my blog post) in the Get Info dialog in iTunes. However, a flac through the DAAP connection will show as “Kind: MPEG audio file (remote)” which is not handled in the same fashion. The idea it seems would be to convince iTunes the DAAP was sharing “Kind: QuickTime movie file”. My thought would be to claim the MIME type was that of a .mov file. As you can see my research as been fairly thorough, but I am still sorry not to be able to provide more. Since you are a well-versed developer, you could likely have a more in-depth conversation with arkadini about this matter is in my power. I would be happy to test any patch, but short of receiving a patch I'm not sure how I might test it here. I do happen to have a Mac with (of course) iTunes (and several Rhythmbox installations for DAAP sharing), so I have the testing environment necessary.
That should read: Since you are a well-versed developer, you could likely have a more in-depth conversation with arkadini about this matter THAN is in my power.
Created attachment 158045 [details] [review] experimental patch This might work.
Oh, excellent. If you can point me to instructions for compiling this into a working plugin I can test this immediately. I have used make perhaps once, so not I'm totally ignorant but far from expert. I guess I will use git to get the code? Or do I save the .diff file from below?
These steps should work, assuming you have saved the patch as 'file.diff': $ sudo apt-get --no-install-recommends build-dep rhythmbox $ git clone git://git.gnome.org/rhythmbox $ cd rhythmbox $ patch -p1 < file.diff $ ./autogen.sh --enable-uninstalled-build $ make then, to run it: $ cd shell $ ./rhythmbox
Thanks. I understand all of this except the beginning directory. Do I start in ~/ and this process creates a folder called /home/[username]/rhythmbox into which I cd, or do I begin in a different location?
The 'git clone' command will create a rhythmbox subdirectory in the current directory. It doesn't matter where you start. Your home directory is as good a place as any.
It went well until make: $ make make: *** No targets specified and no makefile found. Stop. I did notice a file called Makefile.am in the rhythmbox folder created by git. Do I need to specify that or maybe something else?
If autogen.sh ran successfully, it would have created makefiles in each directory in the source tree.
Ok, got that all sorted out. There was a character it didn't like in the path (ugh). So I compiled and tested the patch/plugin/Rb build. Though the type changed in the Info dialog (Kind: QuickTime movie file) the file still refuses playback. http://www.soundunreason.com/InkWell/?p=928#comment-4074 I hopped onto the xiph IRC channel but it's late Saturday, so I'll try there again early in the week. Let me know if I can otherwise be useful or if you have another idea I can test.
Reassigning this to libdmapsharing, since that's where any fix for this would go now.
Xiph does not seem to distribute a 64-bit version of its QuickTime plugin set. Until this changes, I'm afraid any work on this would not help "modern" systems much.
The Xiph components mentioned in my above linked blog post are currently functioning on a 10.5.8 Macbook. What do you mean when you say "this would not help 'modern' systems"?
(In reply to comment #14) > The Xiph components mentioned in my above linked blog post are currently > functioning on a 10.5.8 Macbook. What do you mean when you say "this would not > help 'modern' systems"? Snow Leopard, 10.6. I don't have any other Mac OS X computer to test with. Although I am interested in seeing this work, I can't really justify spending time on it or inserting a hack into libdmapsharing unless someone releases 64-bit plugins. As another option, libdmapsharing does support real-time transcoding to MP3 or WAV (e.g., FLAC to MP3). So, it would be possible to add this ability to the Rhythmbox DAAP plugin. This would be the cleaner solution, I think. It would require a mimetype selector (or transcode checkbox) in the DAAP plugin configuration GUI. Rythmbox would then pass the selected mimetype as the fifth argument to daap_share_new in rb-daap-sharing.c. Just a note about the two supported formats. MP3 is problematic due to intellectual property issues, of course. Because of this, we can't assume all Rhythmbox installations support it (the GStreamer LAME plugin is required in order to transcode to MP3). On the other hand WAV can be very hard on available bandwidth. Unfortunately, iTunes does not directly support any format that does not have some combination of these negative properties.
Michael - Thanks. I have a 10.4 and a 10.5 and they are both "64 bit ready" (thanks, Apple). I have confirmed that there is no current 64 bit Xiph component. I found talk of such on their forums and hopefully they will get that together before long. I am not necessarily opposed to the idea of transcoding though I would encourage two items there related. First, transcoding should be dependent upon the streamed-to client being iTunes. This is so that the transcoding option could be enabled and only those actually requiring transcoding would receive it. Second, the transcoding format should be user selectable. My local network can handle the bandwidth requirements for streaming WAV files. Others may be content with the quality loss of streaming as MP3. As such the plugin should have, perhaps, a drop-down selector or radio button for choosing which transcoding is to be used.
The Xiph QuickTIme FAQ now addresses 64-bit Mac OS X a bit more: http://www.xiph.org/quicktime/faq.html Perhaps that will help. I do not have a Macintosh at the moment to test with.
Closing the bug for migration, as it makes it break.