FLAC actually doesn't compress this file any better than gzip:

$ flac -f -8 third_party/WebKit/Source/platform/audio/resources/Composite.wav
Composite.wav: wrote 147717 bytes, ratio=0.601

The composite file contains the impulse responses for the HRTF panner.  hongchan@ had a CL to cut that in half because the left and right channels are exactly identical.  However, the CL wasn't finished because it wasn't producing the same results as before, and we didn't consider it critical.  Perhaps we should re-evaluate this soon.

Compressing it is ok, but decompression isn't free and it will delay the initialization of the HRTF panner mode, which is noticeably slow on desktop and even slower on Android devices that tend to be less powerful.

Sounds great, I'd certainly like to see it cut in half by removing the unnecessary data, in addition to the compression.  It sounds like both those approaches combined would lead to 70% savings (making it ~70Kb).  That seems worth doing -- it's hard to find APK size savings of this magnitude.

> Compressing it is ok, but decompression isn't free and it will delay the initialization of the HRTF panner mode, which is noticeably slow on desktop and even slower on Android devices that tend to be less powerful.

Well, one way of looking at that is that if it's already slow, then you have no performance guarantees and the decompression cost may be relatively negligible.  Our users probably shouldn't be paying disk space+update bandwidth just for a slow feature to still be slow anyways.

Well, no.  That's like saying Chrome is slow to start up, so it's ok to make it even slower.  No one would allow you to do that.  We want to make it faster, not slower.  The slowness has audible effects (and also used to have visible effects).

> That's like saying Chrome is slow to start up, so it's ok to make it even slower. 

Correct, if for example it takes 200ms to start up and we are considering introducing a 5ms regression to improve another metric like RAM.

This kind of tradeoff question comes up a lot with System Health team (I had an extended discussion along these lines when launching GPU raster) and lately the philosophy has been to list and measure key user stories: https://docs.google.com/presentation/d/1Ewk8U4Ct7yXxtfeGMDZVAbltzSaMKUoawqrqoABI8Eg/edit#slide=id.p .  The discussion can be especially fraught when impact on a niche user story like WebAudio webapp usage needs to be traded off against a key user story like Chrome install/update.  (But my point is that it's not obvious the harm to WebAudio would be nonnegligible in this case, anyway.)

Anyway, purely philosophical debates like this don't usually finish with consensus, so we can let the disagreement stand for now and revisit with data in hand when FLAC compression is actually available.  In the meantime, please go ahead and remove the half-redundant data; assigning to hongchan@ for that part.