search for: m_ln2

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

...e on Debian/alpha. Attached is a patch which combines this fix with my earlier patch. -- - mdz -------------- next part -------------- --- fixed.c.orig Sat May 19 18:28:08 2001 +++ fixed.c Sat May 19 18:26:50 2001 @@ -81,11 +81,11 @@ residual_bits_per_sample[3] = (real)((data_len > 0) ? log(M_LN2 * (real)(int64)total_error_3 / (real) data_len) / M_LN2 : 0.0); residual_bits_per_sample[4] = (real)((data_len > 0) ? log(M_LN2 * (real)(int64)total_error_4 / (real) data_len) / M_LN2 : 0.0); #else - residual_bits_per_sample[0] = (real)((data_len > 0) ? log(M_LN2 * (real)total_error_0 /...

...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: floor(log(cmax) / M_LN2) It turns out on at least some x86's compiling with gcc-2.91 (at least) the result of floor(log(8.0) / M_LN2) is 2.0 not 3.0. Anyway, I made a fix and also added code to detect and handle similar problems (related to FP accuracy). Josh __________________________________________________ Do...

...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 some x86's compiling with gcc-2.91 (at > > least) the > > result of floor(log(8.0) / M_LN2) is 2.0 not 3.0. Anyway, I made a > > fix and > > also added code to detect and handle similar problems (related to > > FP &gt...

...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 some x86's compiling with gcc-2.91 (at least) the > result of floor(log(8.0) / M_LN2) is 2.0 not 3.0. Anyway, I made a fix and > also added code to detect and handle similar problems (related to FP > accuracy). This appears to be triggered by -ffa...

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 &lt...

This patch allows MSVS to use M_LN2 const defined in math.h -------------- next part -------------- A non-text attachment was scrubbed... Name: mathln2.patch Type: application/octet-stream Size: 963 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20130904/14cd34db/attachment.obj

lvqcl wrote: > This patch allows MSVS to use M_LN2 const defined in math.h For this one, I'd prefer to see the _USE_MATH_DEFINES definition in the *.vcproj and FLAC.sln files. I'd be happy to have the removal of the two comments in the same commit. Cheers, Erik -- ---------------------------------------------------------------------- Eri...

...- cmp eax, edx - jne .not_order_2 - mov ebp, 2 - jmp short .got_order -.not_order_2: - cmp eax, esi - jne .not_order_3 - mov ebp, 3 - jmp short .got_order -.not_order_3: - mov ebp, 4 -.got_order: ; residual_bits_per_sample[0] = (FLAC__real)((data_len > 0 && total_error_0 > 0) ? log(M_LN2 * (double)total_error_0 / (double)data_len) / M_LN2 : 0.0); ; residual_bits_per_sample[1] = (FLAC__real)((data_len > 0 && total_error_1 > 0) ? log(M_LN2 * (double)total_error_1 / (double)data_len) / M_LN2 : 0.0); ; residual_bits_per_sample[2] = (FLAC__real)((data_len > 0 &amp...

...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 encoding at fixed.c:84. Decoding works fine for me. The floating point exception occurs here: 84 residual_bits_per_sample[0] = (real)((data_len > 0) ? log(M_LN2 * (real)total_error_0 / (real) data_len) / M_LN2 : 0.0); At the point of failure, the part inside the log() is zero, so the result of the log is -inf. On i386, dividing -inf / M_LN2 seems to evaluate to zero, while on alpha it gives a floating point exception. Here's a small test program:...

...the following code (you can see it in flac/decode.c, flac/encode.c, libFLAC/fixed.c and libFLAC/stream_decoder.c) ? #if defined _MSC_VER || defined __MINGW32__ /* with MSVC you have to spoon feed it the casting */ residual_bits_per_sample[0] = (FLAC__float)((total_error_0 > 0) ? log(M_LN2 * (FLAC__double)(FLAC__int64)total_error_0 / (FLAC__double)data_len) / M_LN2 : 0.0); ... #else residual_bits_per_sample[0] = (FLAC__float)((total_error_0 > 0) ? log(M_LN2 * (FLAC__double)total_error_0 / (FLAC__double)data_len) / M_LN2 : 0.0); ... #endif IOW: use (FLAC__double)(F...

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 :

...exact -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 > 4e5 || del*del > 2*M_LN2*(-DBL_MIN_EXP)) { ---------------------------------------^ gmake[2]: *** [pnt.o] Error 1 gmake[2]: Leaving directory `/home/ming/R-0.64.0/src/nmath' gmake[1]: *** [R] Error 1 gmake[1]: Leaving directory `/home/ming/R-0.64.0/src' gmake: *** [R] Error 1 When I changed this line into if...

...h -KPIC enjoy, tim... === diff -ru orig/R-0.64.0/src/nmath/pnt.c R-0.64.0/src/nmath/pnt.c --- orig/R-0.64.0/src/nmath/pnt.c Wed Apr 7 02:45:48 1999 +++ R-0.64.0/src/nmath/pnt.c Sat Apr 10 13:02:45 1999 @@ -80,7 +80,7 @@ del = -del; } - if (df > 4e5 || del*del > 2*M_LN2*(-DBL_MIN_EXP)) { + if (df > 4e5 || del*del > 2*M_LN2*(-(DBL_MIN_EXP))) { /*-- 2nd part: if del > 37.62, then p=0 below FIXME: test should depend on `df', `tt' AND `del' ! */ /* Approx. from Abramowitz & Stegun 26.7.10 (p.949) */ -.-....

Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Patch applied, tested, commited and pushed. Great. But, what about my other patches? I admit that many of them aren't necessary, but (imho) a couple of them are important. I can explain in detail why I think this.

Analogous to M_LN2 patch: the patch moves definition of M_PI from src/libFLAC/window.c and src/test_streams/main.c to include/share/compat.h -------------- next part -------------- A non-text attachment was scrubbed... Name: M_PI.patch Type: application/octet-stream Size: 1581 bytes Desc: not available Url : http://...

...ve restrict definition from include/share/compat.h. Applied. BTW, I tried to use 'restrict' keyword with MSVS 2010 and 2012 and in fact they don't support it. Only --restrict is supported. > * libFLAC and FLAC__ALIGN_MALLOC_DATA : Looks sane but doesn't apply. > * MSVC and M_LN2 : Looks sane but doesn't apply. It is also possible to add /D "_USE_MATH_DEFINES" as an additional option to libFLAC_static.vcproj and libFLAC_dynamic.vcproj. Don't know what is better. What do you think? > * bitmath.h: 1 typo, 1 warning : I don't see why the type has...

...ample. Against 0.9 or CVS? While this clearly fixes a bug, 0.9 still dies for me. #0 0x1600692a8 in FLAC__fixed_compute_best_predictor (data=0x11fc, data_len=1611182472, residual_bits_per_sample=0x0) at fixed.c:84 84 residual_bits_per_sample[0] = (real)((data_len > 0) ? log(M_LN2 * (real)total_error_0 / (real) data_len) / M_LN2 : 0.0); (gdb) bt #0 0x1600692a8 in FLAC__fixed_compute_best_predictor (data=0x11fc, data_len=1611182472, residual_bits_per_sample=0x0) at fixed.c:84 #1 0x160064808 in encoder_process_subframe_ (encoder=0x11ffb86f, max_partition_order=30...

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

> > I also had this verify error encoding a wav I ripped from a CD. I > didn't > > report this as it happended on flac running on debian linux > -current unstable. > > This error happened only with one track of a CD I was ripping. > > > > Another reason for me not reporting this was, that flac 1.0 running > on OpenBSD > > 2.9 encoded the wav with