On Thu, Mar 14, 2013 at 08:12:14PM +0100, mva...@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) _______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev