On 14-03-13 20:02, Declan Kelly wrote:> The next official release of the FLAC command line should really have > a "-9" option for absolute maxed-out big-memory CPU-burning compression.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. FLAC 1.0 had a -9 option and it was removed with a good reason: almost no gain with added decoding complexity.
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)
On 14-03-13 21:24, Declan Kelly wrote:> 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).If you take a look at the comparison on the FLAC website you'll see that the gain going from -5 (the default setting) to -8 will save you about 0.5% of space (that's 1 in 200!) while encoding takes 4 times as long. Trying to get more compression out of FLAC will only yield diminishing results. FLAC was designed to decode fast. That's one of the reasons it became popular, but also a constraint on how far it can be pushed. If you really want to get the most out of FLAC, you should provide some patches (or hire someone to do it) that improve encoding within subset constraints. There's still one in-subset feature of the FLAC format that is not yet used, variable block length. Might get you 1% more compression at the cost of many, many hours of writing code and testing.
On Mar 14, 2013, at 13:24, Declan Kelly wrote:> 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 have a vague recollection that going beyond -4 is incompatible with certain hardware players. Sorry I don't have a reference for this, but it seems like even -8 or --best are not 100% compatible with all decoders. Going beyond that to -9 or even -12 seems like it would be far less than 100% compatible. Of course, the logical approach is to look into why these decoders can only handle some FLAC encodings, and work within those restrictions.> 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.I buy nearly everything in FLAC. I do not re-compress, and as far as I know there is no easy way to determine how the originals were compressed. Download speeds are faster, and I figure that my backups are already small enough using the original FLAC that I don't need to experiment with re-compressing in the hopes of getting the files even smaller. For original recordings, I use --best, but I'm not concerned with direct playback on all devices. If I have a problem with playback, I'd probably decode and re-encode. Also, my original recordings are raw and unmastered, so I rarely listen to them without mixing and processing. I then compress the mastered audio (for CD or HD audio) using FLAC again, as a backup of the final product. Again, I use -- best and --no-padding because it's convenient, but I wouldn't mind learning a better default command line. Brian