similar to: rice format

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

Torsdag, 23 januar 2003, skrev Tor-Einar Jarnbjo <Tor-Einar_Jarnbjo@grosch- link.de>: >According to the format description, 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

looks fine, I would suspect how the PCM sample are formatted and sent to process(), could you show that part of the code? Josh --- James Smith <jsmith@landmarkdigital.com> wrote: > > 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

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

Here's how I set up the data for processing: // For moving data into 32 bit shape uint8_t *buffer8 = NULL; uint16_t *buffer16 = NULL; uint32_t *buffer32 = NULL; unsigned sample32; unsigned sample, channel; uint32_t bitsPerSample = this->get_bits_per_sample(); numFrames = inData.GetSize();

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

This lpc_restore_order was partially inspired by Miroslav's affd, though my (not very great) ARM asm version resembled this, as well. The other two reduce CPU array indexing overhead in loops a little. Additionally, a request for help: My not very optimized lpc_restore_signal is at the below URL, I couldn't get the ldm* instructions to work as advertised, even though I've talked

On Sun, Jun 24, 2001 at 02:30:56PM -0700, Josh Coalson wrote: > There have been reports of -9 using huge amounts of memory. -9 is really > theoretical, but people always seem to want to try the max setting. Anyway, > that's not an excuse but figuring out why -9 is using so much memory is lower > on my list than other stuff. -8 should get within 0.01% of -9 and is pretty >

----- Forwarded message from Don Armstrong <don@donarmstrong.com> ----- Date: Thu, 30 Sep 2004 16:19:41 -0700 From: Don Armstrong <don@donarmstrong.com> Resent-From: Don Armstrong <don@donarmstrong.com> To: submit@bugs.debian.org Subject: Bug#274301: libflac4 segfaults on corrupt flac files Severity: normal Package: libflac4 Version: 1.1.0-11 Running ogg123 on

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

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

> > You should only need to run this script if doing a in place > > upgrade from 4.7.x to 4.8.0 or 4.8.1 fails. I see you are using 4.8.2. > > This should have been fixed. Did you upgrade from 4.7.x to 4.8.2 and > > have > issues? > > > > Most likely you will need to restore from backup or create a new DC > > if you can't run the script.

On Mon, 2018-06-11 at 09:34 +0200, renaud.rolles at giraudbtp.com wrote: > > > You should only need to run this script if doing a in place > > > upgrade from 4.7.x to 4.8.0 or 4.8.1 fails. I see you are using 4.8.2. > > > This should have been fixed. Did you upgrade from 4.7.x to 4.8.2 and have > > > > issues? > > > > > > Most likely

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

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

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

--- Paul Harrison <pfh@mail.csse.monash.edu.au> wrote: > Hello, > > I am the author of the Bonk audio compression program... i've just > been > looking at your comparrison table, and i noticed bonk gets marginally > better compression than Flac on some files (actually i was > rather surprised to see bonk on the list at all, it's not exactly > high >

On Sun, Apr 27, 2003 at 07:28:48PM +1000, Paul Harrison wrote: > On Sun, 27 Apr 2003, Miroslav Lichvar wrote: > > > However, decoding will not be very fast. I think it is possible to > > speed up bonk implementation (with some additional tables), but > > probably it will never be as fast as decoding of rice codes. > > Agreed, there's too much juggling going on

Hi, I asked a few questions about the flac format a couple of weeks ago. One more (if you don't mind) about the Rice coding. The Rice parameter "k" can't be zero (unless I'm mistaken), yet the FLAC spec says the Rice parameter can range from 0 to 15. I guessed, and tried adding one before using the parameter (i.e. assuming the range was really 1 to 16), and that didn't

On Tue, Jul 11, 2006 at 04:17:41PM -0700, Mary Amon wrote: > Right now, I am > looking in the src code of libFLAC, (I am looking through stream_encoder.c > in libFLAC src code), but its really confusing to someone who just learned > what ./configure meant today. Well, configure is obfuscating, but that's not really the