similar to: AW: AW: Incomplete format description?

Torsdag, 23 januar 2003, skrev Miroslav Lichvar <lichvarm@phoenix. inf.upol.cz>: >If input is 16 bit, side channel will be 17 bit (16bit - 16bit is >17bit number). And warmup samples will be (17 - wasted_bits) bit. Voila, this was the source of all my frustration, sync problems and who knows what. My decoder now works correctly for files encoded with the default settings. Are

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

Here's what I listed in that email. Merging doesn't appear to be necessary. If you have any build problems, let me know. Note that my detection code is Darwin-specific. It's a BSD call (sysctl()), so a change to the platform-detection macros should enable it to work on other BSDs. However, I don't know what that would be, and I couldn't determine any safe way to do the check

hello, I am now develloping an embeded decoding system for flac.I have a problem about the format of the rice coding: the residual begins with : 01 01 08 0C the first two bytes are the warmups, the prediction order is 2. and the 080C is the following: 00 0010 0000 001100 the first two bits mean: residual coding method is partitioned rice the following four bits mean: the partition order is 2 ;

--- CHI Hongliang <hongliang.chi@enst-bretagne.fr> wrote: > hello, > > I am now develloping an embeded decoding system for flac.I have a > problem about the format of the rice coding: > > the residual begins with : 01 01 08 0C > > the first two bytes are the warmups, the prediction order is 2. and > the 080C is the following: > 00 0010 0000 001100 > >

I have noticed lpc slowdown both in encoding and decoding, not related to new config.h stuff. It seems there is wrong choosing of fastest possible version of lpc function. Patch is attached. -- Miroslav Lichvar -------------- next part -------------- Index: src/libFLAC/stream_decoder.c =================================================================== RCS file:

--- Tor-Einar Jarnbjo <Tor-Einar_Jarnbjo@grosch-link.de> wrote: > Torsdag, 23 januar 2003, skrev Miroslav Lichvar <lichvarm@phoenix. > inf.upol.cz>: > > >If input is 16 bit, side channel will be 17 bit (16bit - 16bit is > >17bit number). And warmup samples will be (17 - wasted_bits) bit. > > Voila, this was the source of all my frustration, sync problems

I'm using libFLACC++ and libFLAC and 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

Josh Coalson wrote in 2009 <http://lists.xiph.org/pipermail/flac-dev/2009-April/002654.html>: "the reference encoder has avoided negative shifts entirely since 1.1.4. negative shifts were meant to be positive shifts in the opposite direction but they were implemented directly with << >> and in C negative shifts are undefined. treat as an error for now to avoid bad behavior

Torsdag, 23 januar 2003, skrev "Tor-Einar Jarnbjo" <Tor-Einar_Jarnbjo@grosch- link.de>: >- My implementation seems to decode fixed subframes now, but the lpc >subframes contains nothing but noise, and the bitstream is out of sync after >reading one. The source code I'm using for decoding the lpc subframe is >available here:

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

Hello you all, this is my first time on this forum because I recently started to learn this exciting "new" language and Frame stuff... anyway, I used to have Ruby 1.8.2 installed with Rails and I wrote some warmup applications on these. Yesterday I decided to update my Ruby and Rails... about 4-5 hours later I finished... it wasn''t easy but what is.. right? so I changed

On 7/11/2017 3:58 PM, Fred Smith wrote: > I faced the same issue some years ago, and found a low-priced mono > laser that lated me quite a few years. no color, but few thing I > wanted to print actually demanded color. my last two laser printers have been Brother black&white all-in-ones ("MFC"). *VERY* cheap per page printing costs, even if you use Brother brand toner

Hi I'm building new samba server (on Debian 6.0, software RAID10 2TB, Xeon CPU). Generally everything is working fine, so I have decided to run some stress tests. My choice was dbench. Old server is Debian 4.0 (samba 3.0.24, Athlon 3000+, one ATA 160GB disk). So run dbench 16 on both old and new server The results are strange old serwer: about 300MB/sek (dbench 3.0) and below are first

hi guys/gals I realize that this question must have been asked before, I sroogled and found some posts on the web on how to tweak/tune gluster, however.. What I hope is that some experts and/or devel could write a bit more, maybe compose a doc on - How to investigate and trouble gluster's speed-performance bottleneck. Why I think such a thorough guide would be important? Well.. I guess

Thanks Miroslav, for your help - much appreciated. > > RICE PARTITION SIZE: In a zero-partition-order Rice block, the > > documentation says the number of samples in the partition is equal > > to the frame's blocksize. Surely this should be equal to the > > frame's-blocksize-minus-the-predictor-order, since we shouldn't need > > to encode residual for

On 05/05/2015 07:21 PM, Jeremy Fitzhardinge wrote: > On 05/03/2015 10:55 PM, Juergen Gross wrote: >> I did a small measurement of the pure locking functions on bare metal >> without and with my patches. >> >> spin_lock() for the first time (lock and code not in cache) dropped from >> about 600 to 500 cycles. >> >> spin_unlock() for first time dropped

On 05/05/2015 07:21 PM, Jeremy Fitzhardinge wrote: > On 05/03/2015 10:55 PM, Juergen Gross wrote: >> I did a small measurement of the pure locking functions on bare metal >> without and with my patches. >> >> spin_lock() for the first time (lock and code not in cache) dropped from >> about 600 to 500 cycles. >> >> spin_unlock() for first time dropped

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