search for: evaluate_lpc_subframe_

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 http://git.xiph.org/?p=flac.git;a=commitdiff;h=20ac2c...

...p://git.xiph.org/?p=flac.git;a=commitdiff;h=27846708fe6271e5e3965a4bbad99baa1ca24c49 Now I remember a discussion about a bug in -p switch: the old code substracts lpc_order instead of FLAC__bitmath_ilog2(lpc_order), and this commit fixes this. It seems that the logic in process_subframe_() and in evaluate_lpc_subframe_() is the same, so the constants in the conditions should be the same: either both equal to 16, or both equal to 17. I built two flac executables, the 1st is from current git head, the 2nd - with my patch applied. Then I took a 16-bit WAV file and compressed it with both encoders. Standard compr...

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 subframe_bps + 4 Version 0 hangs du...

...We can only speculate about this, but I think this code has been duplicated > by accident, and therefore it wasn't changed as the code shouldn't have > been there in the first place. Well, the code in process_subframe_() calculates MAX value of qlp_coeff_precision, while the code in evaluate_lpc_subframe_() adjusts CURRENT qlp_coeff_precision. It's possible to move the logic from evaluate_lpc_subframe_() into process_subframe_(), see the attached patch, but I'm not sure that the code becomes much clearer after it. -------------- next part -------------- A non-text attachment was scrubbed......

...> because that value is either chosen by the encoder (it is a > lookup value, and is always small enough not to trigger this, > set in stream_encoder.c around line 700) or it is set through > the encoder, in which case it should probably not be overriden > without notice. Currently evaluate_lpc_subframe_() automatically adjusts qlp_coeff_precision when a user sets non-standard order value (via -l option). I don't think that it's incorrect behavior. Why not? (And my initial point was that the current limit of qlp_coeff_precision is not enough, and 32-bit datapath is *not* ensured for 16-bit...

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

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

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

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

...if(subframe_bps <= 17) { > max_qlp_coeff_precision = min(32 - subframe_bps - lpc_order, FLAC__MAX_QLP_COEFF_PRECISION); > max_qlp_coeff_precision = max(max_qlp_coeff_precision, min_qlp_coeff_precision); > } > > in process_subframe_(), whereas evaluate_lpc_subframe_() has the comments that you refer to. > > I've not done an analysis to determine whether these constants should match, or if maybe they should remain distinct. > > Brian Willoughby > > > On Apr 18, 2015, at 8:05 AM, lvqcl <lvqcl.mail at gmail.com> wrote: >>...

...arning: 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' shadows a global declaration /usr/include/sys/signal.h:407: warning: shadowed declaration is here stream_encoder.c: In function 'evaluate_verbatim_subframe_': stream_encoder.c:3625: warning: declaration of 'signal'...

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

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

...on = flac_min(32 - subframe_bps - lpc_order, FLAC__MAX_QLP_COEFF_PRECISION); + max_qlp_coeff_precision = flac_max(max_qlp_coeff_precision, min_qlp_coeff_precision); } else max_qlp_coeff_precision = FLAC__MAX_QLP_COEFF_PRECISION; @@ -3577,7 +3568,7 @@ unsigned evaluate_lpc_subframe_( if(subframe_bps <= 16) { FLAC__ASSERT(order > 0); FLAC__ASSERT(order <= FLAC__MAX_LPC_ORDER); - qlp_coeff_precision = min(qlp_coeff_precision, 32 - subframe_bps - FLAC__bitmath_ilog2(order)); + qlp_coeff_precision = flac_min(qlp_coeff_precision, 32 - subframe_bps - FLAC__bitmath...