similar to: [PATCH] stream_encoder.c: fix subframe_bps comparison

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

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)

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 =

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[])

I have noticed lpc slowdown both in encoding and decoding, not related to new config.h stuff. It seems there is wrong choosing of fastest possible version of lpc function. Patch is attached. -- Miroslav Lichvar -------------- next part -------------- Index: src/libFLAC/stream_decoder.c =================================================================== RCS file:

stream_encoder.c has the following code: /* try to keep qlp coeff precision such that only 32-bit math is required for decode of <=16bps streams */ if(subframe_bps <= 16) { ... But FLAC can convert 16-bit input to 17-bit if mid-side coding is used. So, does it make sense to compare subframe_bps with 17? (The patch is attached. What do you think about it?) -------------- next part

Martijn van Beurden wrote: > Or maybe the question is: why is this code in evaluate_lpc_subframe anyway, > i.e, why is this code duplicated? If process_subframe_ sets the > qlp_precision for evaluate_lpc_subframe, why should the latter ignore that? > > We can only speculate about this, but I think this code has been duplicated > by accident, and therefore it wasn't changed

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

--- 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 +++---------

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

Erik de Castro Lopo wrote: >> It slightly improves the performance with standard encoding levels and >> 16-bit files as the 17-bit side channel can still be processed with the >> 32-bit accumulator and correctly selects the 64-bit accumulator with >> very large 16-bit partitions. >> >> This is related to commits 6f7ec60c and 187e596e. > > Sorry I

lvqcl wrote: > Erik de Castro Lopo wrote: > >>> It slightly improves the performance with standard encoding levels and >>> 16-bit files as the 17-bit side channel can still be processed with the >>> 32-bit accumulator and correctly selects the 64-bit accumulator with >>> very large 16-bit partitions. >>> >>> This is related to commits

Martijn van Beurden wrote: > Yes, but that MAX value is used to loop over the > qlp_coeff_precision values between MIN and MAX. So, if the > qlp_coeff_precision value is limited in the loop but MAX is not > limited, the loop does the exact same thing multiple times: a > waste of time. Therefore, only the MAX should be limited. > > I don't think the logic is needed

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

I changed the condition in *_precompute_partition_info_sums_*() functions from if(bps <= 16) to if(FLAC__bitmath_ilog2(default_partition_samples) + bps < 32) and then changed the 'subframe_bps' argument of find_best_partition_order_() in evaluate_fixed_subframe_() and evaluate_lpc_subframe_() as follows: evaluate_fixed_subframe_(): evaluate_lpc_subframe_(): 1)

Miroslav Lichvar wrote: > On Wed, Jul 17, 2013 at 07:45:53PM +1000, Erik de Castro Lopo wrote: > > The fix was changing one local variable from FLAC_uint32 to FLAC_uint64 > > in function precompute_partition_info_sums_(). > > > > https://git.xiph.org/?p=flac.git;a=commit;h=6f7ec60c7e7f05f5ab0b1cf6b7b0945e44afcd4b > > I don't like this fix. It will

On Fri, Jul 20, 2001 at 08:14:55PM -0700, Josh Coalson wrote: > --- Matt Zimmerman <mdz@debian.org> wrote: > > On Fri, Jul 20, 2001 at 10:51:11PM -0400, Matt Zimmerman wrote: > > > > > This version seems to work at least partially on ia64. I am able > > to encode my > > > usual test WAV file now, but I still get a segfault during the > >

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

When using the -p switch during encoding, the encoder should try different qlp predictor precision steps. However, some faulty code was too severely restricting the possible steps. This patch lifts the restriction to match a restriction coded a little further in the process. This doesn't make using -p worth your while, but at least it doesn't create larger files now ---