search for: evaluate_fixed_subframe_

...alue for residual[] is equal to max. bps for data[] + 4. > > The value of FLAC__MAX_EXTRA_RESIDUAL_BPS == 4 is enough to fix this problem > > with FLAC__fixed_compute_residual(). > > > On the other hand, it is possible to set FLAC__MAX_EXTRA_RESIDUAL_BPS > to 0, and change evaluate_fixed_subframe_() function instead: in the call > of find_best_partition_order_() function, replace subframe_bps > with subframe_bps + order. Adding the extra bits to bps in evaluate_fixed_subframe_ instead of precompute_partition_info_sums_ is ok with me, that's what I suggested in the original thread...

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) subframe_bps + order subframe_bps + 0 2) subframe_bps + order subframe_bps + 2 3) subframe_bps + order subframe_bps + 4 4) subframe_bps + 4 subfram...

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

...> 16 == 2^4, so max. bps value for residual[] is equal to max. bps for data[] + 4. > The value of FLAC__MAX_EXTRA_RESIDUAL_BPS == 4 is enough to fix this problem > with FLAC__fixed_compute_residual(). On the other hand, it is possible to set FLAC__MAX_EXTRA_RESIDUAL_BPS to 0, and change evaluate_fixed_subframe_() function instead: in the call of find_best_partition_order_() function, replace subframe_bps with subframe_bps + order. ...And maybe it's also better to use 'subframe_bps + order' instead of 'order' in calculation of 'estimate' variable in evaluate_fixed_subframe_()?

...; 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) subframe_bps + order subframe_bps + 0 > 2) subframe_bps + order subframe_bps + 2 > 3) subframe_bps + order subframe_bps + 4 > 4) subframe...

...here CC stream_encoder.lo stream_encoder.c: In function 'evaluate_constant_subframe_': stream_encoder.c:3454: warning: declaration of 'signal' shadows a global declaration /usr/include/sys/signal.h:407: warning: shadowed declaration is here stream_encoder.c: In function 'evaluate_fixed_subframe_': stream_encoder.c:3477: warning: declaration of 'signal' shadows a global declaration /usr/include/sys/signal.h:407: warning: shadowed declaration is here stream_encoder.c: In function 'evaluate_lpc_subframe_': stream_encoder.c:3539: warning: declaration of 'signal' sha...

...ping rice_parameter (%u -> %u) @0\n", rice_parameter, FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE_ESCAPE_PARAMETER - 1); #endif rice_parameter = FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE_ESCAPE_PARAMETER - 1; + do_escape_coding = true; } _candidate_bits = evaluate_fixed_subframe_( @@ -3251,7 +3252,7 @@ rice_parameter, min_partition_order, max_partition_order, - encoder->protected_->do_escape_coding, + do_escape_coding, encoder->protected_->rice_parameter_search_dist, subframe[!_best_subframe], partition...

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

Hi all, I have tagged 1.3.0pre4 in git and provided a tarball here: http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre4.tar.xz I have built and tested the git tree on: linux-x86_64 openbsd5-i386 freebsd5-i386 as well as successfully cross compiling from Linux to 32 and 64 bit MinGW. As far as I am concerned, the only thing left to do for this release is to update the