Flake is a completely independent codebase. When I used it years ago, I remember it being not only better compression but significantly faster as well. I believe some of the techniques used in libflake were added to libFLAC in 1.1.4. However, some of the improved compression in flake was due to options that are outside the FLAC 'subset', such as larger blocksize, greater number of prediction coefficients, and higher-order Rice codes. -Ben Allison> Are you sure that the encoding library was improved, or just the > command line? > > Keep in mind that 1-8 (or 0-8) are just macros for particular > combinations of options that are also available separately. > > I'm just guessing, here, but 9-12 might be nothing more than selected > combinations of options that are already available in the official > flac command-line, albeit without a short, numerical abbreviation. > > Brian Willoughby > Sound Consulting
Speaking of better compression, I've been using the following options on the command line for ages. I'm not sure what they actually do (stole the recipe from a thread on this mailing list, if I remember right), but they seem to improve the compression ratio over just using --best (by 0.3 to 0.5% typically), without any obvious impact on the compression time (not that I measured that scientifically, mind you...) --apodization=tukey(0.25) --apodization=gauss(0.1875) Any one who would care to comment on what this does ? Thanks, Pyt. On Thu, Mar 14, 2013 at 3:06 AM, Ben Allison <benski at winamp.com> wrote:> Flake is a completely independent codebase. When I used it years ago, I > remember it being not only better compression but significantly faster as > well. I believe some of the techniques used in libflake were added to > libFLAC in 1.1.4. However, some of the improved compression in flake was > due to options that are outside the FLAC 'subset', such as larger > blocksize, greater number of prediction coefficients, and higher-order > Rice codes. > > -Ben Allison > > > Are you sure that the encoding library was improved, or just the > > command line? > > > > Keep in mind that 1-8 (or 0-8) are just macros for particular > > combinations of options that are also available separately. > > > > I'm just guessing, here, but 9-12 might be nothing more than selected > > combinations of options that are already available in the official > > flac command-line, albeit without a short, numerical abbreviation. > > > > Brian Willoughby > > Sound Consulting > > _______________________________________________ > flac-dev mailing list > flac-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20130314/05aa059c/attachment.htm
On Wed, Mar 13, 2013 at 10:06:51PM -0400, benski at winamp.com wrote:> > Flake is a completely independent codebase. When I used it years ago, I > remember it being not only better compression but significantly faster as > well. I believe some of the techniques used in libflake were added to > libFLAC in 1.1.4. However, some of the improved compression in flake was > due to options that are outside the FLAC 'subset', such as larger > blocksize, greater number of prediction coefficients, and higher-order > Rice codes.When I tested flake, it was almost shockingly fast (compared to what I was used to with FLAC) but the tightest compression options didn't produce .flac files that could play on every playback device and/or software that I tested. It is a shame that development has stopped. The next official release of the FLAC command line should really have a "-9" option for absolute maxed-out big-memory CPU-burning compression. Most general purpose compression tools have "-9" as the tightest option for compression. -- -Dec. --- (no microsoft products were used to create this message) "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994
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.
?hel kenal p?eval (neljap?ev, 14. m?rts 2013 19:02:35) kirjutas Declan Kelly:> On Wed, Mar 13, 2013 at 10:06:51PM -0400, benski at winamp.com wrote: > > Flake is a completely independent codebase. When I used it years ago, I > > remember it being not only better compression but significantly faster as > > well. I believe some of the techniques used in libflake were added to > > libFLAC in 1.1.4. However, some of the improved compression in flake was > > due to options that are outside the FLAC 'subset', such as larger > > blocksize, greater number of prediction coefficients, and higher-order > > Rice codes. > > When I tested flake, it was almost shockingly fast (compared to what I > was used to with FLAC) but the tightest compression options didn't > produce .flac files that could play on every playback device and/or > software that I tested. > > It is a shame that development has stopped. > > The next official release of the FLAC command line should really have a > "-9" option for absolute maxed-out big-memory CPU-burning compression. > Most general purpose compression tools have "-9" as the tightest option > for compression.Flake higher compression levels make non-subset files. Computer are fast today and Flake more complex compression don't take very much time anymore. Other thing is that lossless compression can't be very much smaller. One possibility is to broaden Flac subset. But I don't know is it good idea or not. I'm just daily audiophile.