search for: lichvar

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

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

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

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

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

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 valid frame? > Another solution might be to 'just try again' somewher...

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

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 Beurden reminded me that the decoding improvements for FLAC were made only for 32-bit x64 architecture (aka IA32). FLAC is multiplatform, so it...

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 + FLAC__M...

--- 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? > > &g...

ok, tried it out... passes test/test_seeking.sh and my "xmms twitch" test, checked in to CVS. thanks! Josh --- Miroslav Lichvar <lichvarm@phoenix.inf.upol.cz> wrote: > On Fri, Nov 03, 2006 at 10:01:42AM +0100, Miroslav Lichvar wrote: > > Thanks. Sending latest version of the patch. Now it can seek in > files > > that have large id3 tag (or any random data) at the end and it > won't loop on &g...

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

On Sat, Oct 05, 2002 at 12:26:12PM -0400, Hod McWuff wrote: > On Sat, 2002-10-05 at 03:19, Miroslav Lichvar wrote: > > On Fri, Oct 04, 2002 at 01:57:03PM -0400, Hod McWuff wrote: > > > Agreed that the oversampling isn't useful in the long term. I'm not sure > > > what you mean by 'dictioniary overhead'. > > > > > > I'd like to see an easy-to-...

...a frame boundary. I was playing with variable blocksize some time ago. I used something like brute force search, no invention at all. I got ~1.5% improvement of compression, but 10 second sample took about hour of encoding :-). If there is some fast algo for that, it would be cool. -- Miroslav Lichvar

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

...5:21: note: previous declaration of 'float_t' was here typedef long double float_t; /* `float' expressions are evaluated as ^ Makefile:613: recipe for target 'grabbag/replaygain.lo' failed It seems to be related to the recent commit b4f7528e. -- Miroslav Lichvar

On Thu, Jun 19, 2014 at 07:28:11PM +1000, Erik de Castro Lopo wrote: > Miroslav Lichvar wrote: > > In file included from /usr/include/math.h:45:0, > > from grabbag/replaygain.c:25: > > /usr/include/bits/mathdef.h:35:21: note: previous declaration of 'float_t' was here > > typedef long double float_t; /* `float' expressions are eval...

Miroslav Lichvar wrote: > Well, this reverts the commit 18e0154. How is the user supposed to set > CFLAGS without getting -O3 -funroll-loops there? (e.g. to minimize the > size of the compiled binaries) Is it -O3 or -funroll-loops that you have a problem with? Or both? What would you prefer to see as the...

...here is an statistically measurable performance, keep it, otherwise > remove the FLAC__BYTES_PER_WORD == 8 code all together. I'll try to do it, but I don't have a deep understanding of bit(read|write) routines such as FLAC__bitreader_read_rice_signed_block() and other. Maybe Miroslav Lichvar can say something? > Since you seem to think there little to be gainned No, I just don't know what performance improvement can be obtained (and of course FLAC is very fast already).

...foo.flac', it gives to stdout wav data instead of big endian raw data as i expected, but 'flac -d -fr -fb -c' works fine. I think -d -fb should implied -fr. And when i give it multiple files like 'flac -d -c -fr -fb foo1.flac foo2.flac', it decode only first file. -- Miroslav Lichvar mirator@upcase.inf.upol.cz