search for: residual_bits_per_sampl

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

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

...hen 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 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 f...

....not_order_0: - cmp eax, ecx - jne .not_order_1 - mov ebp, 1 - jmp short .got_order -.not_order_1: - 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_...

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

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) ? #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_...

...#39;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 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 exc...