similar to: Higher compression modes from Flake

Displaying 20 results from an estimated 2000 matches similar to: "Higher compression modes from Flake"

2013 Mar 14
3
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
2013 Mar 14
0
Higher compression modes from Flake
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,
2013 Mar 14
4
Higher compression modes from Flake
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
2013 Mar 13
0
Higher compression modes from Flake
On 13-03-13 10:49, Marko Uibo wrote: > I plan to test my ~20 GB flac collection how big difference flake -12 > gives me. But I still use reference implementation for my main collection. If I remember correctly gains were less then 0,5%, which for 20GB will be 100MB, not enough to get even one extra album in. If you like the idea of that little extra gain while sticking with FLAC (for
2013 Mar 14
0
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
2013 Mar 14
0
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
2013 Mar 14
1
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
2013 Mar 15
3
flac-dev Digest, Vol 100, Issue 36
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 >
2013 Mar 14
0
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
2013 Mar 16
1
Higher compression modes from Flake
On Mar 14, 2013, at 13:24, Declan Kelly wrote: > 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
2013 Mar 14
3
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
2012 Feb 08
3
FLAC Mathematical Details
Op 07-02-12 19:50, Ralph Giles schreef: > Basically the audio is chopped into a blocks and each block is coded > either uncompressed, as a constant value (good for silence), or with > linear predictive coding plus a rice-coded residual. I don't know how > the encoder decides where to put the block boundaries. AFAIK, FLAC uses a fixed block length so block boundaries are just put
2011 Jan 08
5
Idea to possibly improve flac?
Lots of comments throughout this one... On Jan 7, 2011, at 15:28, Declan Kelly wrote: > On Fri, Jan 07, 2011 at 02:22:51PM -0800, brianw at sounds.wa.com wrote: >> However, you should be aware that many modern producers use software >> to create their music, and when the software stores sound clips in >> MP3 format, what you end up with is music that sometimes looks like
2014 Mar 16
2
More than 150 MB / second encoding ?
Hello, Is there some version of FLAC that allows very very fast encoding (i.e. able to process at least 150 MB / second of .wav input data on a standard computer : laptop computer, Core i5/i7, Windows 7 64 bit, 8 GB RAM) ? (It's ok to have a compression ratio which is a little bit lower than traditionnal FLAC) I'm looking for something which is between FLAC (very good ratio, slower than
2007 Jul 25
3
FLAC: re-encoding
hi I have some questions about re-encoding existing FLAC files to FLAC 1.2.0.: - can older 1.1.x FLAC files be re-encoded to FLAC 1.2.0 by using the FLAC 1.2.0 encoder? - can FLAC files encoded with the FLAC Flake SVN encoder (or any other 'unofficial' FLAC encoder) be re-encoded by using the FLAC 1.2.0 encoder? thx in advance! -------------- next part -------------- An HTML attachment
2011 Jan 08
1
Idea to possibly improve flac?
> I was wrong about it going up to 11 - it actually goes up to 12. Too bad. I thought for a minute there that it goes up to eleven because... "Well, it's one louder, isn't it? It's not ten. You see, most blokes, you know, will be playing at ten. You're on ten here, all the way up, all the way up, all the way up, you're on ten on your guitar. Where can you go from
2012 Jun 01
3
Bad configuration file
Hello everyone, I'm writing you a topic because i have a problem with smaba and LDAP. This is my problem, when I type in the shell slapcat, i've got this message : str2entry: invalid value for attributeType objectClass #1 (syntax 1.3.6.1.4.1.1466.115.121.1.38) slapcat: bad configuration file! There is my slapd.conf : include /etc/ldap/schema/core.schema include
2012 Jul 02
1
NTLM Authentification
Hello, I'm trying to change my passwod when an user in log on his session XP. But at the closure of the session I see this in the log : ntlm_password_check: Checking NTLMv2 password with domain [TEST] ntlm_password_check: Checking NTLMv2 password with uppercased version of domain [TEST] ntlm_password_check: Checking NTLMv2 password without a domain ntlm_password_check: NTLMv2
2012 Feb 08
2
FLAC Mathematical Details
On 02/08/2012 11:49 AM, Ralph Giles wrote: > On 7 February 2012 21:59, Martijn van Beurden <mvanb1 at gmail.com> wrote: > >> AFAIK, FLAC uses a fixed block length so block boundaries are just put >> somewhere a block ends. Flake, another FLAC-encoders can use variable >> block length and has a algorithm to decide the length, but this is >> outside of the -0 to
2012 Feb 08
1
FLAC Mathematical Details
On 02/08/2012 01:06 PM, Ralph Giles wrote: > On 8 February 2012 10:00, Justin Ruggles <justin.ruggles at gmx.com> wrote: > >> 0.5% to 1.0% on average. That's with a fairly simple algorithm. > > Not very worthwhile. I imagine it's possible to do quite a bit more on > some files, but it would be pretty expensive to find the boundaries... Yes, it likely can do