<div dir="ltr">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.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 14, 2013 at 5:06 PM, <span dir="ltr"><<a href="mailto:flac-dev-request@xiph.org" target="_blank">flac-dev-request@xiph.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send flac-dev mailing list submissions to<br>
<a href="mailto:flac-dev@xiph.org">flac-dev@xiph.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.xiph.org/mailman/listinfo/flac-dev" target="_blank">http://lists.xiph.org/mailman/listinfo/flac-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:flac-dev-request@xiph.org">flac-dev-request@xiph.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:flac-dev-owner@xiph.org">flac-dev-owner@xiph.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of flac-dev digest..."<br>
<br>Today's Topics:<br>
<br>
1. Re: Higher compression modes from Flake (Declan Kelly)<br>
2. Re: Higher compression modes from Flake (Martijn van Beurden)<br>
3. Re: Higher compression modes from Flake (Marko Uibo)<br>
4. Re: Higher compression modes from Flake (Martijn van Beurden)<br>
5. Re: Higher compression modes from Flake (Declan Kelly)<br>
6. Re: Higher compression modes from Flake (Declan Kelly)<br>
7. Re: flac 1.3.0pre2 pre-release (Erik de Castro Lopo)<br>
8. Re: Higher compression modes from Flake (Martijn van Beurden)<br>
<br><br>---------- Forwarded message ----------<br>From: Declan Kelly <<a href="mailto:flac-dev@groov.ie">flac-dev@groov.ie</a>><br>To: FLAC dev <<a href="mailto:flac-dev@xiph.org">flac-dev@xiph.org</a>><br>Cc: <br>
Date: Thu, 14 Mar 2013 19:02:35 +0000<br>Subject: Re: [flac-dev] Higher compression modes from Flake<br>On Wed, Mar 13, 2013 at 10:06:51PM -0400, <a href="mailto:benski@winamp.com">benski@winamp.com</a> wrote:<br>
><br>
> Flake is a completely independent codebase. When I used it years ago, I<br>
> remember it being not only better compression but significantly faster as<br>
> well. I believe some of the techniques used in libflake were added to<br>
> libFLAC in 1.1.4. However, some of the improved compression in flake was<br>
> due to options that are outside the FLAC 'subset', such as larger<br>
> blocksize, greater number of prediction coefficients, and higher-order<br>
> Rice codes.<br>
<br>
When I tested flake, it was almost shockingly fast (compared to what I<br>
was used to with FLAC) but the tightest compression options didn't<br>
produce .flac files that could play on every playback device and/or<br>
software that I tested.<br>
<br>
It is a shame that development has stopped.<br>
<br>
The next official release of the FLAC command line should really have a<br>
"-9" option for absolute maxed-out big-memory CPU-burning compression.<br>
Most general purpose compression tools have "-9" as the tightest option<br>
for compression.<br>
<br>
--<br>
-Dec.<br>
---<br>
(no microsoft products were used to create this message)<br>
"Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994<br>
<br>
<br><br>---------- Forwarded message ----------<br>From: Martijn van Beurden <<a href="mailto:mvanb1@gmail.com">mvanb1@gmail.com</a>><br>To: <a href="mailto:flac-dev@xiph.org">flac-dev@xiph.org</a><br>Cc: <br>Date: Thu, 14 Mar 2013 20:12:14 +0100<br>
Subject: Re: [flac-dev] Higher compression modes from Flake<br>On 14-03-13 20:02, Declan Kelly wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The next official release of the FLAC command line should really have a "-9" option for absolute maxed-out big-memory CPU-burning compression.<br>
</blockquote>
<br>
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.<br>
<br>
<br>
<br><br>---------- Forwarded message ----------<br>From: Marko Uibo <<a href="mailto:vinyylimees@gmail.com">vinyylimees@gmail.com</a>><br>To: <a href="mailto:flac-dev@xiph.org">flac-dev@xiph.org</a><br>Cc: <br>Date: Thu, 14 Mar 2013 21:16:37 +0200<br>
Subject: Re: [flac-dev] Higher compression modes from Flake<br>Ühel kenal päeval (neljapäev, 14. märts 2013 19:02:35) kirjutas Declan Kelly:<br>
> On Wed, Mar 13, 2013 at 10:06:51PM -0400, <a href="mailto:benski@winamp.com">benski@winamp.com</a> wrote:<br>
> > Flake is a completely independent codebase. When I used it years ago, I<br>
> > remember it being not only better compression but significantly faster as<br>
> > well. I believe some of the techniques used in libflake were added to<br>
> > libFLAC in 1.1.4. However, some of the improved compression in flake was<br>
> > due to options that are outside the FLAC 'subset', such as larger<br>
> > blocksize, greater number of prediction coefficients, and higher-order<br>
> > Rice codes.<br>
><br>
> When I tested flake, it was almost shockingly fast (compared to what I<br>
> was used to with FLAC) but the tightest compression options didn't<br>
> produce .flac files that could play on every playback device and/or<br>
> software that I tested.<br>
><br>
> It is a shame that development has stopped.<br>
><br>
> The next official release of the FLAC command line should really have a<br>
> "-9" option for absolute maxed-out big-memory CPU-burning compression.<br>
> Most general purpose compression tools have "-9" as the tightest option<br>
> for compression.<br>
<br>
Flake higher compression levels make non-subset files. Computer are fast today<br>
and Flake more complex compression don't take very much time anymore. Other<br>
thing is that lossless compression can't be very much smaller. One possibility<br>
is to broaden Flac subset. But I don't know is it good idea or not. I'm just<br>
daily audiophile.<br>
<br>
<br><br>---------- Forwarded message ----------<br>From: Martijn van Beurden <<a href="mailto:mvanb1@gmail.com">mvanb1@gmail.com</a>><br>To: <a href="mailto:flac-dev@xiph.org">flac-dev@xiph.org</a><br>Cc: <br>Date: Thu, 14 Mar 2013 20:31:34 +0100<br>
Subject: Re: [flac-dev] Higher compression modes from Flake<br>On 14-03-13 20:16, Marko Uibo wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One possibility is to broaden Flac subset. But I don't know is it good idea or not.<br>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br><br>---------- Forwarded message ----------<br>From: Declan Kelly <<a href="mailto:flac-dev@groov.ie">flac-dev@groov.ie</a>><br>To: FLAC dev <<a href="mailto:flac-dev@xiph.org">flac-dev@xiph.org</a>><br>Cc: <br>
Date: Thu, 14 Mar 2013 20:24:43 +0000<br>Subject: Re: [flac-dev] Higher compression modes from Flake<br>On Thu, Mar 14, 2013 at 08:12:14PM +0100, <a href="mailto:mvanb1@gmail.com">mvanb1@gmail.com</a> wrote:<br>
<br>
> No. If you want such things, try TAK, OptimFROG, Monkey's Audio or even<br>
> LA, you'll lose hardware compatibility anyway and they do much better<br>
> than FLAC will with a -9 option.<br>
<br>
No. I want the tightest possible compression, while remaining 100%<br>
compatible with the subset that all known FLAC decoders can successfully<br>
stream or play now in cars, Hi-Fi units, "MP3 players" and cell phones.<br>
The out and out most widely supported lossless audio format could (and<br>
should) have a better "bang for the buck" to the average user (who has<br>
possibly been tempted away from MP3 or WMV or some Apple format).<br>
<br>
I buy a lot of music on Bandcamp (and similar sites) and usually get<br>
smaller files (for long term storage) when recompressing (flac -8).<br>
A common sentiment I have seen online is "my CPU time is too valuable to<br>
bother with maximum compression", but that ignores the fact that all of<br>
the copies made of those files are going to add up to something bigger.<br>
<br>
A recent Google-developed algorithm called Zopfli is taking a similar<br>
approach with the old Deflate method (first used in PKZip, still used<br>
today in PNG, gzip, zlib, etc).<br>
100% compatible with every web browser that can already decode the data.<br>
Not a new format, just the best that gzip/zlib can be.<br>
<br>
There is a huge increase in CPU requirement for compression, but that<br>
only has to be done once for each source file.<br>
<br>
<a href="http://googledevelopers.blogspot.ie/2013/02/compress-data-more-densely-with-zopfli.html" target="_blank">http://googledevelopers.blogspot.ie/2013/02/compress-data-more-densely-with-zopfli.html</a><br>
<br>
"Zopfli is best suited for applications where data is compressed once<br>
and sent over a network many times, for example, static content for the<br>
web."<br>
<br>
The compressed output is "only" 3-8% smaller than the best that zlib can<br>
do, but that adds up in a lot of scenarios. If I had a Web server full<br>
of hosted sites, each with at least one copy of jquery-1.9.1.min.js.gz<br>
(or some other common static component) or a very busy PNG-heavy site,<br>
every byte saved is going to save my disk and bandwidth costs, with no<br>
penalty for the Web audience viewing the websites (and compatibility<br>
with every 21st century browser).<br>
<br>
It's almost useless for on-the-fly compression, but asymmetrical codecs<br>
often are unsuited to that anyway, even at lower compression levels.<br>
<br>
<br>
> FLAC 1.0 had a -9 option and it was<br>
> removed with a good reason: almost no gain with added decoding complexity.<br>
<br>
Thanks; I didn't know that.<br>
<br>
--<br>
-Dec.<br>
---<br>
(no microsoft products were used to create this message)<br>
<br>
<br><br>---------- Forwarded message ----------<br>From: Declan Kelly <<a href="mailto:flac-dev@groov.ie">flac-dev@groov.ie</a>><br>To: FLAC dev <<a href="mailto:flac-dev@xiph.org">flac-dev@xiph.org</a>><br>Cc: <br>
Date: Thu, 14 Mar 2013 20:30:58 +0000<br>Subject: Re: [flac-dev] Higher compression modes from Flake<br>On Thu, Mar 14, 2013 at 08:31:34PM +0100, <a href="mailto:mvanb1@gmail.com">mvanb1@gmail.com</a> wrote:<br>
<br>
> It's not a good idea, except when you want to ruin FLACs reputation. One<br>
> of the reasons FLAC is (alongside ALAC) one of the two most popular<br>
> lossless codecs is because of the well-defined subset. I've tried Flake<br>
> -9, -10, -11 and -12 on my portable years ago, and while -9 did<br>
> reasonable, anything higher would just choke the player.<br>
<br>
I found that flake at higher preset compression levels would not even<br>
produce files that the FLAC command line tool could decompress.<br>
<br>
And I 100% agree that we shouldn't change the subset, or do anything to<br>
make any existing decoder fail.<br>
<br>
> If you want more compression, you can do it yourself. The -0 through -8<br>
> switches are just presets, you can use FLAC 1.0's -9 yourself with -l 32<br>
> -b 4608 -m -e -E -r 16 -p on FLAC 1.2.1, there's just no shortcut -9<br>
> anymore.<br>
<br>
I haven't studied Zopfli closely, but a similar "find the absolute best<br>
compression" iteration for FLAC is possible without altering the subset.<br>
There was some discussion on this list a few years ago about a<br>
preprocessor, but all I can find now is a preprocessor that makes WAV<br>
data easier to compress smaller (in a slightly lossy way).<br>
<br>
<br>
--<br>
-Dec.<br>
---<br>
(no microsoft products were used to create this message)<br>
"Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994<br>
<br>
<br><br>---------- Forwarded message ----------<br>From: Erik de Castro Lopo <<a href="mailto:mle%2Bla@mega-nerd.com">mle+la@mega-nerd.com</a>><br>To: <a href="mailto:flac-dev@xiph.org">flac-dev@xiph.org</a><br>Cc: <br>
Date: Fri, 15 Mar 2013 07:37:04 +1100<br>Subject: Re: [flac-dev] flac 1.3.0pre2 pre-release<br>Janne Hyvärinen wrote:<br>
<br>
><br>
> On 14.3.2013 9:37, Erik de Castro Lopo wrote:<br>
> > Janne Hyvärinen wrote:<br>
> ><br>
> >> The patch was made from the published pre2 version. It missed the MinGW<br>
> >> changes that were applied to git version.<br>
> > Patch applied. Thanks.<br>
> ><br>
> > Erik<br>
><br>
> Unfortunately with this commit the LRN's patch from commit<br>
> b85cc57d73a286a07e544823cbeb41d3122b4e94 was overwritten. Here's a patch<br>
> to bring its fixes back. Sorry I used old sources for the large patch.<br>
<br>
Applied, thanks!<br>
<br>
Erik<br>
--<br>
----------------------------------------------------------------------<br>
Erik de Castro Lopo<br>
<a href="http://www.mega-nerd.com/" target="_blank">http://www.mega-nerd.com/</a><br>
<br>
<br><br>---------- Forwarded message ----------<br>From: Martijn van Beurden <<a href="mailto:mvanb1@gmail.com">mvanb1@gmail.com</a>><br>To: <a href="mailto:flac-dev@xiph.org">flac-dev@xiph.org</a><br>Cc: <br>Date: Thu, 14 Mar 2013 22:06:02 +0100<br>
Subject: Re: [flac-dev] Higher compression modes from Flake<br>On 14-03-13 21:24, Declan Kelly wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
No. I want the tightest possible compression, while remaining 100%<br>
compatible with the subset that all known FLAC decoders can successfully<br>
stream or play now in cars, Hi-Fi units, "MP3 players" and cell phones.<br>
The out and out most widely supported lossless audio format could (and<br>
should) have a better "bang for the buck" to the average user (who has<br>
possibly been tempted away from MP3 or WMV or some Apple format).<br>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>_______________________________________________<br>
flac-dev mailing list<br>
<a href="mailto:flac-dev@xiph.org">flac-dev@xiph.org</a><br>
<a href="http://lists.xiph.org/mailman/listinfo/flac-dev" target="_blank">http://lists.xiph.org/mailman/listinfo/flac-dev</a><br>
<br></blockquote></div><br></div>