similar to: [PATCH] stream_encoder.c: choose proper *fixed_compute_best_predictor* function

Erik de Castro Lopo wrote: > Rather than '#ifdef 0'-ing them out, shouldn't we remove them instead? Patch ver.2 attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: fixed_wide_v2.patch Type: application/octet-stream Size: 3303 bytes Desc: not available Url :

Erik de Castro Lopo wrote: > Applied with minor reformatting. Thanks. And btw, about reformatting: currently stream_encoder.c contains the following code: #ifdef FLAC__SSSE3_SUPPORTED if(encoder->private_->cpuinfo.ia32.ssse3) aaaaa; else #endif #ifdef FLAC__SSE2_SUPPORTED bbbbb; #endif This code is correct because if FLAC__SSSE3_SUPPORTED is defined then FLAC__SSE2_SUPPORTED is

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

Another interesting comment is inside src/libFLAC/include/private/fixed.h: "The _wide() version uses 64-bit integers which is statistically necessary when bits-per-sample + log2(blocksize) > 30" I mean the word "statistically". libFLAC uses FLAC__fixed_compute_best_predictor_wide() if "bits_per_sample + FLAC__bitmath_ilog2(blocksize)+1 > 30" is true (see

Miroslav Lichvar wrote: > 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

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

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

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,

On Fri, Jun 20, 2014 at 01:21:03PM +0400, lvqcl wrote: > Miroslav Lichvar ?????: > > > +/* > > + * This is used to avoid overflow with unusual signals in 32-bit > > + * accumulator in the *precompute_partition_info_sums_* functions. > > + */ > > +#define FLAC__MAX_EXTRA_RESIDUAL_BPS 4 > > > + /* WATCHOUT: "+ bps +

Miroslav Lichvar wrote: > I think it would be interesting to know how common are such streams. I > patched flac to print a warning on decoding or testing when this is > detected, but didn't find any files with this problem in my (small) > music collection. > > If someone has a large collection and some cycles to spare, can you please > consider compiling flac from git

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

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

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

Thanks for the quick response on the C++ thing. It would also be nice if the host program could correctly write the STREAMINFO block in the stream encoder metadata callback without having to know the specifics of the header format (or worry about endianness). How exactly to achieve this might take some thought, but what about this idea: 1. The correct way to respond to the metadata callback:

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

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)

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