search for: flac__stream_decoder_process_single

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

--- 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 that actually, there's a little explanation here: http://flac.sourcefor...

...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 valid frame? > Another solution might be to 'just try again' somewhere else > when seeking fails, but maybe there are good reasons not to do > so? The decoder might get stuck in a loop? I think that would be a reasonable solution. In one iterati...

...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 issue: When calling FLAC__stream_decoder_process_single() the error callback is triggered with the error FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER (the error callback is from line 1806 of stream_decoder.c in read_frame_). One thing I noticed is that FLAC__stream_decoder_process_single() still returns TRUE when our read callback returns FLAC__STREAM_...

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 one because it wasn't sent to the mailing...

...rame, const FLAC__int32 * const buffer[], void *callback_param ); /// \brief error callback function of decoder void decoderErrorCallback(const FLAC__StreamDecoder *decoder, FLAC__StreamDecoderErrorStatus status, void *callback_param ); When I call following statement, *// decode data* *if(!FLAC__stream_decoder_process_single(m_decoder))* * return;* * * firstly, read callback is called. In read callback function, I just use memory copy process. *// copy buffer array to m_pile_array* *if(input_pile_size > 0) {* * memcpy(input_pile_array, buffer, input_pile_size);* * input_pile_size = 0;* * * * * * return FLAC__STREAM...

Hello, I have a program that is given a random file and needs to determine whether it is Vorbis or FLAC. For Vorbis, there are various places where I can infer that I have a bad stream. But for FLAC, when I call either FLAC__stream_decoder_process_until_end_of_metadata or FLAC__stream_decoder_process_single, it searches the entire file before giving up. I'd like it to stop searching as soon as it loses sync, or find some better way to detect the file type without scanning the whole file. Any tips on the best way to do that? Thanks, Shayne Wissler

...ote: > > 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 valid frame? > I'm not sure whether we mean the same thing, but I think the problem is that seek_to_absolute_sample_ calls FLAC__stream_decoder_process_single, which calls read_frame_, which calls read_subframe_, which calls either read_subframe_fixed_ o...

...> 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 issue: > > When calling FLAC__stream_decoder_process_single() the error callback is > triggered with the error FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER > (the error callback is from line 1806 of stream_decoder.c in > read_frame_). One thing I noticed is that > FLAC__stream_decoder_process_single() still returns TRUE when our read > callb...

...which the CRC checks out, the whole frame is decoded to validate that a frame is correct. The bogus header might trigger the sanity checks that were made to fail by the CVEs, thereby the seek fails. A fix for this might be not decoding a frame fully, (by making the /*do_full_decode=*/true in FLAC__stream_decoder_process_single conditionally dependent on decoder->private_->is_seeking) but instead implement more sanity checks. For example, it could be checked whether the sample rate, blocksize, number of channels and sample size in the frame header match with those in the stream info, and whether the sample or f...

..._param > ); > > /// \brief error callback function of decoder > void decoderErrorCallback(const FLAC__StreamDecoder *decoder, > FLAC__StreamDecoderErrorStatus status, > void *callback_param > ); > > When I call following statement, > > *// decode data* > *if(!FLAC__stream_decoder_process_single(m_decoder))* > * return;* > * > * > firstly, read callback is called. In read callback function, I just use > memory copy process. > > *// copy buffer array to m_pile_array* > *if(input_pile_size > 0) {* > * memcpy(input_pile_array, buffer, input_pile_size);* > * in...

Hi, I am developing an audio network system and using boost, OpenAL and FLAC library in C/C++. I can stream raw audio data over network but I want to encode audio before streaming in current PC and decode after streaming in other PC because of bandwidth limit. I run your sample codes, encode.c and decode.c, about file encode / decode. Then, I run streaming encode / decode with two different

.... 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 issue: > > > > When calling FLAC__stream_decoder_process_single() the error > callback is > > triggered with the error > FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER > > (the error callback is from line 1806 of stream_decoder.c in > > read_frame_). One thing I noticed is that > > FLAC__stream_decoder_process_single() still returns...

...ite the decoded PCM to the sound driver for playing it. I am looking to make a very simple application which uses the libFLAC.lib static library and calls the following functions to do this task: - FLAC__stream_decoder_new - FLAC__stream_decoder_set_md5_checking - FLAC__stream_decoder_init_FILE - FLAC__stream_decoder_process_single (inside a while<no. of frames> loop) - FLAC__stream_decoder_delete All of this happens without resorting to callbacks. Even though it seems from the documentation that this is a possibility with the given APIs, I am not able to make it work. Does anyone have any ideas about how I should g...

...hange its behaviour. The user code that uses those functions might look like this: void foo() { FLAC__uint64 offset; FLAC__stream_decoder_seek_prepare(decoder, target_sample, stream_length); for (;;) { FLAC__stream_decoder_seek(decoder, &offset); my_seek(file, offset); FLAC__stream_decoder_process_single(decoder); if /* write() callback was called - seek has been completed */ { puts("seek OK"); break; } } } I always like to control the full workflow of my program, and by having those seek functions I'm sure no file I/O is performed via callbacks. Ultimately, I w...

...wrote: > I have a program that is given a random file and needs to determine > whether it is Vorbis or FLAC. For Vorbis, there are various places > where I can infer that I have a bad stream. But for FLAC, when I call > either FLAC__stream_decoder_process_until_end_of_metadata or > FLAC__stream_decoder_process_single, it searches the entire file > before giving up. I'd like it to stop searching as soon as it loses > sync, or find some better way to detect the file type without scanning > the whole file. Any tips on the best way to do that? Perhaps I have misunderstood your problem, but is this not...

...805ba58, channel=1, bps=1) at stream_decoder.c:1751 x = 22 wasted_bits = 0 #4 0x4021e190 in read_frame_ (decoder=0x805ba58, got_a_frame=0xbffff360) at stream_decoder.c:1353 bps = 4294966980 channel = 1 i = 4294966980 mid = 1 side = 4608 left = 8 frame_crc = 4608 x = 248 #5 0x4021c6e0 in FLAC__stream_decoder_process_single (decoder=0x805ba58) at stream_decoder.c:596 got_a_frame = 0 #6 0x08053774 in EasyFLAC__process_single (decoder=0x805ba30) at ../../ogg123/easyflac.c:356 No locals. #7 0x08052690 in flac_init (source=0x805aa60, ogg123_opts=0x8059d60, audio_fmt=0xbffff3e0, callbacks=0xbffff408, callback_arg=0x407e...

Erik de Castro Lopo wrote: > I think I have an alternative fix for the CVE which should not break > seeking. I'm working on getting an copy of the file with which to test. Patch applied and pushed. commit b4b2910bdca010808ccf2799f55562fa91f4347b Author: Erik de Castro Lopo <erikd at mega-nerd.com> Date: Wed Dec 10 18:54:16 2014 +1100

...e incomplete. The LOST SYNC error is usually seen with corrupted blocks, so I think the blocks are incomplete or, less likely, corrupt. There are a few ways to counter this. The easy way is to add a little latency to be sure at least one complete block is in the receiving buffer. So, only call FLAC__stream_decoder_process_single() if the buffer is filled with enough data. If you want the lowest latency possible you could force a small block size or let the encoding PC signal the decoding PC when a block is finished, so the decoding process can be sure there is a full block in the buffer. Oh, and you might take a look...