[flac-dev] Higher compression modes from Flake

[Declan Kelly]

On Thu, Mar 14, 2013 at 08:12:14PM +0100, mvanb1 at gmail.com wrote:

> No. If you want such things, try TAK, OptimFROG, Monkey's Audio or even 
> LA, you'll lose hardware compatibility anyway and they do much better 
> than FLAC will with a -9 option.

No. I want the tightest possible compression, while remaining 100%
compatible with the subset that all known FLAC decoders can successfully
stream or play now in cars, Hi-Fi units, "MP3 players" and cell phones.
The out and out most widely supported lossless audio format could (and
should) have a better "bang for the buck" to the average user (who has
possibly been tempted away from MP3 or WMV or some Apple format).

I buy a lot of music on Bandcamp (and similar sites) and usually get
smaller files (for long term storage) when recompressing (flac -8).
A common sentiment I have seen online is "my CPU time is too valuable to
bother with maximum compression", but that ignores the fact that all of
the copies made of those files are going to add up to something bigger. 

A recent Google-developed algorithm called Zopfli is taking a similar
approach with the old Deflate method (first used in PKZip, still used
today in PNG, gzip, zlib, etc).
100% compatible with every web browser that can already decode the data.
Not a new format, just the best that gzip/zlib can be.

There is a huge increase in CPU requirement for compression, but that
only has to be done once for each source file.

http://googledevelopers.blogspot.ie/2013/02/compress-data-more-densely-with-zopfli.html

"Zopfli is best suited for applications where data is compressed once
and sent over a network many times, for example, static content for the
web."

The compressed output is "only" 3-8% smaller than the best that zlib can
do, but that adds up in a lot of scenarios. If I had a Web server full
of hosted sites, each with at least one copy of jquery-1.9.1.min.js.gz
(or some other common static component) or a very busy PNG-heavy site,
every byte saved is going to save my disk and bandwidth costs, with no
penalty for the Web audience viewing the websites (and compatibility
with every 21st century browser).

It's almost useless for on-the-fly compression, but asymmetrical codecs
often are unsuited to that anyway, even at lower compression levels.


> FLAC 1.0 had a -9 option and it was 
> removed with a good reason: almost no gain with added decoding complexity.

Thanks; I didn't know that.

-- 
-Dec.
---
   (no microsoft products were used to create this message)