search for: rice_parameter

MSVS profiler shows that the following code in stream_encoder.c takes several percent of CPU time: for(rice_parameter = 0, k = partition_samples; k < mean; rice_parameter++, k <<= 1) ; this code is equivalent to: rice_parameter = 0; k = partition_samples; while(k < mean) { rice_parameter++; k <<= 1; } The idea was to accelerate it: rice_parameter = 0; k =...

Or, I was originally thinking: rice_parameter = 0; k = partition_samples; if (k < mean) { int n = mean - k; rice_parameter += n; k <<= n; } (sorry for the hasty post) On Oct 11, 2013, at 10:34, Brian Willoughby wrote: > Hmm, maybe I'm missing something, but what about this: > > rice_parameter = 0; k = partitio...

...y_alloc_aligned_unsigned_array(new_blocksize * 2, &encoder->private_->raw_bits_per_partition_unaligned, &encoder->private_->raw_bits_per_partition); /* now adjust the windows if the blocksize has changed */ #ifndef FLAC__INTEGER_ONLY_LIBRARY @@ -3170,6 +3169,7 @@ unsigned rice_parameter; unsigned _candidate_bits, _best_bits; unsigned _best_subframe; + FLAC__bool do_escape_coding = encoder->protected_->do_escape_coding; FLAC__ASSERT(frame_header->blocksize > 0); @@ -3237,6 +3237,7 @@ fprintf(stderr, "clipping rice_parameter (%u -> %u) @0\n"...

..., order, cmax); #endif for(i = 0; i < order; i++) { diff --git a/src/libFLAC/stream_encoder.c b/src/libFLAC/stream_encoder.c index e1cba75e..c22974fc 100644 --- a/src/libFLAC/stream_encoder.c +++ b/src/libFLAC/stream_encoder.c @@ -3452,7 +3452,7 @@ FLAC__bool process_subframe_( #endif rice_parameter++; /* to account for the signed->unsigned conversion during rice coding */ if(rice_parameter >= rice_parameter_limit) { -#ifdef DEBUG_VERBOSE +#ifndef NDEBUG fprintf(stderr, "clipping rice_parameter (%u -> %u) @0\n", rice_parameter, rice_parameter_limit - 1); #endif...

..., order, cmax); #endif for(i = 0; i < order; i++) { diff --git a/src/libFLAC/stream_encoder.c b/src/libFLAC/stream_encoder.c index 9279c0a3..dcdc70f0 100644 --- a/src/libFLAC/stream_encoder.c +++ b/src/libFLAC/stream_encoder.c @@ -3452,7 +3452,7 @@ FLAC__bool process_subframe_( #endif rice_parameter++; /* to account for the signed->uint32_t conversion during rice coding */ if(rice_parameter >= rice_parameter_limit) { -#ifdef DEBUG_VERBOSE +#ifndef NDEBUG fprintf(stderr, "clipping rice_parameter (%u -> %u) @0\n", rice_parameter, rice_parameter_limit - 1); #endif...

Hi Erik, I've found a middleground for the problem of setting default CFLAGS. I've gone back to setting them if {C,CXX,CPP,LD}FLAGS are unset at the onset of the configure script (i.e., the user hasn't specified anything) and then proceed to set them to the defaults as before. This has been suggested before: https://lists.gnu.org/archive/html/autoconf/2006-04/msg00022.html In

Dear FLAC devs, I would like to get some of our patches merged into master. Most of them deal with adhering to GNU conventions, respectively not overriding flags/variables that are up to the user to set. For instance, honoring $(htmldir) is important, as we have installation paths for the documentation that differ from what is currently coded in the various Makefile.am's. Regards David

On Thu, 2007-04-05 at 02:27 -0700, Brian Willoughby wrote: > Josh (Green), > > Seems like the longest example in your list is a 15-second file. I > would like to see the same problem exhibited in a file that is of a > normal length. I have been recording full performances lasting > hours, and flac always compresses the files below 70% of the original > size. >

Recently I was trying some new approaches to improve FLAC compression, when I stumbled on a possible overflow. The reason this has not come up earlier is because the encoder only hits this point when the estimate of the rice_parameter is very much off. To trigger this overflow, one has to force rice_parameter to 0 in for example the function evaluate_lpc_subframe in libFLAC/stream_encoder.c. When encoding noisy material, which needs a high rice parameter, it can happen that the return value of that function overflows. When this...

...AC__bool is_extended) +FLAC__bool read_residual_partitioned_rice_(FLAC__StreamDecoder *decoder, unsigned predictor_order, unsigned partition_order, FLAC__EntropyCodingMethod_PartitionedRiceContents *partitioned_rice_contents, FLAC__int32 *residual, FLAC__bool is_extended, int bps) { FLAC__uint32 rice_parameter; int i; @@ -2744,6 +2744,15 @@ FLAC__bool read_residual_partitioned_rice_(FLAC__StreamDecoder *decoder, unsigne u = (partition_order == 0 || partition > 0)? partition_samples : partition_samples - predictor_order; if(!decoder->private_->local_bitreader_read_rice_signed_block(deco...

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)

...68435453) at bitbuffer.c:254 #5 0x8061153 in FLAC__bitbuffer_write_rice_signed (bb=0x4085c800, val=-2147483630, parameter=4) at bitbuffer.c:658 #6 0x8056603 in subframe_add_residual_partitioned_rice_ (bb=0x4085c800, residual=0x8361200, residual_samples=4580, predictor_order=28, rice_parameters=0x407dc520, raw_bits=0x407fc520, partition_order=0) at encoder_framing.c:366 #7 0x80563eb in FLAC__subframe_add_lpc (subframe=0x407dc518, residual_samples=4580, subframe_bps=17, wasted_bits=0, bb=0x4085c800) at encoder_framing.c:310 #8 0x80544c8 in encoder_add_subframe_ (encoder=0x8...

Op ma 6 jul. 2020 om 10:22 schreef Erik de Castro Lopo <mle+la at mega-nerd.com>: > > Martijn van Beurden wrote: > > > To trigger this overflow, one has to force rice_parameter to 0 > > Ok, that sounds dodgy. Yes, well, it is. It could very well be that without patching, nobody ever has a problem with this, but as the rice code is based on an estimate, it might, perhaps. Especially if someone reenables rice_parameter_search, which is currently marked as deprecated....

...al = 631 msbs = 1 lsbs_left = 1 blurb = 158 '\236' save_blurb = 196 '?' state = 1 #1 0x4021f88d in read_residual_partitioned_rice_ (decoder=0x805ba58, predictor_order=3, partition_order=14, partitioned_rice_contents=0x805f478, residual=0x807dd80) at stream_decoder.c:1975 rice_parameter = 9 i = 2 partition = 0 sample = 0 u = 4294967293 partitions = 16384 partition_samples = 0 #2 0x4021f01f in read_subframe_fixed_ (decoder=0x805ba58, channel=1, bps=16, order=3) at stream_decoder.c:1832 subframe = (FLAC__Subframe_Fixed *) 0x805f988 i32 = -31667 u32 = 14 u = 14 #3 0x4021e...

...000e7304 in FLAC__fixed_compute_residual (data=0x1202b9c54, data_len=4607, order=1, residual=0x1202e6cc0) at fixed.c:165 #1 0x200000e1f44 in encoder_evaluate_fixed_subframe_ (signal=0x1202b9c50, residual=0x1202e6cc0, abs_residual=0x1202fd510, blocksize=4608, subframe_bps=8, order=1, rice_parameter=1, max_partition_order=4, subframe=0x200002aa2b0) at encoder.c:1028 #2 0x200000e1764 in encoder_process_subframe_ (encoder=0x1202b9bf0, max_partition_order=4, verbatim_only=0, frame_header=0x11ffff850, subframe_bps=8, integer_signal=0x1202b9c50, real_signal=0x1202be460, subfram...

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

...nd fast) estimation (of how many bits a residual value will be @@ -3886,7 +3883,7 @@ void precompute_partition_info_escapes_( } #ifdef EXACT_RICE_BITS_CALCULATION -static FLaC__INLINE unsigned count_rice_bits_in_partition_( +static inline unsigned count_rice_bits_in_partition_( const unsigned rice_parameter, const unsigned partition_samples, const FLAC__int32 *residual @@ -3901,7 +3898,7 @@ static FLaC__INLINE unsigned count_rice_bits_in_partition_( return partition_bits; } #else -static FLaC__INLINE unsigned count_rice_bits_in_partition_( +static inline unsigned count_rice_bits_in_partition_(...

> > I also had this verify error encoding a wav I ripped from a CD. I > didn't > > report this as it happended on flac running on debian linux > -current unstable. > > This error happened only with one track of a CD I was ripping. > > > > Another reason for me not reporting this was, that flac 1.0 running > on OpenBSD > > 2.9 encoded the wav with

...r_partition[to_partition] = max(m, raw_bits_per_partition[from_partition]); + raw_bits_per_partition[to_partition] = flac_max(m, raw_bits_per_partition[from_partition]); from_partition++; to_partition++; } @@ -3965,7 +3956,7 @@ FLAC__bool set_partitioned_rice_( FLAC__ASSERT(suggested_rice_parameter < FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE2_ESCAPE_PARAMETER); FLAC__ASSERT(rice_parameter_limit <= FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE2_ESCAPE_PARAMETER); - FLAC__format_entropy_coding_method_partitioned_rice_contents_ensure_size(partitioned_rice_contents, max(6, partition_o...