Displaying 20 results from an estimated 25 matches for "flac__lpc_restore_signal".
2004 Sep 10
3
Altivec, automake
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...
2004 Sep 10
4
Altivec Optimizations
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
2005 Oct 25
2
Re: Reg. FLAC decoding
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
2004 Sep 10
6
libFLAC internals
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' and...
2004 Nov 06
3
Compile flac-1.1.1 on ppc Linux
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:
2004 Sep 10
2
Altivec, automake
...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 a...
2004 Oct 06
3
flac-1.1.1 completely broken on linux/ppc and on macosx if built with the standard toolchain (not xcode)
...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)
make...
2004 Sep 10
0
libFLAC internals
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 :).
>...
2004 Oct 01
1
[PATCH] fix compile errors with asm disabled
...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__in...
2005 Oct 25
0
Re: Reg. FLAC decoding
...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];
d...
2005 Oct 25
1
Re: Reg. FLAC decoding
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 from...
2014 Dec 11
0
Two new CVEs against FLAC
...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 me....
2015 Apr 14
0
Warninig: ffmpeg FLAC en/decoder
.../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.
2015 Apr 20
2
About a comment in stream_decoder.c
...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.
2015 Aug 29
1
Undefined behaviour
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
2004 Oct 06
0
flac-1.1.1 completely broken on linux/ppc and on macosx if built with the standard toolchain (not xcode)
...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
>...
2014 Dec 11
2
Two new CVEs against FLAC
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
2020 Jun 25
0
FLAC specification clarification
...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 a...
2020 Jun 22
3
FLAC specification clarification
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
2020 Jun 26
2
FLAC specification clarification
...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 a...