search for: flac__lpc_restore_sign

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

Hi, I have been playing with Altivec, and I rewrote a couple of the routines in assembly. Looking at the archives, I noticed that there may already be some effort on this. Anyways... Right now, I have two routines working. They need to be cleaned up, made relocatable, and documented; otherwise, they seem to work fairly well. I see an overall ~27% speed improvement when encoding with the

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

Howdy. I'm working on Altivec versions of some of the libFLAC functions. I figured the best candidates would be those that had MMX/SSE/3dnow versions, and I picked FLAC__lpc_restore_signal() to do first, since it's relatively simple. In stepping through some runs, it appears that 'order' mod 4 is always 0. Is that guaranteed, either by the format or by higher functions in the reference decoder? Also, what assumptions can I make about the alignment of 'data' a...

Hi all, I'm trying to compile the flac-1.1.1 tarball on a Linux PPC system (a G3 iBook running Debian Testing). Configure is fine, but make bombs out almost immediately with: lpc_asm.s: Assembler messages: lpc_asm.s:1: Error: junk at end of line, first unrecognized character is `l' lpc_asm.s:2: Error: junk at end of line, first unrecognized character is `C' lpc_asm.s:4:

...fore using */ FLAC__EntropyCodingMethod_PartitionedRiceContents partitioned_rice_contents[FLAC__MAX_CHANNELS]; unsigned output_capacity, output_channels; FLAC__uint32 last_frame_number; *************** *** 281,286 **** --- 282,288 ---- decoder->private_->local_lpc_restore_signal = FLAC__lpc_restore_signal; decoder->private_->local_lpc_restore_signal_64bit = FLAC__lpc_restore_signal_wide; decoder->private_->local_lpc_restore_signal_16bit = FLAC__lpc_restore_signal; + decoder->private_->local_lpc_restore_signal_16bit_order8 = FLAC__lpc_restore_signal; /* now override with...

...aven't the time to investigate the issue yet=/) More verbose report about the no altivec bug: If I disable altivec optimization (with --disable-asm-optimizations --disable-altivec) the result is: stream_decoder.c: In function `FLAC__stream_decoder_init': stream_decoder.c:296: error: `FLAC__lpc_restore_signal' undeclared (first use in this function) stream_decoder.c:296: error: (Each undeclared identifier is reported only once stream_decoder.c:296: error: for each function it appears in.) stream_decoder.c:297: error: `FLAC__lpc_restore_signal_wide' undeclared (first use in this function) ma...

On Thu, Feb 20, 2003 at 05:46:50PM -0600, Brady Patterson wrote: > I'm working on Altivec versions of some of the libFLAC functions. I figured > the best candidates would be those that had MMX/SSE/3dnow versions, and I > picked FLAC__lpc_restore_signal() to do first, since it's relatively simple. > > In stepping through some runs, it appears that 'order' mod 4 is always 0. Is > that guaranteed, either by the format or by higher functions in the reference > decoder? No, 1 <= order <= 32. There is -l option :). &...

...e/lpc.h +++ mod/src/libFLAC/include/private/lpc.h @@ -61,6 +61,7 @@ void FLAC__lpc_compute_autocorrelation_asm_ia32_3dnow(const FLAC__real data[], unsigned data_len, unsigned lag, FLAC__real autoc[]); #endif #endif +#endif /* * FLAC__lpc_compute_lp_coefficients() @@ -146,17 +147,16 @@ void FLAC__lpc_restore_signal(const FLAC__int32 residual[], unsigned data_len, const FLAC__int32 qlp_coeff[], unsigned order, int lp_quantization, FLAC__int32 data[]); void FLAC__lpc_restore_signal_wide(const FLAC__int32 residual[], unsigned data_len, const FLAC__int32 qlp_coeff[], unsigned order, int lp_quantization, FLAC__...

...uring 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 > you think it is ok? we don't have any ARM optimizations yet, just x86 and ppc. but yes, FLAC__lpc_restore_signal() will give the most bang for the buck and is the easiest (it's just a multiply-accumulate-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];...

On Tue, 2005-10-25 at 23:04, Josh Coalson wrote: > we don't have any ARM optimizations yet, just x86 and ppc. but > yes, FLAC__lpc_restore_signal() will give the most bang for the > buck and is the easiest (it's just a multiply-accumulate-shift > loop). Aw., I dont think I can look into this right now. However, I have some doubts. Is it possible for the frame->header.bits_per_sample, frame->header.sample_rate to differ fr...

...applied and pushed. I think this revives the CVE, at least in some configurations. The patch seems to cover only the problem with memcpy writing past the buffer when blocksize is smaller than order, but not the unbound LPC decoding with functions that don't use data_len as a signed value, e.g. FLAC__lpc_restore_signal_16_intrin_sse2 for orders between 8 and 12, or the non-unrolled version of FLAC__lpc_restore_signal. The code below should catch that, but I'd rather see the real seeking bug fixed instead and not hide it like this. Returning success with invalid/uninitialized data seems like a bad idea to m...

.../4421 Some ffmpeg-encoded FLAC files can be successfully decoded by ffmpeg, but not FLAC. So it's either a bug somewhere (presumably in ffmpeg, but maybe in FLAC), or ffmpeg treats something differently than FLAC. libFLAC has routines like FLAC__lpc_compute_residual_from_qlp_coefficients and FLAC__lpc_restore_signal (and their ..._wide counterparts). libFLAC doens't allow the "sum" variable in them to overflow, right? It seems that ffmpeg routines allow this, and that's the reason of these problems.

...b69d48cd First, I suspect that there's a typo and the intended code is ... < (((FLAC__uint64)1) << 32) ) (without an unary minus). Second, this condition (in algebraic form) order * (2^bps - 1) * (2^qlp_coeff_precision - 1) < 2^32 makes sense if qlp_coeff[] and data[] in FLAC__lpc_restore_signal() are unsigned integers. But they are signed, and the condition should be order * 2^(bps-1) * 2^(qlp_coeff_precision-1) < 2^31 which is equivalent to the current bps + subframe->qlp_coeff_precision + FLAC__bitmath_ilog2(order) <= 32 So IMHO the comment is incorrect.

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 just publish my micro benchmarking code as part of the

...t; > > More verbose report about the no altivec bug: > > If I disable altivec optimization (with --disable-asm-optimizations > --disable-altivec) > > the result is: > > stream_decoder.c: In function `FLAC__stream_decoder_init': > stream_decoder.c:296: error: `FLAC__lpc_restore_signal' undeclared > (first use in this function) > stream_decoder.c:296: error: (Each undeclared identifier is reported > only once > stream_decoder.c:296: error: for each function it appears in.) > stream_decoder.c:297: error: `FLAC__lpc_restore_signal_wide' > undeclared &...

Erik de Castro Lopo wrote: > I think I have an alternative fix for the CVE which should not break > seeking. I'm working on getting an copy of the file with which to test. Patch applied and pushed. commit b4b2910bdca010808ccf2799f55562fa91f4347b Author: Erik de Castro Lopo <erikd at mega-nerd.com> Date: Wed Dec 10 18:54:16 2014 +1100

...on is not whether that portion of the spec has been implemented by any existing encoders/decoders but whether the spec is broken (i.e. cannot be implemented as written). I don't know the rationale for making the LPC shift explicitly signed. In C a negative shift is undefined and it does seem in FLAC__lpc_restore_signal() for example that the LPC shift is used as the argument to a right shift operation. It's possible (generally/conceptually, not necessarily here) a negative shift value could be used to represent a left shift. However, I know very little about linear prediction and how coefficients are chosen...

Yes, this is such a case. However, implementing this in a future encoder/decoder would break compatibility with most (likely all) existing decoders, and only in some very, very rare cases where the material is such that the encoder chooses to use negative shifts, which makes it even harder to troubleshoot. Furthermore, as this can only be used in very rare cases, there is no benefit from allowing

...on is not whether that portion of the spec has been implemented by any existing encoders/decoders but whether the spec is broken (i.e. cannot be implemented as written). I don't know the rationale for making the LPC shift explicitly signed. In C a negative shift is undefined and it does seem in FLAC__lpc_restore_signal() for example that the LPC shift is used as the argument to a right shift operation. It's possible (generally/conceptually, not necessarily here) a negative shift value could be used to represent a left shift. However, I know very little about linear prediction and how coefficients are chosen...