https://bugzilla.gnome.org/show_bug.cgi?id=614783

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.

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.

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.

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).

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.

So…

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.