similar to: FLAC 1.1.2-beta: attn package maintainers

--- Christian Weisgerber <naddy@mips.inka.de> wrote: > Josh Coalson <xflac@yahoo.com> wrote: > > > FLAC 1.1.2 has been released. See the news item for full details: > > In doc/html, the api documentation is only installed if doxygen is > installed. Is this correct? I thought, doxygen was only required > to _build_ the api docs, but the package already comes

severity 200435 normal thanks I received this bug report from a Debian user. I can't think of any reason offhand why the command line tool would work while the xmms plugin would fail. ----- Forwarded message from Stephan Niemz <st.n@gmx.net> ----- Date: Tue, 8 Jul 2003 10:24:57 +0200 From: Stephan Niemz <st.n@gmx.net> Resent-From: Stephan Niemz <st.n@gmx.net> To: Debian

Torsdag, 23 januar 2003, skrev Miroslav Lichvar <lichvarm@phoenix. inf.upol.cz>: >If input is 16 bit, side channel will be 17 bit (16bit - 16bit is >17bit number). And warmup samples will be (17 - wasted_bits) bit. Voila, this was the source of all my frustration, sync problems and who knows what. My decoder now works correctly for files encoded with the default settings. Are

Running the basic (--disable-thorough-tests) test suite, I get these failures round-trip test (rt-1-24-111.raw) encode... Segmentation fault (core dumped) ERROR FAIL: ./test_flac.sh fsd24-01 (--channels=1 --bps=24 -0 -l 16 --lax -m -e -p): encode...ERROR during encode of fsd24-01 FAIL: ./test_streams.sh on alpha and amd64. By contrast, i386 is fine. (All OpenBSD/4.2.) Could be a generic LP64

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

--- Chris Csanady <cc@137.org> wrote: > Building the beta on the mac has one stumbling point: the ppc/as/ > libFLAC-asm.la is not currently built due to the configure define > FLaC__HAS_AS__TEMPORARILY_DISABLED, but it is expected to exist by > > libFLAC_la_LIBADD = ppc/as/libFLAC-asm.la > > in src/libFLAC/Makefile.am. After removing this line, it builds > and

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

Hi all, Sorry for bringing this up this short before the release, but I noticed something rather strange. I was doing some more exotic checks on the last pre-release when I tried test_streams.sh with FLAC 1.3.0 encoding and an older version (1.1.0 or something like that) decoding. This failed for 24-bit samples and I wondered why. After quite some tests and hex-editors, I found out this is

Yes, it's finally here. See the homepage for details, but here's a summary: - 10-15% decoder speedup - 24-bit input support restored - more robust plugins - new metadata block for Vorbis-style tags - vastly improved metadata editor - fixed bug with pipes and Windows - new libFLAC++, a C++ object wrapper around libFLAC - new metadata editing interface in libFLAC and libFLAC++ - and

Hi all, As people may have seen there's a pre-release here: http://downloads.xiph.org/releases/flac/beta/ Specifically: flac-1.3.1pre1.tar.xz : The source code flac-1.3.1pre1-win.zip : Windows 32 and 64 bit binaries Please test. I'm particularly interested in hearing about the windows binaries which were cross compiled from Linux to Windows. Unfortunately there is a bug

On Nov 26 22:39:27, hans at stare.cz wrote: > ./test_replaygain.sh fails for me in tonegenerator(), saying: > > ./test_replaygain.sh[91]: mawk: not found > Testing FLAC replaygain 8000 (8000 x 1) ... -: ERROR: got partial sample > > Apparently, the tone-generating awk script does not work with > my system's awk, which is "awk version 20110810" as distributed

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

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

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

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

All, I have just finished uploading the source release for FLAC 1.0.4 beta to Sourceforge; there are no binary releases. See the included doc/html/news.html for the changes since 1.0.3; there are quite a few. http://prdownloads.sourceforge.net/flac/flac-1.0.4_beta-src.tar.gz?download Please beat up on this as much as possible in the next week or two and try and turn up bugs. Here's a

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

Hi, This patch improves compression a very tiny bit on average, but up to 0.1 percentage point for classical music. I haven't found any tracks that show worsening compression with this patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Improve-LPC-order-guess.patch Type: text/x-patch Size: 0 bytes Desc: not available Url :

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