similar to: lpc slowdown

On Thu, Jun 19, 2014 at 06:25:57PM +0400, lvqcl wrote: > Now I wonder why evaluate_lpc_subframe_() function in stream_encoder.c contains > almost the same code, but without any comments that it's not enough pessimistic: > evaluate_lpc_subframe_(): > > if(subframe_bps + qlp_coeff_precision + FLAC__bitmath_ilog2(order) <= 32) > if(subframe_bps <= 16 &&

Here's what I listed in that email. Merging doesn't appear to be necessary. If you have any build problems, let me know. Note that my detection code is Darwin-specific. It's a BSD call (sysctl()), so a change to the platform-detection macros should enable it to work on other BSDs. However, I don't know what that would be, and I couldn't determine any safe way to do the check

--- configure.ac | 7 +++++ src/libFLAC/bitreader.c | 12 ++------- src/libFLAC/bitwriter.c | 8 ++---- src/libFLAC/fixed.c | 18 +++++-------- src/libFLAC/format.c | 8 ++---- src/libFLAC/include/private/macros.h | 29 ++++++++++++++++++++ src/libFLAC/metadata_iterators.c | 17 +++---------

On Thu, Jun 19, 2014 at 03:30:22PM +0400, lvqcl wrote: > BTW, what can you say about the following place in stream_decoder.c > in read_subframe_lpc_() function: > > /*@@@@@@ technically not pessimistic enough, should be more like > if( (FLAC__uint64)order * ((((FLAC__uint64)1)<<bps)-1) * ((1<<subframe->qlp_coeff_precision)-1) < (((FLAC__uint64)-1)

On Sun, Jun 24, 2001 at 02:30:56PM -0700, Josh Coalson wrote: > There have been reports of -9 using huge amounts of memory. -9 is really > theoretical, but people always seem to want to try the max setting. Anyway, > that's not an excuse but figuring out why -9 is using so much memory is lower > on my list than other stuff. -8 should get within 0.01% of -9 and is pretty >

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

Josh Coalson wrote in 2009 <http://lists.xiph.org/pipermail/flac-dev/2009-April/002654.html>: "the reference encoder has avoided negative shifts entirely since 1.1.4. negative shifts were meant to be positive shifts in the opposite direction but they were implemented directly with << >> and in C negative shifts are undefined. treat as an error for now to avoid bad behavior

This lpc_restore_order was partially inspired by Miroslav's affd, though my (not very great) ARM asm version resembled this, as well. The other two reduce CPU array indexing overhead in loops a little. Additionally, a request for help: My not very optimized lpc_restore_signal is at the below URL, I couldn't get the ldm* instructions to work as advertised, even though I've talked

Hi all, I was investigating the behaviour of the -p switch of flac. This switch should enable exhaustive search for the optimal qlp coefficient precision, but the resulting files are usually 0.5% larger then when not using the switch. I stumbled upon this code in stream_encoder > if(encoder->protected_->do_qlp_coeff_prec_search) { > min_qlp_coeff_precision =

I don't understand the comment in src/libFLAC/stream_decoder.c: /*@@@@@@ technically not pessimistic enough, should be more like if( (FLAC__uint64)order * ((((FLAC__uint64)1)<<bps)-1) * ((1<<subframe->qlp_coeff_precision)-1) < (((FLAC__uint64)-1) << 32) ) */ if(bps + subframe->qlp_coeff_precision + FLAC__bitmath_ilog2(order) <= 32) see

Torsdag, 23 januar 2003, skrev Tor-Einar Jarnbjo <Tor-Einar_Jarnbjo@grosch- link.de>: >According to the format description, the coding method has to be 0. > >I've been using libFLAC 1.0.4 to encode the stream. I've checked my interpretation against "flac -a" and it seems to read 17 bits for each warmup sample. Here is its output: frame=168 blocksize=4608

libFLAC limits the value of qlp_coeff_precision to make sure that 32-bit math is enough for decoding of 16-bit audio. subframe_bps can be equal to 17 for 16-bit input (for side channel). So the value of subframe_bps should be compared with 17, not 16 (see also http://git.xiph.org/?p=flac.git;a=blob;f=src/libFLAC/stream_encoder.c;hb=02591f6b4b09e7c6e26bd2ae7225ff2810b227bb#l3431 ) --------------

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

Martijn van Beurden wrote: > Yes, indeed. I removed the 17-bits part because I just matched > the code in evaluate_lpc_subframe_ with the process_subframe_ > code. It appears it only makes sense that those two pieces code > are the same. A bit of history: 1) The conditional "if(subframe_bps <= 16)" was added to evaluate_lpc_subframe_() in the commit

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

1) lpc.c, FLAC__lpc_quantize_coefficients(): This function declares "const int nshift = -(*shift)" variable when *shift is less than 0. Then nshift is used in the loop: for(i = 0; i < order; i++) { error += lp_coeff[i] / (1 << nshift); This patch adds "const int pshift = *shift" variable. Pros: * more symmetry for two branches * compiler doesn't

On Thu, Jun 19, 2014 at 03:30:06PM +0200, Miroslav Lichvar wrote: > But, as we have seen with unusual data the residual signal can be > wider than bps. The FLAC format specification doesn't seem to mention > this. Should it be treated as a valid FLAC stream? I think it would be interesting to know how common are such streams. I patched flac to print a warning on decoding or testing

To avoid crash caused by an unbound LPC decoding when predictor order is larger than blocksize, the sanity check needs to be moved to the subframe decoding functions. --- src/libFLAC/stream_decoder.c | 30 ++++++++++++------------------ 1 file changed, 12 insertions(+), 18 deletions(-) diff --git a/src/libFLAC/stream_decoder.c b/src/libFLAC/stream_decoder.c index d13b23b..211b4db 100644 ---

In the precompute_partition_info_sums_ function, instead of selecting 64-bit accumulator when the signal bps is larger than 16, revert to the original approach based on partition size, but make room for few extra bits to not overflow with unusual signals where the average residual magnitude may be larger than bps. It slightly improves the performance with standard encoding levels and 16-bit files

On Mon, Jun 30, 2014 at 03:27:18AM +0400, lvqcl wrote: > lvqcl wrote: > > FLAC 1.2.1 and 1.3.0 cannot encode snippet6.wav with -7 and -8 encoding modes. > > But they are able to do this with --disable-fixed-subframes option. This > > implies that snippet6.wav triggers a problem somewthere inside > > FLAC__fixed_compute_residual(data[], data_len, order, residual[])