Archive for the 'XiphQT' Category

FLAC support in Mac OS X 10.5 “Leopard”

October 28th, 2007

The rumour about FLAC support in Leopard started appearing more than one year ago. As rumours go, that one was pretty vague - nonetheless some people managed to infer that iTunes would support it as well, naturally. I must admit that at some point, due to a certain person that shall remain unnamed, I got quite confused myself.

On Friday Leopard has been released. Yesterday I’ve spoken on IRC about the FLAC support with some users that already have 10.5. Then I played with the developer kit for Mac OS X 10.5, now available to everybody. And I have my answer.

Xcode 3.0 developer kit contains some new examples in /Developer/Examples/CoreAudio. One of them is an example implementation of AudioCodec compressor and decompressor for FLAC streams (as in “streams of logically related bits” not “network streams”). To build that codec you would need to, following included README, download FLAC source distribution, copy some of the source files into a subdirectory in the example AudioCodec implementation, edit one of the copied files and build the whole thing in Xcode. After it builds the resulting bundle needs to be copied into /Library/Components. From the README: “You now have a working FLAC encoder and decoder on the system.”

Right. What you still don’t have is any way to extract those FLAC-formatted bit streams from the files FLAC usually comes in, like .flac or occasionally .ogg files, to be able to use your new and shiny codec to decode them. You still don’t have a way to put those FLAC-formatted bit streams into a .flac or .ogg file. Possibly 10.5 comes with some tools, or some more D.I.Y. examples, to manipulate CoreAudio Files (.caf) or maybe even QuickTime (.mov) files, so you can store and extract those FLAC-formatted bit streams in/from those Apple-specific file formats. But still, neither QuickTime Player nor iTunes won’t be able to play .flac files even if you build and install the example codec.

And that’s it. That’s the FLAC “support” in Leopard, as far as I know. Expected more? Sorry, move along.

If you are a XiphQT user you had the same “support” for FLAC decoding more than a year ago, when version 0.1.5 had been released. Except it included support for FLAC in .ogg files. I know, to many people that’s next to useless, but still. And XiphQT’s code for decoding FLAC is roughly half the size of the Apple’s example and doesn’t have loops copying data between interfaces sample by sample! Even a simple thing like multi-channel mappings is incorrect in their implementation - they either didn’t bother to read the FLAC specification or didn’t bother to implement it properly, because it’s hard to believe they don’t know how to use their own API. Nice “example” Apple!

At this point there’s only one more thing left to write. Expect native FLAC file format support in XiphQT soon.

XiphQT 0.1.8, as promised

September 2nd, 2007

OK, XiphQT 0.1.8 is now out.

The previous, 0.1.7, version was quite stable except for one crash/freeze-causing issue that was discovered soon after the release, was fixed soon after the discovery, then spent another 5 months or so in the repository. Those selected few who bothered reading my comments on the trac, of those few who actually went to the trac to file a ticket on that bug, could find out there was a binary dev snapshot with a fix, available as soon as the source code was fixed. But it seems most of the users couldn’t find it. Now that it’s been released that’s taken care of.

One very warm and fuzzy thing about 0.1.8 is the resolution of the video stalling issue. So, no more attempts to find a Linux box (or tempting thoughts of replacing the current OS with a Linux on my “Macintosh HD”) every time I come across an Ogg/Theora URL!

Late summer XiphQT news

August 26th, 2007

OK now, who said XiphQT is dead?

I should make one thing clear: I don’t really like QuickTime. I have a kind of love-hate relationship with XiphQT, like in “love Xiph, hate QT”. After periods of development activity I get to the point where my stomach hurts more often than it should and the percentage of aggressive and explicit sentences spoken aloud be me rises way above the acceptable level. So then I stop and sometimes it takes longer than shorter to be able and want to work on XiphQT again.

Anyway, it seems today I managed to reduce the video stalling issue in the importer code almost completely - initial and more sophisticated approach didn’t work but the one borrowed from Perian did.

Other news is that Ivo Emanuel Gonçalves made a Windows installer for XiphQT - many thanks Ivo! Now, if only somebody could update the Windows port too, because it’s still at 0.1.5, that would be just awesome!

Also, there’s been quite a number of trac tickets about why the official project page doesn’t say anything about the most recent development snapshot, which fixes quite an annoying iTunes crash issue. Words like “silly” also appeared in some e-mails I got on that subject. And I totally agree. And intend to fix it.

That may actually mean a release. And because I’ll be going to Poland the first weekend of September - that may actually mean a release quite soon. Yay!

Ogg Vorbis handling regression fixed

March 28th, 2007

Recent changes in the Ogg importer component brought some regression - some Ogg Vorbis files may cause QuickTime (iTunes, etc.) to freeze or crash (ticket #1154, #1155).

The problem should now be fixed in the SVN (r12814) and a new binary snapshot containing the fix is available. Recommended to all XiphQT users.

Xiph QuickTime Components 0.1.7

March 23rd, 2007

A new XiphQT release is finally out!

The version number is 0.1.7 and while it has the property of being strictly greater than the previous version number, which was 0.1.5, it doesn’t really reflect the state of the project. I should probably annotate the version number with something like “pronounce: oh-seven-one” ;) No worries, other Xiph projects seem to have problems with version numbering, too. And I’ll just number the next release, which should be ready in much less than 11 months, with 0.8, or maybe even higher, we’ll see…

The release notes highlight the changes quite nicely. And I’ve already received some feedback on improved performance, something I wasn’t sure would be really noticeable. Overall, seems to be quite a reasonable release, definitely worth upgrading - get it if you haven’t done that yet.

Xiph, QuickTime Components and Summer of Code 2007

March 17th, 2007

Once again, Xiph.Org has been accepted for Google Summer of Code! And amongst Xiph project ideas for this year XiphQT also has its place. So, if you ever wanted something in XiphQT fixed or wished a new feature was added but never had quite enough arguments to convince yourself it’s worth actually trying and doing it yourself - maybe now is the time?

Of course, XiphQT is only a small part of Xiph.Org. If you’d prefer to hack on a more general and open audio and media stuff, there aren’t many limits, neither. Last year, besides the directly project-related ideas proposed by Xiph developers, we saw a number of original and interesting submissions ranging from nearly pure hardware to fairly sophisticated algorithms, with FCPGAs, assembler, libraries and applications in between, all one way or another related to audio and media. And participating in the event was quite an experience, too!

All that is, basically, to say: whether you would like to add Ogg Skeleton, OggPCM or CMML support to XiphQT, apply FLAC to compression of power system analysis (ATP) data, work on a next generation audio codec or do something completely original (preferably it having relations to audio, open media or Xiph technologies) - come see us on irc (, #xiph) and consider applying. There’s still enough time (until March 24th) to prepare at least one quality application!

Exporting Oggs from QuickTime

November 12th, 2006

Committed the code for the new OggExport and CAVorbisEncoder components. You can find in the Xiph.Org’s SVN repository.

The new bits are alpha software, thus hard hat equipped testers are welcome!

At the moment the exporter will produce Ogg Vorbis files, with quality fixed at 0.4 (~128kbit/s) ignoring any user-set options. But at least in QuickTime Pro and iMovie it seems to work.

More features should follow soon…

Brand New Ogg

November 7th, 2006

I have just produced the first Ogg file using XiphQT’s new code. The file’s about 680K (source audio was about 50 seconds long) and, with exception of the missing e_o_s flag on the last ogg_page, it’s a perfectly valid Ogg Vorbis file.

There are actually two new components involved: VorbisEncoder (CoreAudio) compressing the audio data and OggExporter (QuickTime) muxing ogg pages and writing the physical bitstream to disk. It shouldn’t take too long now to add FLAC and Speex encoding components, but that’s after Theora compressor is ready.

The new code still needs some more work and tidying up before I can commit it, but it should reach the SVN this week.

Native FLAC in iTunes/QuickTime

October 12th, 2006

I feel a bit guilty about not publishing this before. But, you know, it was kind-of working, I had some time so I thought I’d re-write it in a way similar to OggImporter. Then I stopped having time. Thus, I accept those e-mails asking about native FLAC support as a deserved punishment.

The FLACImporter.component I’m writing about is actually a slightly modified importer component from Damien Drix’s QuickTime FLAC Plugin. Basically I removed the decoder part (which stopped working properly in QuickTime 7), changed codec IDs to match those found in XiphQT and made a Universal build. As it is, it parses and imports native FLAC files and then the decoding part is done by CAFLAC component, part of XiphQT.

You can find the binary files and source patch here. But read on, because it’s not all that rosy…

The component used to work when I first played with it, and it still does - in QuickTime Player (and a number of other QuickTime-based apps) that is. It doesn’t have all the functionality of the OggImporter, and performance could be better, too. But it works, it plays the FLAC files.

But… you guessed it right: iTunes. iTunes is something else. On my machine iTunes plays native FLAC files fine, yes, but they need to be in iTunes Library already. That is - it won’t (easily) accept new files with the .flac extension.

During my tests I discovered, however, that iTunes will accept .flac files if you set their FSTypeCode to something popular and openable with QuickTime, like ‘MooV’ (original FSType of .mov QuickTime Movie files) or… ‘OggS’! Which is the FSType used by OggImporter component to denote .ogg files. And that’s quite an intriguing discovery, since both components use nearly perfectly identical steps to register with the OS! How come?! To test, I created a copy of OggImporter that only uses different FSType and file extensions - and it doesn’t work. So, how’s that? Does iTunes have the ‘.ogg’ and ‘OggS’ hardcoded somewhere? Is my machine’s OS going slightly crazy? Am I missing something? I’ll try to investigate that…

But for now, the summary. The FLACImporter should work in QuickTime (you’ll need the XiphQT package, as well). It should work in iTunes, but there may be problems with adding .flac files to your library. If you can’t add them, and don’t mind a bit of cheating, you can set the FSType of you FLAC files to ‘OggS’ (or ‘MooV’, but ‘OggS’ should work). You can set it with SetFile tool from the developer packages (/Developer/Tools/SetFile). On the FLACImporter page you can also find a simple python script I wrote that should work on a machine without dev packages installed. Setting slightly-not-true FSType should be harmless and is reversible (set FSType to 0). In case I/someone finds a better solution…

Note on the Intel part of the binary: it’s untested. Let me know if doesn’t work. No Win32 binaries either, since I don’t have a machine to compile it at the moment.

So, is it working for you? How about the strange iTunes behaviour - anybody able to shed some light on the puzzle?