[Flac-dev] FLAC support for Android?

Dave Chapman dave at dchapman.com
Wed Feb 25 08:25:51 PST 2009

Cristian Adam wrote:
> On Wed, Feb 25, 2009 at 2:23 PM, Brian Willoughby <brianw at sounds.wa.com>wrote:
>> A better suggestion might be to start with libFLAC, optimize as
>> needed, and then submit the optimizations back to the FLAC project
>> where they will be more widely useful.
>> But that's just my opinion.
> I agree. This way the DirectShow filter for Windows Mobile (based on
> libFLAC) will
> also benefit from those optimizations.

When Rockbox switched from libFLAC to the ffmpeg decoder, FLAC turned 
from one of our slowest codecs, to the fastest.  The difference was 
extremely dramatic.

libFLAC is the _reference_ implementation of FLAC, not one that is 
designed to be the ideal decoder everywhere.  That's the advantage of 
open codecs - the specification is public, and third-party 
encoders/decoders should be encouraged, not immediately rejected without 

I'm not talking about things that can be achieved by optimising libFLAC. 
  One of the reasons the Rockbox version of the ffmpeg decoder is so 
fast on our target devices is because it is very tightly integrated (no 
abstract layers of API).  i.e. we created a FLAC codec designed 
specifically for the Rockbox codec API.

This involved extracting the FLAC decoder from ffmpeg, using the core 
decoding parts of that code, and writing new code just for Rockbox. 
Whilst this was a lot more work to do than simply linking libFLAC, the 
end result was very worthwhile.



More information about the Flac-dev mailing list