similar to: The flacdiff and flactimer utils

Here you are: soa2ii at thor /mnt/files/music/Slime/Alle gegen Alle $ metaflac --list 02\ St?rtebecker.flac METADATA block #0 type: 0 (STREAMINFO) is last: false length: 34 minimum blocksize: 4608 samples maximum blocksize: 4608 samples minimum framesize: 14 bytes maximum framesize: 15637 bytes sample_rate: 44100 Hz channels: 2 bits-per-sample: 16 total samples: 5857656

Hello, This is a patch to allow building of the project using MSYS, MinGW, and MinGW-w64 with the following invocation: make -f Makefile.lite libFLAC libFLAC++ flac metaflac test_libs_common test_libFLAC test_libFLAC++ test_grabbag test_seeking test_streams utils examples This patch addresses eight points: 1. `uname -p` in MSYS returns "unknown" so we must use `gcc -dumpmachine`

Hello, This is a patch to allow building of the project using MSYS, MinGW, and MinGW-w64 with the following invocation: make -f Makefile.lite libFLAC libFLAC++ flac metaflac test_libs_common test_libFLAC test_libFLAC++ test_grabbag test_seeking test_streams utils examples This patch addresses eight points: 1. `uname -p` in MSYS returns "unknown" so we must use `gcc -dumpmachine`

Hello, I'm runing Debian Stable linux with flac version 1.2.1. Weekly, I run a cron job to test all my flac files for problems using the -ts options. I have several computers storing the same information over various raid arrays, and occasionally I do find the odd file that has had problems and can then change hard drives and re-synchronize. Anyways, I have recently encountered a couple of

Fixes are similar to parts of the following commits: <https://git.xiph.org/?p=flac.git;a=commitdiff;h=2199d086921eb37d249cae0731f334556ec6209d#patch7> <https://git.xiph.org/?p=flac.git;a=commitdiff;h=b9574fe58950d38c96399161421484935249822a#patch3> -------------- next part -------------- A non-text attachment was scrubbed... Name: flacdiff.patch Type: application/octet-stream Size: 569

--- COPYING.GPL | 43 +++++++++++----------- doc/Makefile.am | 6 +-- doc/Makefile.lite | 6 +-- examples/c/decode/file/Makefile.am | 6 +-- examples/c/decode/file/Makefile.lite | 6 +-- examples/c/decode/file/main.c | 6 +--

On 1.4.2013 22:37, Erik de Castro Lopo wrote: > Janne Hyv?rinen wrote: > >> Zip with random patches: >> >> flac_mac: fixes some missing parameters from safe string handling >> changes in flac_mac's main.c >> flac_mac_project: adds flac's include dir for the project so new >> functions can be found >> progress_display: flac testing progress

So, let's provide some information then :-) ---------------------------------------------------------------------------------------------- soa2ii at thor /mnt/files/music/Slime/Alle gegen Alle $ flac -aF 02\ St?rtebecker.flac flac 1.2.1, Copyright (C) 2000,2001,2002,2003,2004,2005,2006,2007 Josh Coalson flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome

--- Ingo Ralf Blum <ingoralfblum@gmx.de> wrote: > I have a problem when I try to open a file, which is not a FLAC file. > When I > open a non-flac file with the stream decoder API, one of the first > things called > is FLAC__stream_decoder_process_metadata, which itself calls > stream_decoder_find_metadata_. Unfortunately the non-flac file > contains some > content,

Hi, I have a problem when I try to open a file, which is not a FLAC file. When I open a non-flac file with the stream decoder API, one of the first things called is FLAC__stream_decoder_process_metadata, which itself calls stream_decoder_find_metadata_. Unfortunately the non-flac file contains some content, which leads to the state set to FLAC__STREAM_DECODER_READ_FRAME. However in

To avoid crash caused by an unbound LPC decoding when predictor order is larger than blocksize, the sanity check needs to be moved to the subframe decoding functions. --- src/libFLAC/stream_decoder.c | 30 ++++++++++++------------------ 1 file changed, 12 insertions(+), 18 deletions(-) diff --git a/src/libFLAC/stream_decoder.c b/src/libFLAC/stream_decoder.c index d13b23b..211b4db 100644 ---

All C and C++ files must include config.h --- src/libFLAC++/metadata.cpp | 4 ++++ src/libFLAC++/stream_decoder.cpp | 4 ++++ src/libFLAC++/stream_encoder.cpp | 4 ++++ src/plugin_xmms/charset.c | 4 ++++ src/plugin_xmms/configure.c | 4 ++++ src/plugin_xmms/fileinfo.c | 4 ++++ src/plugin_xmms/http.c | 4 ++++

On 06.11.2008 22:16, LRN wrote: > In stream_decoder.c function find_metadata_() checks whether a file is > valid or not. There are 4 cases it recognizes: > 1) file begins with 'fLaC' > 2) file begins with ID3 (skipped), followed by 'fLaC' > 3) file may begin with 11111111 111110?? sync code (or 11111111111110, > depends on endianess i suppose). That is - a raw

Hello FLACers, I'm just getting started and am using the test suite as a beginning point. I have combined the stream encoder and decoder tests. The test encoder uses a 1024 array of integers (initialized 0-7 over and over again). I take this array and feed it into the encoder and save the resulting array from the write callback. I then feed that to the decoder and save the resulting array it

Hello! I'm using the seekable stream decoder API of libFLAC 1.02 and I think that I found a possible bug in process_metadata(). The problem is as follows: I have a file which isn't a FLAC sample (it's actually an ACE archive) where process_metadata() returns TRUE. And even worse, the metadataCallback() is never called (which means process_metadata() succeeds, although no metadata is

In stream_decoder.c function find_metadata_() checks whether a file is valid or not. There are 4 cases it recognizes: 1) file begins with 'fLaC' 2) file begins with ID3 (skipped), followed by 'fLaC' 3) file may begin with 11111111 111110?? sync code (or 11111111111110, depends on endianess i suppose). That is - a raw file with FLAC frames, without header (right?). 4) file begins

Came across another error that might help! Using flac -t I get: 251_A.wav: *** Got error code 0:FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC 251_A.wav: *** Got error code 0:FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC Thanks, Matthew On Feb 6, 2008 3:19 AM, Matthew Davis <zasdarq@gmail.com> wrote: > Thank you for the reply! I know that my system can play flac files, I've >

Open src/flac/decode.c, find write_callback() function and add return FLAC__STREAM_DECODER_WRITE_STATUS_ABORT; to the beginning of the function. Decoding will fail with the following message: test.flac: ERROR while decoding data state = FLAC__STREAM_DECODER_READ_FRAME As you can see, decoder state isn't quite correct. One of the ways to fix this is in the attached

Erik de Castro Lopo wrote: > That's a really good question. Haven't was already dropped support for > MSVC6? If so, we should drop this #ifdef hackery. Can test this without > the hackery for versions of MSVC > 6? I don't have VC 2002/2003, but the oldest Visual Studio that FLAC supports is MSVS 2005 anyway. It can compile FLAC__uint64 -> FLAC__double conversion

Miroslav Lichvar wrote: > I'm trying to figure out how this one works. It seems the problem is > integer underflow in the "frame.header.blocksize-order" expression > used in read_subframe_fixed_() and read_subframe_lpc_() to get the > number of encoded samples, which causes a buffer overflow in the > LPC/fixed subframe decoding. > > The fix prevents that by