search for: partition_order

...const unsigned order, FLAC__bool do_full_decode); static FLAC__bool read_subframe_verbatim_(FLAC__StreamDecoder *decoder, unsigned channel, unsigned bps, FLAC__bool do_full_decode); -static 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); +static FLAC__bool read_residual_partitioned_rice_(FLAC__StreamDecoder *decoder, unsigned predictor_order, unsigned partition_order, FLAC__EntropyCodingMethod_PartitionedRi...

...DING_METHOD_PARTITIONED_RICE2_PARAMETER_LEN : FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE_PARAMETER_LEN; const unsigned pesc = is_extended? FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE2_ESCAPE_PARAMETER : FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE_ESCAPE_PARAMETER; - /* sanity checks */ - if(partition_order == 0) { - if(decoder->private_->frame.header.blocksize < predictor_order) { - send_error_to_client_(decoder, FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC); - decoder->protected_->state = FLAC__STREAM_DECODER_SEARCH_FOR_FRAME_SYNC; - return true; - } - } - else { - if(partitio...

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)

....4 to encode the stream. I've checked my interpretation against "flac -a" and it seems to read 17 bits for each warmup sample. Here is its output: frame=168 blocksize=4608 sample_rate=44100 channels=2 channel_assignment=RIGHT_SIDE subframe=0 wasted_bits=0 type=LPC order=5 partition_order=4 qlp_coeff_precision=12 quantization_level=9 warmup[0]=-993 warmup[1]=-476 warmup[2]=171 warmup[3]=115 warmup[4]=-766 Tor =================================================================== EASY and FREE access to your email anywhere: http://Mailreader.com/ ======================...

...ivate/format.h" - -#ifdef min -#undef min -#endif -#define min(a,b) ((a)<(b)?(a):(b)) +#include "private/macros.h" /* adjust for compilers that can't understand using LLU suffix for uint64_t literals */ #ifdef _MSC_VER @@ -542,7 +538,7 @@ unsigned FLAC__format_get_max_rice_partition_order_from_blocksize(unsigned block max_rice_partition_order++; blocksize >>= 1; } - return min(FLAC__MAX_RICE_PARTITION_ORDER, max_rice_partition_order); + return flac_min(FLAC__MAX_RICE_PARTITION_ORDER, max_rice_partition_order); } unsigned FLAC__format_get_max_rice_partition_order_fr...

I think I've gotten FLAC__lpc_restore_signal() about as good as I'm going to get it. Here's what I have: -a new file, lpc_asm.s, which has the assembly routines -changes to cpu.h, cpu.c, and stream_decoder.c to enable them -changes to configure.in to support the new cpu stuff -a preliminary Makefile.am -maybe something else I'm forgetting Now automake complains that configure.in

...>private_->residual[channel]+15U & ~0xf); + + FLAC__ASSERT((((long)residual) & 0xf) == 0); decoder->private_->frame.subframes[channel].type = FLAC__SUBFRAME_TYPE_VERBATIM; *************** *** 1965,1970 **** --- 1986,1993 ---- const unsigned partitions = 1u << partition_order; const unsigned partition_samples = partition_order > 0? decoder->private_->frame.header.blocksize >> partition_order : decoder->private_->frame.header.blocksize - predictor_order; + FLAC__ASSERT((((long)residual) & 0xf) == 0); + if(!FLAC__format_entropy_coding_m...

...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=0x8314758, frame_header=0xbfffe5ac, subframe_bps...

...) = -1, but the real number is 3.I can not figure out what is the problem. Is it the problem of the rice format? or the predictor? thanks this is what i got by: flac -a frame=0 blocksize=16 sample_rate=22050 channels=1 channel_assignment=INDEPENDENT subframe=0 wasted_bits=0 type=FIXED order=2 partition_order=2 warmup[0]=1 warmup[1]=1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20050410/f3c6a749/attachment.html

...igure out what is the > problem. Is it the problem of the rice format? or the predictor? > > thanks > > > this is what i got by: flac -a > frame=0 blocksize=16 sample_rate=22050 channels=1 > channel_assignment=INDEPENDENT > subframe=0 wasted_bits=0 type=FIXED order=2 partition_order=2 > warmup[0]=1 > warmup[1]=1 is it 8 bits-per-sample? if so, then the problem is this: > then, accdoring the ["k" zeroes][1][low-order bits][sign-bit] > format, I found the first decoded residual is : -2, that's not quite the correct format for the rice code. first,...

...0?\212Us??v??f??\231%\233??qJ??oLF\024???>?j%\237??" i = 44552 j = 8 val_i = 70816 cbits = 1 uval = 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 strea...

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