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%
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
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
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
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
Ühel kenal päeval (neljapäev, 14. märts 2013 22:06:02) kirjutas Martijn van
Beurden:
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
Hi,
On 03/14/2013 03:31 PM, Martijn van Beurden wrote:
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)
Christoph Terasa wrote:
Since MS refuses to support C99, the common practice is to use either
sprintf_s:
http://msdn.microsoft.com/en-us/library/ce3zzk1k(v=VS.80).aspx
_snprintf_s:
http://msdn.microsoft.com/de-de/library/f30dzcf6(v=VS.80).aspx
The former can be used as a
Microsoft provides a surprisingly good (but proprietary) API inside strsafe.h.
StringCchPrintfA can be substituted for snprintf but the return value is
different. A small wrapper function around StringCchPrintfExA could get you
enough information to emulate snprintf well. But sprintf_s
Ben Allison wrote:
Microsoft provides a surprisingly good (but proprietary) API inside
strsafe.h.
All of which are completely useless from cross platform code. I remember
looking at that stuff at some time and thinking that their API design
was somewhat lacking in clarity or vision (to be
10 matches
Mail list logo
