similar to: Making the FLAC decoder work without callbacks

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

Sorry, I am newbie. Sample codes are from https://github.com/oneman/libflac/tree/master/examples/cpp. I used FLAC__stream_decoder_process_single function but it still gives exception. Maybe I could not control read callback, you're right. I will check it and write result in this thread. Thanks for help. 2013/7/1 Martijn van Beurden <mvanb1 at gmail.com> > I'll top-post this

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'll top-post this one because it wasn't sent to the mailinglist but to me. Please reply to list next time. I assume you mean the main.c files in the encode and decode directory under examples. I can't really determine the root cause of your problem with this information, but I think you're trying to feed the decoder blocks that are incomplete. The LOST SYNC error is usually

--- Reza Naima <reza@reza.net> wrote: > I've cross-compiled flac for the armv4l processor (rio receiver), and > > i'm trying to start up a decode thread : > > #include <FLAC/stream_decoder.h> > .... > FLAC__StreamDecoder *flac = NULL; > flac = FLAC__stream_decoder_new(); > if (flac == NULL) { >

I've cross-compiled flac for the armv4l processor (rio receiver), and i'm trying to start up a decode thread : #include <FLAC/stream_decoder.h> .... FLAC__StreamDecoder *flac = NULL; flac = FLAC__stream_decoder_new(); if (flac == NULL) { printf("[DECODE] Unable to initalize flac object\n");

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, I'm writing a simple flac playing program, and I've basically modified the example C decoder code to use libao. The example code works just fine, but when I use libao, after calling FLAC__stream_decoder_process_until_end_of_stream(), decoder points to an inaccessible area of memory (0x2). This invariable causes a segmentation fault when anything else thereafter uses the decoder (i.e.

Hi all, If I have code that does this: while (FLAC__stream_decoder_process_single (decoder)) /* Do something. */ ; I get an infinite loop. Shouldn't FLAC__stream_decoder_process_single return false if it gets to FLAC__STREAM_DECODER_END_OF_STREAM? If so, here's a patch. Cheers, Erik ------------------8<------------------8<------------------8<------------------

Josh Coalson wrote: > > I get an infinite loop. Shouldn't FLAC__stream_decoder_process_single > > return false if it gets to FLAC__STREAM_DECODER_END_OF_STREAM? > > it supposed to be like that actually, there's a little explanation > here: > > http://flac.sourceforge.net/api/group__flac__stream__decoder.html#ga45 Ok, I've read that and I agree that the

--- Erik de Castro Lopo <erikd-flac@mega-nerd.com> wrote: > Hi all, > > If I have code that does this: > > while (FLAC__stream_decoder_process_single (decoder)) > /* Do something. */ ; > > I get an infinite loop. Shouldn't FLAC__stream_decoder_process_single > return false if it gets to FLAC__STREAM_DECODER_END_OF_STREAM? it supposed to be like

Hello, I am currently learning the FLAC C API and had the code working with FLAC__stream_decoder_init_file. However, since I'd need the Unicode filename support, I tried _wfopen_s in combination with FLAC__stream_decoder_init_FILE, however I get a runtime crash as sonn as I call FLAC__stream_decoder_process_until_end_of_stream. The same code (partially taken from the examples) is working

During my current dealings with the FLAC library I think I discovered a memory leak. After an encoder stream has finish()'ed, I believe you are supposed to use it again by calling init(). However, when verification is enabled, the init() routine will create a new stream decoder (to verify the data) without deleting (or reusing) the existing one. A small program demonstrating this is pasted

This has the advantage of being more efficient than the included routines and allows distros to centralize crypto mainteniance on a few libraries. --- configure.ac | 4 +- m4/ax_check_openssl.m4 | 124 +++++++++++++++++++++++++++++++++++++ src/libFLAC/Makefile.am | 2 +- src/libFLAC/include/private/md5.h | 8 ++- src/libFLAC/md5.c

Ivailo Karamanolev wrote: > I am currently learning the FLAC C API and had the code working with > FLAC__stream_decoder_init_file. However, since I'd need the Unicode filename > support, I tried _wfopen_s in combination with > FLAC__stream_decoder_init_FILE, however I get a runtime crash as sonn as I > call FLAC__stream_decoder_process_until_end_of_stream. The same code >

2014-12-11 14:34 GMT+01:00 Miroslav Lichvar <mlichvar at redhat.com>: > > On Thu, Dec 11, 2014 at 11:12:25AM +0100, Martijn van Beurden wrote: > > Op 11-12-14 om 10:53 schreef Martijn van Beurden: > > > Op 11-12-14 om 10:05 schreef Miroslav Lichvar: > > >> but I'd rather see the real seeking bug fixed instead > > > > > > I think I might

Ivailo - FILE objects are internal to the C runtime library, they are not system objects like HANDLEs (windows) or file descriptors (unix). This means that if libFLAC has linked against a different C runtime library than your application, then the two FILE objects are incompatible. This isn't just a Windows specific issue either - if libFLAC was compiled against libc and your application

On Tue, 2006-07-25 at 06:37 +0200, Josh Green wrote: > A user of CRAM (http://swami.sourceforge.net/cram.php) sent in a bug > report related to decoding of CRAM files. This issue occurs with > flac-1.1.2 but not previous versions (such as flac-1.1.1). Note that > the same file is used for this test (hopefully ruling out any issue with > the encoder). > > Details of the

On Thu, Dec 11, 2014 at 11:12:25AM +0100, Martijn van Beurden wrote: > Op 11-12-14 om 10:53 schreef Martijn van Beurden: > > Op 11-12-14 om 10:05 schreef Miroslav Lichvar: > >> but I'd rather see the real seeking bug fixed instead > > > > I think I might have a fix [...] So the problem is that FLAC__stream_decoder_process_single returns error before it finds a

I managed to get around it. I used the stream functions and provided my own callbacks for reading and writing. What's strange is that what I've done is just copied the contents of read/write/seek/tell/eof callbacks from the sources to my application and it works just fine, no glitches. When I use the build-in implementation, it just crashes without any reason. It's not a problem to