search for: flac__fixed_restore_signal

...se_mid_side=0, do_exhaustive_model_search=0, do_qlp_coeff_prec_search=0, rice_optimization_level=4, max_lpc_order=8, blocksize=4608, qlp_coeff_precision=0, padding=0) at encode.c:280 #7 0x12000a208 in main (argc=3, argv=0x11ffffc38) at main.c:293 and when decoding: #0 0x200000e7830 in FLAC__fixed_restore_signal (residual=0x1202ce480, data_len=4606, order=2, data=0x1202c9c78) at fixed.c:209 #1 0x200000ef25c in stream_decoder_read_subframe_fixed_ (decoder=0x1202b9c30, channel=0, bps=8, order=2) at stream_decoder.c:1158 #2 0x200000eeb34 in stream_decoder_read_subframe_ (decoder=0x1202b9c30,...

lvqcl wrote: > FLAC__fixed_restore_signal() is a part of flac *de*coder, so it makes > sense to test it on different architectures (ARM, MIPS?). But I have no > idea how to make it. Yes, but the code in FLAC__fixed_restore_signal() is (ignoring identifier name differences) identical to FLAC__fixed_compute_residual(), Maybe I should...

Hi all, People watching the git commits might have noticed that I have been fixing a number of issues around undefined behaviour. Why you ask? * Some forms of undefined behaviour have potential for security exploits. * Compiler writers are free to replace anything which invokes UB with a NOP or even, nothing at all. * Having large numbers of UB warnings makes it difficult (or rather time

Tests show that FLAC__fixed_compute_residual/FLAC__fixed_restore_signal are slightly faster when flac_restrict modifier is added to their arguments. (Encoding speed increase for flac -8 is about 2%. The difference is not very big yet measurable). -------------- next part -------------- A non-text attachment was scrubbed... Name: fixed.patch Type: application/octet-str...

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

Sorry for the delay in getting back to you., I was working on something else and just now got FLAC to work. Ok., FLAC files are playing now :) Cheers. There is a slight noise happening in the background., which i'm figuring out. I hope that it'll be solved soon. However, i wanted to know if there are any ARM specific optimizations that can be done. The processor is a 166MHz processor. Do

...mulate-shift loop). unsigned i, j; FLAC__int32 sum; for(i = 0; i < data_len; i++) { sum = 0; for(j = 0; j < order; j++) sum += qlp_coeff[j] * data[i-j-1]; data[i] = residual[i] + (sum >> lp_quantization); } the next would probably be FLAC__fixed_restore_signal(), which is also easy, and FLAC__bitbuffer_read_rice_signed_block(), which is unfortunately complicated. Josh __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

...* (real)total_error_4 / (real) data_len) / M_LN2 : 0.0); #endif return order; @@ -152,7 +152,7 @@ void FLAC__fixed_compute_residual(const int32 data[], unsigned data_len, unsigned order, int32 residual[]) { - unsigned i; + int i; switch(order) { case 0: @@ -190,7 +190,7 @@ void FLAC__fixed_restore_signal(const int32 residual[], unsigned data_len, unsigned order, int32 data[]) { - unsigned i; + int i; switch(order) { case 0:

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

I think I've gotten FLAC__lpc_restore_signal() about as good as I'm going to get it. Here's what I have: -a new file, lpc_asm.s, which has the assembly routines -changes to cpu.h, cpu.c, and stream_decoder.c to enable them -changes to configure.in to support the new cpu stuff -a preliminary Makefile.am -maybe something else I'm forgetting Now automake complains that configure.in

...der, &decoder->private_->partitioned_rice_contents[channel], residual)) return false; break; default: *************** *** 1850,1856 **** /* decode the subframe */ memcpy(decoder->private_->output[channel], subframe->warmup, sizeof(FLAC__int32) * order); ! FLAC__fixed_restore_signal(decoder->private_->residual[channel], decoder->private_->frame.header.blocksize-order, order, decoder->private_->output[channel]+order); return true; } --- 1863,1869 ---- /* decode the subframe */ memcpy(decoder->private_->output[channel], subframe->warmu...

Problems in FLAC 0.9: - On alpha, flac immediately dumps core for both encoding and decoding (FreeBSD/alpha). - The distribution Makefile.in files haven't been generated with "automake --include-deps". The resulting Makefiles aren't fully portable; in particular they break with BSD make. In the future, care should be taken to use "--include-deps". - What is