If you have been following my adventures, you know that I have ripped my entire CD collection (some 14,000 songs) to flac files and have those stored on an Ubuntu machine. (Read the starting article here.)
I have thus far been able to use my collection through a file-share on another machine. Both the serving machine and the receiving machine are running Ubuntu. That is working great but the road does not end there.
Rhythmbox is capable of sharing music in much the same manner as iTunes does using what is known as DAAP (Digital Audio Access Protocol).
Now, iTunes does not natively support the playback of flac files. Apple has their own lossless codec which they would like us all to use. But this is not time to commit yourself to forever being an Apple consumer. Keep your options open.
So, in my case the question arrives: How do I play my collection on my Mac (10.4.11) using what’s available there? I know that VLC, though clunky, will play flac files; it does not currently properly support DAAP. By contrast iTunes (pretty as it is) will connect to DAAP but as mentioned is unable to play flac files natively.
I have mentioned before this article which offers instructions for enabling flac playback in iTunes on the Mac.
The article was aimed at someone with files local to their Mac wanting to playback those flac files using iTunes. This procedure rests upon a component for QuickTime called the Xiph QuickTime Component (xiph-qt-0.1.8.dmg). QuickTime is relied upon by iTunes for playback. So, giving QT the ability to play flac files ought to be the end of the matter.
With Xiph and the Flac.Importer installed (in the QT Components folder) I am able to play a local flac file using QT. I have confirmed that each of these is required by QT for flac playback (you will encounter a different error if either of these components is not in place).
Sadly, after adding these components and connecting to the Rhythmbox share iTunes sees but will not play my flac files. Instead, when a flac file is selected for playback iTunes sits idly while claiming to be in playback mode (though the time does not change nor does the progress bar move across the song).
The one item which was not followed was running all the flac files through the OggS application. The article implies this is an optional step. The OggS application registers certain metadata with the operating system. According to this article this is necessary only in order for iTunes to successfully import the flac files into your collection, but iTunes will ignore any attempt to attach to a flac file which has not been so registered.
I wish not to do this for these three reasons:
- This creates an extra step I have to take on every subsequent flac I rip
- The flac files are to be considered complete when they are ripped not after they have been iTunicized
- The files are stored across the network and they are more than 14,000 in number—way too much time and bandwidth spent for a rather superfluous matter
I am still seeking the answer and am creating this post as an informational repository at which I can point folks who may be able to contribute to the solution. I will continue to add information as I find it. Please feel free to help out in the comments.
Special Note for those Running 64 bit Macs (Lion, for instance):
You can run iTunes in 32 bit mode to make the above work (until a 64 bit version of the tools becomes available). To do so go into your Applications folder, right-click on iTunes and choose Get Info. On that dialog you will find a check box to “Open in 32-bit mode“. Check it.
I haven’t tested this but I am assuming it will allow the above procedures to work.
19 thoughts on “The Mac .flac iTunes Blues”
I tried associating the .flac files with QT and with iTunes directly (was VLC) but this didn’t help anything.
I am only able to associate .flac files which have passed through OggS with either of these applications. Any .flac file which has not been registered through OggS will not allow file associations of this sort, nor will it play within iTunes.
It comes down to a setting in the metadata for kMDItemFSTypeCode. By default the code for a .flac file will be 0 but OggS sets the type to 1332176723. In theory, if I could ask the operating system to always assume a type 1332176723 for anything with extension .flac I would be in business.
You can find this information by running a command on any particular file you like:
So yours might look like this:
We shall see.
There is a reason why it is necessary to change the kMDItemFSTypeCode in order for the fila associations to work. Spotlight restricts what file types are allowed to do based on kMD (metadata) information.
It looks as though if we were able to create an mdimport file capable of telling Spotlight (and therefore the kernel) how to manage .flac files (ie: default kMDItemFSTypeCode to 1332176723) then we would be all set.
So now the question becomes is this possible and how?
I posted a response (I think) in your thread on ehmac.ca.
Yep. I added more details. Thanks for your interest.
Several folks have pointed me toward Fluke.
I am familiar with Fluke. It is a package which contains the three elements I mention in my post (the Xiph QuickTime Component, the FLACImporter, and the OggS application). It is a convenient way to add all of those.
It, of course, has the same problem. In order to play a flac in iTunes I have to touch that file (either with Fluke or with OggS directly). This touch tells Spotlight to set the metadata called kMDItemFSTypeCode for that particular file as 1332176723 in Spotlight’s datastore.
It’s an innefficient pain (efficient pain is better?) to do this on a non-local (network) collection consisting of 14,000+ files. (Regardless, this doesn’t help the use of DAAP at all.)
I am thinking that if I can tell Spotlight to assume this type code for any instance of *.flac then this will take care of the matter.
Another possible solution to the DAAP issue is to create a Rhythmbox plugin which in effect lies to iTunes telling it that the flac files are ogg files.
In specific, a flac from a local (OggS touched) flac file will display as “Kind: QuickTime movie file” (which plays thanks to the two QT additions in the post above) 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.
Support my idea for a better DAAP solution for Ubuntu:
I am mostly positive it won’t work to run one of the non-local files through OggS and then try to access that file through the DAAP connection.
The OggS step stores information about a file, either in the Spotlight data store or in the resource fork of the file system, and there is no associated filepath for any file coming through DAAP. Further if it turns out that the metadata is stored in the resource fork then other file systems (outside of HSF and HSF Plus) won’t have a resource fork (are not multi-forking file systems).
Either way, it seems that the path to success on the Mac (if one should exist) lies in manipulating the system of assumptions made when a flac file is encountered.
If I run the command mdls on a file called Song.flac (sans OggS) I get a list of kMDItems returned. One of those is kMDItemFSTypeCode = 0 and another is kMDItemKind = “FLAC Audio File”. If I change that filename to Song.jpg I get kMDItemFSTypeCode = 0 (should be 27747840 for a jpg) and kMDItemKind = “JPEG Image”. If I, even then, run that file through Set OggS it changes the TypeCode to 1332176723.
If I make the same tests using a file called Image.jpg (an actual image file) the TypeCode starts as 27747840 (of course), Set changes it to 1332176723, and Clear changes it to 0 (because it’s really the same as Set except its target output is zero–this happens to not break the jpg).
This suggests that Spotlight gathers current metadata from the file (perhaps from the ID3 tag information) and fills in those kMDItems. It either finds a value it knows and marks it as 0 or it finds a value it doesn’t have instructions for (more likely) and inserts a null value as a fallback. It would seem then that the thing to do is to give Spotlight a set of proper instructions for handling flac as it relates to this particular kMDItem.
What I am aiming at (though it’s possible it’s a mirage) is getting Spotlight to assume the TypeCode is 1332176723 when it encounters a flac file.
I’m having an almost identical problem to you and haven’t found a solution. I’ve read what you said and am curious as to know whether or not you have made any progress or determined another work around solution?
Unfortunately not. I am still seeking a developer who has a different opinion (and the time to hack at it); but as of yet all of the developers I have talked with say it can’t be done (though they are a little soft on why it can’t be done).
If you are a current Mac user, I would encourage you to call Apple’s customer support and inquire about FLAC playback and encoding on your Mac. They will tell you it can’t be done but I think this will help influence Apple to include FLAC support in the future (the consumer holds the purse strings).
Hello, James. Yep, I sympathize a lot with your problems. Believe it or not, I have a much larger library to deal with, most of it in .FLAC and/or .APE; I don’t use a remote server, however (I use a monster Drobo disk server instead), so the files always look local to me.
Have you tried Vox? It’s a simple, no-frills player, but it’s stable and neat. The developer is a super-nice individual, uber-responsive and greatly involved with his creation; even if Vox doesn’t support DAAP (I don’t know that it does or doesn’t), you could try contacting him at the URL above. Perhaps he can add that feature to Vox’s roadmap…
Good luck, I hope we live to see the solution to this one of many Steve Jobs proprietary/BigBrother games.
I believe it. I have known DJ’s with amazing clutter. I was so excited to get all the discs into crates and out of the living room.
It bothers me less that ALAC is proprietary and more that I cannot buy music as ALAC–and I can buy music as FLAC but Apple ignores them. (As does Microsoft.) Remember APE is proprietary just less restrictive.
I’ll have another look at Vox. Seems I did once but don’t remember it. I just downloaded PLAY but need to replace a hard drive in my music server so haven’t done any testing yet.
I filed a bug (feature request) with Gnome/Rhythmbox to see if we couldn’t put together a DAAP share that would feed into iTunes such that iTunes would be able to playback the FLAC files:
A developer there (J Matthew) put together a patch which I tested. The patch did change the type iTunes displays in the Info dialog (Kind: QuickTime movie file); however, the same behavior persists on the client end—namely no playback.
I am continuing to investigate.
I found your site usefull.
Great news. Thanks for reading.
For Mac users seeking FLAC and library support (or Windows user or Linux users) there is now another great contender on the scene. Check out my article on Clementine:
Oh, My Darling! Musica!