Peter McQuillan has again outdone himself by providing a set of patches for Android that provides native decoding of WavPack files. The support even includes handling correction files (which I believe is the first time on a portable device)! It uses the 4.60.1 version of the WavPack library without source code modification.

Of course, this has not been accepted by the Android folks yet. It would obviously be a great coup for WavPack to be in Android and anyone interested in helping this along should “star” the issue request on the Google Android site (you don’t have to add a comment unless you want to):

One thing I'd just like to add to this Android is no longer just on phones, we're starting to see portable media players (like the Archos 5) being released with Android as their operating system. At CES this year manufacturers were also showing Android running on set top boxes.As Android becomes pervasive, it would be great to think that WavPack support would be included as standard - so please add your "star"

Android is no longer just on phones, we're starting to see portable media players (like the Archos 5) being released with Android as their operating system. At CES this year manufacturers were also showing Android running on set top boxes.As Android becomes pervasive, it would be great to think that WavPack support would be included as standard - so please add your "star"

I am noticing this trend as well. I am wondering if this has a lot to do with the SDK or just the general nature of the embedded O/S. The easier is to get up and running to write apps and other utilities for it the more people will start to take a liking to it.

I'm more than a little frustrated by Google's position that Android is a fork of Linux, rather than working on having their modifications accepted into the mainline kernel. But that's largely irrelevant here.

Google does not have that position. Their code was dropped from mainline by a maintainer not working for Google. He criticized a lack of effort from Google's side to get it accepted, as you write. The other side of the story is, that there may also be a lack of willingness to accept very reasonable changes on the side of the kernel maintainers. Google employs the best programmers of the world, they are not known for trying to force half-baked, vendor-centric changes into OSS projects. They are also not known as forkers, but rank along the biggest contributors to OSS worldwide.

Lets see what happens. If the future shows that one side still can profit from the other, changes will merge again. This is all pretty low level, anyway. Higher level interfaces and APIs are not affected by this, just specific types of drivers.

We only disagree in the meaning of "Google's position". I stated their de facto position. Really, dropping a load of changes however long after the initial branch is simply not the way open source is done anywhere, and if the patch was from anyone but Google it would be dropped without a second thought. You stated their "official" position. There is an incongruity between the two positions at the moment. I'm hoping for a resolution between Google and Linux, but all the hope in the world won't necessarily make it happen.

I am noticing this trend as well. I am wondering if this has a lot to do with the SDK or just the general nature of the embedded O/S. The easier is to get up and running to write apps and other utilities for it the more people will start to take a liking to it.

Well, its a free OS that is currently being developed/improved that works on ARM chips (which a large amount of consumer electronics devices use). Its also (apparently) relatively straightforward to get working on a new hardware platform. From a manufacturers perspective this can mean reduced software development costs as well as reduced license costs.I can't speak about the complexity of writing apps for Android, but once I figured out how to get the proper development environment setup adding WavPack support wasn't too complicated

Now that the code to add WavPack is available, I'm hoping that any manufacturer that releases a product using Android also adds WavPack support as well! Though it would be much easier if WavPack support was added by default in the Android code - so please add your star!

Now that the code to add WavPack is available, I'm hoping that any manufacturer that releases a product using Android also adds WavPack support as well! Though it would be much easier if WavPack support was added by default in the Android code - so please add your star!

Ohh I definitely will support it except I don't have an Android device! I am already greatful for being able to use WavPack on my Cowon o2 though I was seriously considering using hybrid mode in the future if I start to run low on space!

Until Google decide to add native support (and please add your star if you haven't already) I thought people might be interested in trying this music player on their android phones. Its been available for a few months, but it required you to have 'root' access on your phone. However a few weeks the author managed to get the application working on non-rooted phones as well.I tried it on a Nexus One and it works well. Its quite basic in terms of functionality (no seeking for example), but it does play WavPack files It apparently also does FLAC, APE and Musepack so something there for everyone

Soiaf, does that program not support seeking in general, or does it just not support seeking with WavPack?

No, the program itself doesn't currently seem to support seeking (or at least it doesn't for MP3 and FLAC also). Its a small annoyance, but otherwise the program is quite good, it does what it says it does

FLAC support is rumored to be planned for the next Android release after 2.2, namely Gingerbread.

That doesn't suprise me. Xiph.org supports Google with the WebM-format (Vorbis as audio codec). It sounds very fair to me if Google shows some respect back and build in support for Xiph's lossless codec.

It wouldn't even suprise me if Google takes over Xiph in a few years.

With WebM (VP8 + Matroska + Vorbis) and a great lossless format (FLAC) Google has a very competitive codecpackage.

FLAC support is rumored to be planned for the next Android release after 2.2, namely Gingerbread.

There are clues as to what they may be thinking in the comments section at the bottom of this page. I am not sure exactly how to interpret it, but I am certainly hoping that there would be room for both FLAC and WavPack support in Android, especially since WavPack's hybrid mode makes more sense on a portable than pure lossless.

Peter has been kind enough to update the WavPack patches for Android 2.2 (thanks, Peter!) and there is still no word from Google on what they are planning to do in this area (so there is still hope this could go in).

In any event, we are up to 96 "stars" on the feature request, so if you would be interested in this and haven't done so, please give it a star and maybe we can get to 100!

I have added a star and comment, I use WavPack as my primary lossless audio codec. Thanks for all your work on it!

I have mostly been using it recently alongside x264 video in MKV container, it beats 'zlib' compression on the wave audio (which is a built in option when generating an MKV), and WavPack seems to be supported properly in MKV anyway.

I know FLAC has more support from being around longer, and because of the 'OGGFLAC' thing, and good luck to that format as well, but WAVPack in my experience of using it always performs better.

I was interested in that FLAKE project which was a more efficient encoder, and then someone made a faster CUDA encoder (uses GPU for processing) called FLACUDA. I wonder if something like that would happen for WavPack?