search for: flake

Hello Is it planned someday to implement additional higher (9-12) compression modes like in Flake? http://flake-enc.sourceforge.net/ It's not very important I think. Harddrive space isn't problem today. But it preserves other indepentent work done on Flac and give room for some extra albums on harddrive. I think development of flake is stopped. I plan to test my ~20 GB flac collect...

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 option...

?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 compress...

...ou 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) >...

...ns that are already available in the official flac command-line, albeit without a short, numerical abbreviation. Brian Willoughby Sound Consulting On Mar 13, 2013, at 02:49, Marko Uibo wrote: > Is it planned someday to implement additional higher (9-12) > compression > modes like in Flake? > > http://flake-enc.sourceforge.net/ > > It's not very important I think. Harddrive space isn't problem today. > But it preserves other indepentent work done on Flac and give room for > some extra albums on harddrive. I think development of flake is > stopped. >...

...r 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 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 -8 presets, as these are all fixed block length.

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 wa...

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 hardware/s...

...ity 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 -...

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

# gem install rmagick Bulk updating Gem source index for: http://gems.rubyforge.org ERROR: While executing gem ... (OpenURI::HTTPError) 404 Not Found # gem update sources Updating installed gems... Attempting remote update of sources ERROR: While executing gem ... (Gem::GemNotFoundException) Could not find sources (> 0) in the repository # gem search rmagic --remote *** REMOTE GEMS

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

...nt extends above 20 kHz. But I just want to make sure that there isn't another technique that I'm missing. >> Some audio turns out smaller with ALAC, other audio turns out >> smaller with FLAC. Overall, the average performance is identical. > > I've been trying Flake (an alternative FLAC encoder; all it does is > encode) recently and while it goes way faster than the reference FLAC > encoder in terms of speed, the first encode I tried with it ended up > larger than with the reference encoder, at all compression levels. > The compression levels in Fl...

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

...r the content extends above 20 kHz. > > Google for that hydrogenaudio thread: Reznor made one post on it, and > mentioned that the recording was done at both 24/96 (Lavry) and 24/192 > (Apogee) on all songs, and they chose whichever they preferred at mix > time. > > >> If Flake is only an >> encoder, and compression levels above 8 are not guaranteed to be >> compatible, then what's the purpose? ?If Flake cannot decode, then >> what good is it to create a file that no other decoder can handle? > > Because it (hopefully) produces compatible FLAC...

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 was scrubbed... URL: http://lists.xiph.org/pipermail/flac/attachments/20070725/dd0f6d3c/attachment.html

...chema modulepath /usr/lib/ldap moduleload back_bdbn moduleload ppolicy.la moduleload smbk5pwd.la overlay smbk5pwd smbk5pwd-enable samba overlay ppolicy ppolicy_default "ou=default,ou=policies,dc=my,dc=test" ppolicy_use_lockout ppolicy_hash_cleartext Please help :( Flake -- C?dric CARLEN ?l?ve-ing?nieur ? TELECOM Lille 1 Promotion FI15 ? 06.59.42.81.55

...analysis makes it obvious whether the content extends above 20 kHz. Google for that hydrogenaudio thread: Reznor made one post on it, and mentioned that the recording was done at both 24/96 (Lavry) and 24/192 (Apogee) on all songs, and they chose whichever they preferred at mix time. > If Flake is only an > encoder, and compression levels above 8 are not guaranteed to be > compatible, then what's the purpose? If Flake cannot decode, then > what good is it to create a file that no other decoder can handle? Because it (hopefully) produces compatible FLAC files that can...

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

...tests are so flaky, I should think they > > should be marked UNSUPPORTED. Who has the authority to make those > > determinations? > > Dmitry Vyukov does. CC'ing him. Are there any special repro instructions? I am running all tsan tests periodically on linux and none of them flakes.