similar to: flac-dev Digest, Vol 100, Issue 36

?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

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

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

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

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

Okay, I was thinking it may have been something to do with the header, but I wasn't sure how to verify that. thanks guys. On Mon, Apr 15, 2013 at 3:00 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 >

On Jul 18, 2015, at 10:46 AM, Martijn van Beurden <mvanb1 at gmail.com> wrote: > Op 16-07-15 om 07:50 schreef Brian Willoughby: >> On Jul 14, 2015, at 8:18 AM, Declan Kelly <flac-dev at groov.ie> wrote: >>> Can anyone on the list (possibly someone who works for MSFT) get this >>> fixed before Win10 is released? >> What size differences are we talking

> 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

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

On Jul 14, 2015, at 8:18 AM, Declan Kelly <flac-dev at groov.ie> wrote: > On Mon, Jul 13, 2015 at 01:28:22PM +0200, mvanb1 at gmail.com wrote: >> FLAC is not the only one though, Apple Lossless has been added >> to the mix in the same way, but (properly) creates smaller files. > > Can anyone on the list (possibly someone who works for MSFT) get this > fixed before

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

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

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

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

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,

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

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

Hi Martjn, and everyone, Apologies if I have missed the reply, but I think I have not got any comment so far on this. That means our new ID request is accepted? What should I do next to proceed?? Apparently this is my first time here, so appreciate any advice assistance. Best regards, Taku From: Kurosawa, Taku Sent: Thursday, November 22, 2018 8:41 PM To: 'Martijn van Beurden'

To me the real question is not whether that portion of the spec has been implemented by any existing encoders/decoders but whether the spec is broken (i.e. cannot be implemented as written). I don't know the rationale for making the LPC shift explicitly signed. In C a negative shift is undefined and it does seem in FLAC__lpc_restore_signal() for example that the LPC shift is used as the

Declan Kelly <flac-dev at groov.ie> wrote: > On Thu, Mar 08, 2012 at 09:50:20AM -0800, giles at thaumas.net wrote: >> I wouldn't worry about it though. It's unfortunate the dbPowerAmp >> developers want to take advantage of the subset of customer who don't >> understand what 'lossless' means. > > I read some of the articles on