similar to: [Flac-users] settings for tighter compression than -8?

Early this past week, Miroslav Lichvar suggested for me: > Ok, you need 0.04% improvement, that should not be a problem. Try > flac --lax -e -p -l 32 -r 10 --no-padding Thank you again, Miroslav. I tried that, and it took almost two full days (surprisingly, Windows ME stayed up that long without crashing) to re-encode the entire set on my 266-MHz machine. After all, in the help file

On Sun, Apr 06, 2003 at 04:40:42PM -0500, David W. Tamkin wrote: > If processing time is not a big factor -- say, I could put up with four > to six times the duration of compressing at -8 -- what command-line > settings could one use to get even more compression? > > I have a case where the FLACs encoded at -8 are about 653.3 MB, but the > set comes with artwork whose jpegs

On Sat, Apr 12, 2003 at 05:49:06PM -0500, David W. Tamkin wrote: > Early this past week, Miroslav Lichvar suggested for me: > > >Ok, you need 0.04% improvement, that should not be a problem. Try > >flac --lax -e -p -l 32 -r 10 --no-padding > > Thank you again, Miroslav. I tried that, and it took almost two full > days (surprisingly, Windows ME stayed up that long

Miroslav Lichvar wrote: > Ok, you need 0.04% improvement, that should not be a problem. Perhaps a little more than that, since the sizes I listed were after stripping out the padding and all metadata blocks except SEEKTABLE and STREAMINFO. > Try flac --lax -e -p -l 32 -r 10 --no-padding > and if it is not enough, increase -r up to 16. Thank you. I'll do that. What, though,

--- Miroslav Lichvar <lichvarm@phoenix.inf.upol.cz> wrote: > On Sat, Nov 09, 2002 at 06:02:33PM +0100, Miroslav Lichvar wrote: > > On Fri, Nov 08, 2002 at 07:12:35PM -0800, Josh Coalson wrote: > > > Yeah, it's useful, so now there is a > > > FLAC__seekable_stream_decoder_get_decode_position() and > > > FLAC__file_decoder_get_decode_position(). I

Miroslav Lichvar wrote: > On Wed, Jul 17, 2013 at 07:45:53PM +1000, Erik de Castro Lopo wrote: > > The fix was changing one local variable from FLAC_uint32 to FLAC_uint64 > > in function precompute_partition_info_sums_(). > > > > https://git.xiph.org/?p=flac.git;a=commit;h=6f7ec60c7e7f05f5ab0b1cf6b7b0945e44afcd4b > > I don't like this fix. It will

On Fri, Nov 08, 2002 at 12:39:52PM -0800, Josh Coalson wrote: > --- Miroslav Lichvar <lichvarm@phoenix.inf.upol.cz> wrote: > > I have few notes: > > > > It seems there is changed API in CVS again. So, what about adding > > function like > > unsigned FLAC__format_frame_size(const FLAC__Frame *frame) > > which returns size of the frame in bytes. This

On Fri, May 04, 2012 at 05:53:23PM +0200, Miroslav Lichvar wrote: > The most interesting part of the patch is the rewrite of the > FLAC__bitreader_read_rice_signed_block function, which in the git repo > seems to have only couple lines changed since 1.2.1. Here is that part of the patch rebased against current git. In a quick test it gives a 10% speedup in decoding. -- Miroslav Lichvar

On Fri, Nov 08, 2002 at 07:12:35PM -0800, Josh Coalson wrote: > Yeah, it's useful, so now there is a > FLAC__seekable_stream_decoder_get_decode_position() and > FLAC__file_decoder_get_decode_position(). I haven't documented > them yet but you can see an example in > src/metaflac/operations_shorthand_seektable.c where I use it > during seektable creation. Ok, here is

El 03/05/12 12:19, Miroslav Lichvar escribi?: > It makes the C function faster than the corresponding asm routine, so > if it's included I'd suggest to just drop the asm function to not keep > around more asm code than is necessary. With current compilers it is very likely that those routines are already superflous.

On Thu, Sep 12, 2002 at 10:54:04PM +0200, Miroslav Lichvar wrote: > I tried tagging using metaflac with some iso-8859-2 chars, but these > chars were replaced by '#' chars, something wrong is here. Ok, here is simple patch, it works for me, but I'm not familiar with this stuff. BTW, metaflac --list prints comments in raw utf8, it can screw terminal easily. -- Miroslav Lichvar

Ok, what about enabling the 3dnow function in libFLAC by default? I think time has shown the function is bugfree... :) -- Miroslav Lichvar

I have noticed flac -S- isn't working correctly, '-' isn't handled in parse_option() nor in convert_to_seek_table_template(). It makes SEEKTABLE with one seek point. Similar options -V-, -e-, -p-, ... are not allowed since 1.0.4, I think best would be drop -S- from documentation too and use --no-seektable option only. -- Miroslav Lichvar

There's an entry in the changelog: "Improved decoding efficiency of all bit depths but especially so for 24 bits (lvqcl)" A couple of comments: 1) The patch that improves encoding for all depths was proposed by Miroslav Lichvar <http://git.xiph.org/?p=flac.git;a=commit;h=4eab6313cd2198b5647d925bdb3847590505fa21> 2) "Performance checks" graph posted by Martijn van

Ok, the patch from 2003 about improving seeking still didn't make it to CVS, so here is another try. I made some benchmarking with the test_seeking utility from flac sources to show how bad the current seeking is, especially without seektable. Track used for the experiment had about 50 minutes. In the following table is average number of seeks and number of decoded frames required for one

On Thu, Dec 11, 2014 at 11:12:25AM +0100, Martijn van Beurden wrote: > Op 11-12-14 om 10:53 schreef Martijn van Beurden: > > Op 11-12-14 om 10:05 schreef Miroslav Lichvar: > >> but I'd rather see the real seeking bug fixed instead > > > > I think I might have a fix [...] So the problem is that FLAC__stream_decoder_process_single returns error before it finds a

On Tue, Dec 17, 2002 at 01:01:08PM -0800, Josh Coalson wrote: > --- Miroslav Lichvar <lichvarm@phoenix.inf.upol.cz> wrote: > > Ok, what about enabling the 3dnow function in libFLAC by default? > > I think time has shown the function is bugfree... :) > > Yeah, I just haven't done it because I don't remember hearing > feedback from others about using it (or

El 03/05/12 12:19, Miroslav Lichvar escribi?: > Hi Josh, > > nice to see you here again. > > On Wed, Apr 25, 2012 at 04:26:05PM -0700, Josh Coalson wrote: >> (Jumping in again, maybe at the wrong point since this doesn't seem >> to involve encoding, but here goes.) >> >> Miroslav's patches have always been high-quality for sure. But >>

On Fri, Jun 20, 2014 at 01:21:03PM +0400, lvqcl wrote: > Miroslav Lichvar ?????: > > > +/* > > + * This is used to avoid overflow with unusual signals in 32-bit > > + * accumulator in the *precompute_partition_info_sums_* functions. > > + */ > > +#define FLAC__MAX_EXTRA_RESIDUAL_BPS 4 > > > + /* WATCHOUT: "+ bps +

--- Josh Coalson <xflac@yahoo.com> wrote: > > -- Miroslav Lichvar <lichvarm@phoenix.inf.upol.cz> wrote: > > On Tue, Dec 17, 2002 at 01:01:08PM -0800, Josh Coalson wrote: > > > --- Miroslav Lichvar <lichvarm@phoenix.inf.upol.cz> wrote: > > > > Ok, what about enabling the 3dnow function in libFLAC by > default? > > > > I think time