search for: channel_assignment

...ption, the coding method has to be 0. > >I've been using libFLAC 1.0.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 a...

...I think that I'm using the calls in the typical order (see code below). But every monoe or stereo file that I send thru I get files that are the same sze as the orginal wave files. Doing a flac -a on the flac files I see that I get: frame=9 blocksize=4608 sample_rate=8000 channels=1 channel_assignment=INDEPENDENT subframe=0 wasted_bits=0 type=VERBATIM ....... Any idea why/ where I have goofed? Thanks, James Code snippet: =================================================== FlacEncoder flacCompressor; bool setValue = false; // set up regular par...

...e_->metadata_filter_ids_count = 0; } +/* Undo any special channel coding */ +static inline void read_channel_coding(FLAC__StreamDecoder *decoder) +{ + register FLAC__int32 left, right; + register unsigned i; + register FLAC__int32 *lchan, *rchan; + switch(decoder->private_->frame.header.channel_assignment) { + case FLAC__CHANNEL_ASSIGNMENT_INDEPENDENT: + /* do nothing */ + break; + case FLAC__CHANNEL_ASSIGNMENT_LEFT_SIDE: + FLAC__ASSERT(decoder->private_->frame.header.channels == 2); + lchan = &(decoder->private_->output[0])[0]; + rchan = &(decoder->private_->ou...

...: -2, and with the Fixed predictor, I got the decoded sample: 2*1-1 +(-2) = -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

...the decoded sample: 2*1-1 +(-2) > = -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 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...

...the > typical order (see code below). But every monoe or stereo file that > I send > thru I get files that are the same sze as the orginal wave files. > > Doing a flac -a on the flac files I see that I get: > > frame=9 blocksize=4608 sample_rate=8000 channels=1 > channel_assignment=INDEPENDENT > subframe=0 wasted_bits=0 type=VERBATIM > ....... > > Any idea why/ where I have goofed? > > Thanks, > > James > > > Code snippet: > =================================================== > FlacEncoder flacCompressor; &gt...

...code below). But every monoe or stereo file that >> I send >> thru I get files that are the same sze as the orginal wave files. >> >> Doing a flac -a on the flac files I see that I get: >> >> frame=9 blocksize=4608 sample_rate=8000 channels=1 >> channel_assignment=INDEPENDENT >> subframe=0 wasted_bits=0 type=VERBATIM >> ....... >> >> Any idea why/ where I have goofed? >> >> Thanks, >> >> James >> >> >> Code snippet: >> ================================================...