I don't think you guys should worry too much about messing up old decoders, but no matter what you choose to do FLAC MUST REMAIN LOSSLESS.
On Thu, Mar 14, 2013 at 5:06 PM, <flac-dev-requ...@xiph.org> wrote: > Send flac-dev mailing list submissions to > flac-dev@xiph.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.xiph.org/mailman/listinfo/flac-dev > or, via email, send a message with subject or body 'help' to > flac-dev-requ...@xiph.org > > You can reach the person managing the list at > flac-dev-ow...@xiph.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of flac-dev digest..." > > Today's Topics: > > 1. Re: Higher compression modes from Flake (Declan Kelly) > 2. Re: Higher compression modes from Flake (Martijn van Beurden) > 3. Re: Higher compression modes from Flake (Marko Uibo) > 4. Re: Higher compression modes from Flake (Martijn van Beurden) > 5. Re: Higher compression modes from Flake (Declan Kelly) > 6. Re: Higher compression modes from Flake (Declan Kelly) > 7. Re: flac 1.3.0pre2 pre-release (Erik de Castro Lopo) > 8. Re: Higher compression modes from Flake (Martijn van Beurden) > > > ---------- Forwarded message ---------- > From: Declan Kelly <flac-...@groov.ie> > To: FLAC dev <flac-dev@xiph.org> > Cc: > Date: Thu, 14 Mar 2013 19:02:35 +0000 > Subject: Re: [flac-dev] Higher compression modes from Flake > On Wed, Mar 13, 2013 at 10:06:51PM -0400, ben...@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 > > > > ---------- Forwarded message ---------- > From: Martijn van Beurden <mva...@gmail.com> > To: flac-dev@xiph.org > Cc: > Date: Thu, 14 Mar 2013 20:12:14 +0100 > Subject: Re: [flac-dev] Higher compression modes from Flake > 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. > > > > > ---------- Forwarded message ---------- > From: Marko Uibo <vinyylim...@gmail.com> > To: flac-dev@xiph.org > Cc: > Date: Thu, 14 Mar 2013 21:16:37 +0200 > Subject: Re: [flac-dev] Higher compression modes from Flake > Ü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, ben...@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. > > > > ---------- Forwarded message ---------- > From: Martijn van Beurden <mva...@gmail.com> > To: flac-dev@xiph.org > Cc: > Date: Thu, 14 Mar 2013 20:31:34 +0100 > Subject: Re: [flac-dev] Higher compression modes from Flake > On 14-03-13 20:16, Marko Uibo wrote: > >> One possibility is to broaden Flac subset. But I don't know is it good >> idea or not. >> > > It's not a good idea, except when you want to ruin FLACs reputation. One > of the reasons FLAC is (alongside ALAC) one of the two most popular > lossless codecs is because of the well-defined subset. I've tried Flake -9, > -10, -11 and -12 on my portable years ago, and while -9 did reasonable, > anything higher would just choke the player. > > If you want more compression, you can do it yourself. The -0 through -8 > switches are just presets, you can use FLAC 1.0's -9 yourself with -l 32 -b > 4608 -m -e -E -r 16 -p on FLAC 1.2.1, there's just no shortcut -9 anymore. > > Changing things like the subset will get developers/hardware manufacturers > nervous (because no one can tell them one the next subset change will be, > which might render their device incompatible) so it should *never* be > changed, only in case of a complete format overhaul, FLAC 2.0 or something, > which is probably never going to happen. > > > > ---------- Forwarded message ---------- > From: Declan Kelly <flac-...@groov.ie> > To: FLAC dev <flac-dev@xiph.org> > Cc: > Date: Thu, 14 Mar 2013 20:24:43 +0000 > Subject: Re: [flac-dev] Higher compression modes from Flake > 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) > > > > ---------- Forwarded message ---------- > From: Declan Kelly <flac-...@groov.ie> > To: FLAC dev <flac-dev@xiph.org> > Cc: > Date: Thu, 14 Mar 2013 20:30:58 +0000 > Subject: Re: [flac-dev] Higher compression modes from Flake > On Thu, Mar 14, 2013 at 08:31:34PM +0100, mva...@gmail.com wrote: > > > It's not a good idea, except when you want to ruin FLACs reputation. One > > of the reasons FLAC is (alongside ALAC) one of the two most popular > > lossless codecs is because of the well-defined subset. I've tried Flake > > -9, -10, -11 and -12 on my portable years ago, and while -9 did > > reasonable, anything higher would just choke the player. > > I found that flake at higher preset compression levels would not even > produce files that the FLAC command line tool could decompress. > > And I 100% agree that we shouldn't change the subset, or do anything to > make any existing decoder fail. > > > If you want more compression, you can do it yourself. The -0 through -8 > > switches are just presets, you can use FLAC 1.0's -9 yourself with -l 32 > > -b 4608 -m -e -E -r 16 -p on FLAC 1.2.1, there's just no shortcut -9 > > anymore. > > I haven't studied Zopfli closely, but a similar "find the absolute best > compression" iteration for FLAC is possible without altering the subset. > There was some discussion on this list a few years ago about a > preprocessor, but all I can find now is a preprocessor that makes WAV > data easier to compress smaller (in a slightly lossy way). > > > -- > -Dec. > --- > (no microsoft products were used to create this message) > "Mosaic is going to be on every computer in the world." - Marc Andreessen, > 1994 > > > > ---------- Forwarded message ---------- > From: Erik de Castro Lopo <mle...@mega-nerd.com> > To: flac-dev@xiph.org > Cc: > Date: Fri, 15 Mar 2013 07:37:04 +1100 > Subject: Re: [flac-dev] flac 1.3.0pre2 pre-release > Janne Hyvärinen wrote: > > > > > On 14.3.2013 9:37, Erik de Castro Lopo wrote: > > > Janne Hyvärinen wrote: > > > > > >> The patch was made from the published pre2 version. It missed the > MinGW > > >> changes that were applied to git version. > > > Patch applied. Thanks. > > > > > > Erik > > > > Unfortunately with this commit the LRN's patch from commit > > b85cc57d73a286a07e544823cbeb41d3122b4e94 was overwritten. Here's a patch > > to bring its fixes back. Sorry I used old sources for the large patch. > > Applied, thanks! > > Erik > -- > ---------------------------------------------------------------------- > Erik de Castro Lopo > http://www.mega-nerd.com/ > > > > ---------- Forwarded message ---------- > From: Martijn van Beurden <mva...@gmail.com> > To: flac-dev@xiph.org > Cc: > Date: Thu, 14 Mar 2013 22:06:02 +0100 > Subject: Re: [flac-dev] Higher compression modes from Flake > 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. > > > _______________________________________________ > flac-dev mailing list > flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > >
_______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
