similar to: uint64 -> double conversion

On Sat, May 19, 2001 at 06:42:22PM -0400, Matt Zimmerman wrote: > I think this could be fixed by changing the (data_len > 0) test to be > (data_len > 0 && total_error_X > 0). Yes, this appears to have worked. I can now correctly encode and decode both my 8kHz/8-bit/mono sample, and a 44.1kHz/16-bit/stereo sample on Debian/alpha. Attached is a patch which combines this fix

I have optimized FLAC__fixed_compute_best_predictor_asm_ia32_mmx_cmov function and fixed bug when data_len == 0. Now the function is about 50% faster and flac -5 is about 5% faster on my box. I have tested it thoroughly, I think it can go to flac 1.0.4. -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/ia32/fixed_asm.nasm.orig 2002-01-26 19:05:12.000000000 +0100 +++

Matt Zimmerman <mdz@debian.org> wrote: > Aha. In FLAC__fixed_restore_signal, the index variable 'i' is declared > unsigned, then used like so: [...] With the following trivial patch applied, > everything works on Alpha, at least with my test sample. Against 0.9 or CVS? While this clearly fixes a bug, 0.9 still dies for me. #0 0x1600692a8 in

On Sat, May 19, 2001 at 08:03:54PM +0000, Christian Weisgerber wrote: > Matt Zimmerman <mdz@debian.org> wrote: > > > 0.9. As I said, I was using an 8-bit sample, > > Ah, that didn't quite register with me. I'm using a CD-style > 44.1kHz/stereo/16-bit test file. I repeated my test with a 44.1kHz/stereo/16bit file. I get a floating point exception when

Erik de Castro Lopo wrote: > That's a really good question. Haven't was already dropped support for > MSVC6? If so, we should drop this #ifdef hackery. Can test this without > the hackery for versions of MSVC > 6? I don't have VC 2002/2003, but the oldest Visual Studio that FLAC supports is MSVS 2005 anyway. It can compile FLAC__uint64 -> FLAC__double conversion

On Mon, Jan 24, 2005 at 06:31:21PM -0800, Josh Coalson wrote: > yes, a mere 2 years later it is checked in! > > speed improvement for me is roughly 17% testing flac files on > linux-i386. Thanks! In case you would like to check another old patch, I have attached updated patch for seekable stream decoder, originally posted on 09/07/2003. -- Miroslav Lichvar -------------- next

On Mon, Oct 30, 2006 at 11:13:25AM -0800, Josh Coalson wrote: > my apologies for not doing this before Miroslav... I will definitely > integrate it this time. 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 streams with shuffled frames. -- Miroslav Lichvar -------------- next part

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

Matt Zimmerman <mdz@debian.org> wrote: > 0.9. As I said, I was using an 8-bit sample, Ah, that didn't quite register with me. I'm using a CD-style 44.1kHz/stereo/16-bit test file. > to avoid dealing with endian issues in the file format. I don't > know whether any of those exist or not. I don't think so. 0.9 works fine on i386 (little) and sparc (big), and

--- configure.ac | 7 +++++ src/libFLAC/bitreader.c | 12 ++------- src/libFLAC/bitwriter.c | 8 ++---- src/libFLAC/fixed.c | 18 +++++-------- src/libFLAC/format.c | 8 ++---- src/libFLAC/include/private/macros.h | 29 ++++++++++++++++++++ src/libFLAC/metadata_iterators.c | 17 +++---------

On Sat, May 19, 2001 at 12:55:08AM -0400, Matt Zimmerman wrote: > On Sat, May 19, 2001 at 02:05:14AM +0000, Christian Weisgerber wrote: > > > Problems in FLAC 0.9: > > > > - On alpha, flac immediately dumps core for both encoding and > > decoding (FreeBSD/alpha). > > I have reproduced this on Debian/alpha as well. I will spend some time > debugging it

When I was trying to find yesterday's xmms-plugin bug, i have noticed that seeking in stream without seek-table isn't very good. With attached patch it is much better. -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/seekable_stream_decoder.c.orig 2003-02-26 19:41:51.000000000 +0100 +++ src/libFLAC/seekable_stream_decoder.c 2003-07-09 23:49:35.000000000 +0200

Ok, here is a patch waiting for new CVS :). It works fine for me, but please check it before commiting... -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/bitbuffer.c.orig 2003-01-30 17:36:01.000000000 +0100 +++ src/libFLAC/bitbuffer.c 2003-01-30 21:53:18.000000000 +0100 @@ -51,6 +51,25 @@ */ static const unsigned FLAC__BITBUFFER_DEFAULT_CAPACITY = ((65536 - 64) *

lvqcl wrote: > Anybody knows the reason for the following code > (you can see it in flac/decode.c, flac/encode.c, libFLAC/fixed.c and > libFLAC/stream_decoder.c) ? <snip> > Is it MSVC6 specific? The following web pages seem to confirm this: > http://www.winehq.org/pipermail/wine-patches/2004-September/012502.html >

On Mon, Jul 02, 2001 at 09:50:38PM -0700, Josh Coalson wrote: > After some intense debugging, I found the problem. One block in the file > triggered a very rare bug in the LPC coefficient quantizer caused by > insufficient floating point precision. There is a snippet to compute the > log(base 2) of a number: > > floor(log(cmax) / M_LN2) > > It turns out on at least

> > After some intense debugging, I found the problem. One block in > > the file > > triggered a very rare bug in the LPC coefficient quantizer caused > > by > > insufficient floating point precision. There is a snippet to > > compute the > > log(base 2) of a number: > > > > floor(log(cmax) / M_LN2) > > > > It turns out on at

math.h file in MS VC++ _does_ have M_LN2 constant but it requires _USE_MATH_DEFINES: --- a\src\libFLAC\fixed.c 2013-08-13 13:30:24.000000000 +0400 +++ b\src\libFLAC\fixed.c 2013-08-14 10:14:07.873648300 +0400 @@ -34,6 +34,9 @@ # include <config.h> #endif +#if defined(_MSC_VER) +#define _USE_MATH_DEFINES +#endif #include <math.h> #include <string.h> #include

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 :

> Also, Kai has been kind enough to send me a copy of his file which > has a > problem only on -8, which I'll be looking into soon. After some intense debugging, I found the problem. One block in the file triggered a very rare bug in the LPC coefficient quantizer caused by insufficient floating point precision. There is a snippet to compute the log(base 2) of a number:

Dear all, Compiling R-0.64.0 on DEC osf4.0 has the following error message (earlier version was OK). cc -ieee_with_inexact -g -I../include -I../../src/include -c pnf.c -o pnf.o cc -ieee_with_inexact -g -I../include -I../../src/include -c pnt.c -o pnt.o cc: Error: pnt.c, line 83: In this statement, "1021" is not an lvalue, but occurs in a context that requires one. if (df >