[Flac-dev] FLAC support for Android?

[Conrad Parker]

2009/2/26 Dave Chapman <dave at dchapman.com>:
> 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
> consideration.
>
> 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.

That's fair enough: people should be able to make their own implementations.

Ensuring compatability between different implementations is a lot of work
and can be painful for everyone involved, but it has to be done.

First step: does anyone have some example files that should work but perhaps
don't work in FFmpeg/Rockbox, that could be added to their test suites?

Conrad.