similar to: Bug in bitreader for short reads?

fixed in cvs http://sourceforge.net/tracker/?func=detail&aid=2490454&group_id=13478&atid=113478 --- On Mon, 6/1/09, Gilles Boccon-Gibod <bok at bok.net> wrote: > From: Gilles Boccon-Gibod <bok at bok.net> > Subject: [Flac-dev] Bug in bitreader for short reads? > To: flac-dev at xiph.org > Date: Monday, June 1, 2009, 10:16 AM > It seems that the bitstream

you're right, this is fixed in CVS, see http://sourceforge.net/tracker/?func=detail&aid=2490454&group_id=13478&atid=113478 --- On Sun, 5/31/09, Gilles Boccon-Gibod <bok at bok.net> wrote: > From: Gilles Boccon-Gibod <bok at bok.net> > Subject: [Flac] Bug in bitreader for short reads? > To: flac at xiph.org > Date: Sunday, May 31, 2009, 10:40 PM > It

It seems that the bitstream reader is not working as it should (verified in version 1.2.0 and 1.2.1). The problem is as follows: if the data read by the read callback is not a multiple of 4, the bit reader will end up in a very bad state, where the bits_consumed field will grow without ever being reset to 0, and that causes everything to fail. This is not a case that's encountered very

Hi, I've trying to decode a FLAC audio stream. I have a reader which sends raw byte data to my FLAC wrapper class. Only once the decode function below returns, the reader will send new data. Hence I want to decode until the stream is empty, but I will add new data to the stream once it is empty. *void **MyFlacCoder::**decode(char *data, int bytes) { mBuffer = input;

Thank you so much for polite help Martijn. Allison, My read callback function is just ; * /// \brief read callback function of decoder* * FLAC__StreamDecoderReadStatus decoderReadCallback( const FLAC__StreamDecoder *decoder, FLAC__byte buffer[], size_t *bytes, void *callback_param)* * {* * // mutex lock* * m_mutex.lock();* * * * // copy buffer array to m_pile_array* * if(input_pile_size > 0)

First, Thank you for your answers. I using the following code to try simply decode a flac file and write the decoded data raw PCM file. The resulting file is just noise and pops, so is the decoded data in a different format than PCM? struct flacData { FILE *inputFile; FILE *outputFile; char *filename; }; FLAC__StreamDecoderReadStatus flac_DecoderReadCallback(const FLAC__StreamDecoder

Thanks for that email. The one lihe change I made is this : from #define FLAC__MAX_RICE_PARTITION_ORDER (15u) to #define FLAC__MAX_RICE_PARTITION_ORDER (6u) and that seemed to make decoder_new() happy, but it's promptly crashing after making a call to the read callback (below), then to the meta callback. The meta callback did nothing but print a string and return. I removed it, and

Hi again, I can not solve problem. I want to mention my source code, so you may answer easily. This is decoder init stream function. *FLAC__stream_decoder_init_stream(m_decoder, decoderReadCallback, NULL, NULL, NULL, NULL, decoderWriteCallback, NULL, decoderErrorCallback, input_pile_array);* * * Then, callbacks * * /// \brief read callback function of decoder FLAC__StreamDecoderReadStatus

Martijn, I don't use any metadata when encoding and decoding. When I call *FLAC__StreamDecoderStateString[FLAC__stream_decoder_get_state(m_decoder)] * * * it returns FLAC__STREAM_DECODER_SEARCH_FOR_METADATA enum value. Is it an error ? 2013/7/2 Burak Or?un ?zkablan <borcunozkablan at gmail.com> > Hi again, > > I can not solve problem. I want to mention my source code, so

I've upgraded to FLAC 1.1.3, and now I have some streams where seek does not work anymore, but they used to work before. After a bit of debugging, it looks like those streams (created a long time ago with an old version of FLAC) have a seek table where all the entries have a stream offset of 0. The result is that in the function seek_to_absolute_sample_, on line 3076 (file

On Sun, Dec 20, 2015 at 01:30:57PM +0300, lvqcl wrote: > Erik de Castro Lopo wrote: > > > The think in and ideal world we would a: > > > > * Make it work correctly FLAC__BYTES_PER_WORD == 8 and compare the performance > > with FLAC__BYTES_PER_WORD == 4. > > * If there is an statistically measurable performance, keep it, otherwise > > remove the

Erik de Castro Lopo wrote: > The think in and ideal world we would a: > > * Make it work correctly FLAC__BYTES_PER_WORD == 8 and compare the performance > with FLAC__BYTES_PER_WORD == 4. > * If there is an statistically measurable performance, keep it, otherwise > remove the FLAC__BYTES_PER_WORD == 8 code all together. I'll try to do it, but I don't have a deep

There are preprocessor definitions in bitreader.c and bitwriter.c: /* Things should be fastest when this matches the machine word size */ /* WATCHOUT: if you change this you must also change the following #defines down to SWAP_BE_WORD_TO_HOST below to match */ /* WATCHOUT: there are a few places where the code will not work unless uint32_t is >= 32 bits wide */ #define

Hi all, I've used the llvmgcc to compile a quite simple bit of c-code: >short addtest(short a, short b) >{ > return a+b; >} When I'm feeding llc (llvm-2.1-version) with the resulting bytecode, it fails with this error: llc: BitcodeReader.cpp:1040: bool llvm::BitcodeReader::ParseModule(const std::string&): Assertion `Func->getFunctionType()->getParamAttrs() ==

Hi there, problem is solved, thanks go out to Duncan Sands. >It sounds like the version of llvm-gcc doesn't match the version of llc. >What does the llvm assembler look like (i.e. what llvm-dis gives for the >bitcode)? > >D. The bitcode was indeed produced with the gcc frontend for llvm-2.2 and used with llc from llvm-2.1. Thanks for helping me out! Matthias Heine

Fixes typos in comments in these two files. -------------- next part -------------- A non-text attachment was scrubbed... Name: typo.patch Type: application/octet-stream Size: 1602 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20140212/f8f231cf/attachment.obj

The read callback can take as long as it wants (it's blocking, after all). It's almost definitely something wrong with your read callback code. Without the full source, it's hard to know exactly what. A few guesses, in no particular order. 1) Maybe you are reading in a loop and forgetting to increment the byte buffer pointer (continuously writing to the beginning of the buffer) 2)

Yes, I have tried plain wav data with file and stream functions of decoder and encoder. They work succesfully. You're right about FLAC can't find the first block in stream, because I didn't add any metadata in stream. The documentation of FLAC says that metadata callback function is optional for stream function of decoder, so I didn't need adding metadata. Actually, I am sure

On Fri, Mar 14, 2008 at 07:36:31PM +0100, Miroslav Lichvar wrote: > attached are patches that improve decoding speed a bit. The first > patch improves the bit scan macro used for decoding unary values, the > second one adds a GCC inline assembly for bswap and the third patch > replaces the read_rice_block function. The third patch has a bug causing reading past input buffer, attaching

For some reason, I didn't get Brians email, but I noticed it was replied to, so I'll copy from the archive > Is there an overview - in plain English - summarizing the API changes? No, not yet, as it isn't final yet. However, for the API changes, one only has to look at the header files, not the actual source files. > Without diving in to the source changes, my first question