[flac-dev] flac-dev Digest, Vol 100, Issue 36

Fri Mar 15 00:22:24 PDT 2013

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-request at xiph.org> wrote:

> Send flac-dev mailing list submissions to
>         flac-dev at 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-request at xiph.org
>
> You can reach the person managing the list at
>         flac-dev-owner at 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-dev at groov.ie>
> To: FLAC dev <flac-dev at 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, 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
>
>
>
> ---------- Forwarded message ----------
> From: Martijn van Beurden <mvanb1 at gmail.com>
> To: flac-dev at 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 <vinyylimees at gmail.com>
> To: flac-dev at 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, 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.
>
>
>
> ---------- Forwarded message ----------
> From: Martijn van Beurden <mvanb1 at gmail.com>
> To: flac-dev at 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-dev at groov.ie>
> To: FLAC dev <flac-dev at 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, 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)
>
>
>
> ---------- Forwarded message ----------
> From: Declan Kelly <flac-dev at groov.ie>
> To: FLAC dev <flac-dev at 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, mvanb1 at 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+la at mega-nerd.com>
> To: flac-dev at 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 <mvanb1 at gmail.com>
> To: flac-dev at 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 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/20130315/871163d5/attachment-0001.htm 