similar to: GCC/clang compilation issues

> Oliver St?neberg wrote: > > > I finally got around to trying to update FLAC for the MAME/MESS > > project again. There were several issues I was able to fix and will > > submit patches later, but I hit one roadblock with GCC and clang: > > > > src/lib/libflac/libFLAC/stream_encoder.c:1696:43: error: cast from function call > > of type

> I don't know, its your build system and I haven't seen it, nor do > I have the time and motivation to look at it (unless of course you > were paying me for my time). I willing give my time to maintain > FLAC. I have not signed up to spend my time on your project. And I am willing to looking at FLAC and spent my time to fix compiler warnings to make it more portable and

> Oliver St?neberg wrote: > > > > > > Oliver St?neberg wrote: > > > > > > > I finally got around to trying to update FLAC for the MAME/MESS > > > > project again. There were several issues I was able to fix and will > > > > submit patches later, but I hit one roadblock with GCC and clang: > > > > > > >

Oliver St?neberg wrote: > > > Oliver St?neberg wrote: > > > > > I finally got around to trying to update FLAC for the MAME/MESS > > > project again. There were several issues I was able to fix and will > > > submit patches later, but I hit one roadblock with GCC and clang: > > > > > >

Oliver St?neberg wrote: > I finally got around to trying to update FLAC for the MAME/MESS > project again. There were several issues I was able to fix and will > submit patches later, but I hit one roadblock with GCC and clang: > > src/lib/libflac/libFLAC/stream_encoder.c:1696:43: error: cast from function call > of type 'double' to non-matching type

> Oliver St?neberg wrote: > > > Copying my report from sf.net: > > > > The source uses a mixture of "#ifdef HAVE_CONFIG_H" and "#if HAVE_CONFIG_H" > > checks. Judging from > > > > DEFS=-DHAVE_CONFIG_H > > > > in the configure I supposed it should be "#ifdef" in all cases. These incorrect > > checks cause

> Oliver St?neberg wrote: > > > This is simply fixed by putting those unused constants into the > > proper defines. I attached a patch against git 70b078c. > > Unfortunately it breaks x86_64 build (where FLAC__CPU_X86_64 is defined, and > FLAC__CPU_IA32 isn't). Maybe it's simpler to turn them into #defines such as > > #define

On Thu, Jun 19, 2014 at 03:30:22PM +0400, lvqcl wrote: > BTW, what can you say about the following place in stream_decoder.c > in read_subframe_lpc_() function: > > /*@@@@@@ technically not pessimistic enough, should be more like > if( (FLAC__uint64)order * ((((FLAC__uint64)1)<<bps)-1) * ((1<<subframe->qlp_coeff_precision)-1) < (((FLAC__uint64)-1)

Hi, after having some discussion of the FPU/SSE behavior on the sf.net bug tracker as well as having some other changes we made for the MAME/MESS project sitting around I thought about joining this list to make things easier. First one is the latest modification we had to make to compile with clang 3.4 x64. Here are the warnings the 1.2.1 source will give with it:

Copying my report from sf.net: The source uses a mixture of "#ifdef HAVE_CONFIG_H" and "#if HAVE_CONFIG_H" checks. Judging from DEFS=-DHAVE_CONFIG_H in the configure I supposed it should be "#ifdef" in all cases. These incorrect checks cause build errors since it tries to include the config.h on a custom configuration, that doesn't provide one. I can provide a

FYI, I have checked in a few interesting things. One is a speedup to the decoder (about 15% improvement in overall decode time). Another is a new interface to FLAC file metadata. If you're curious look at include/FLAC/metadata.h. It is basically a collection of object manipulation routines and iterators that make it pretty easy to add/edit/delete FLAC metadata in files efficiently. The

Hello, I just tried to compile libFLAC (using Borland C++ Builder 6 on Windows). The compilers yells at me on line 233 of libFLAC/lpc.c *(residual++) = *(data++) - (sum >> lp_quantization); --> data is const and cannot be modified Funny thing is, if data is declared: const FLAC__int32 *data instead of const FLAC__int32 data[] everything is ok. Is this a bug in my compiler, or

Hi all, I'm attempting to encode raw audio data using libFLAC++. My audio data is 16 bit, mono, 16000Hz. I set all the appropriate parameters on the encoder and then call init(). Everything appears to be ok. I don't know how to properly convert from char *data to the FLAC__int32 *[] requested by the process function. I think this is where my problem is. If I call process() like this:

On Thu, Aug 14, 2014 at 12:34 PM, lvqcl <lvqcl.mail at gmail.com> wrote: > Jose Pablo Carballo <jose.carballo at ridgerun.com> wrote: > >> - channels = 2; >> - bps = 16; >> + channels = ((unsigned)buffer[23] << 8) | buffer[22]; >> + bps = ((unsigned)buffer[35] << 8) | buffer[34]; >> total_samples = (((((((unsigned)buffer[43] << 8)

There are following functions in bitreader.c: FLAC__bool FLAC__bitreader_read_unary_unsigned(FLAC__BitReader *br, unsigned *val); FLAC__bool FLAC__bitreader_read_rice_signed(FLAC__BitReader *br, int *val, unsigned parameter); FLAC__bool FLAC__bitreader_read_rice_signed_block(FLAC__BitReader *br, int vals[], unsigned nvals, unsigned parameter); * function FLAC__bitreader_read_rice_signed():

Hi, In the last days I've been taking as reference the example found in examples/c/encode/file/main.c. With it I've been able to encode a 2ch, 16 bps, 44100 sample rate input WAV file to a FLAC file. Now I've been trying to modify this example to encode a 2ch, 24 bps, 96000 sample rate WAV file. I have to say I'm a bit lost on how I should read the input file in this case, and

On Tue, Jan 13, 2004 at 02:04:48PM -0800, Josh Coalson wrote: > --- Denis Chatelain <listes@octopodus.com> wrote: > > Hello, > > > > > > I just tried to compile libFLAC (using Borland C++ Builder 6 on > > Windows). > > > > The compilers yells at me on line 233 of libFLAC/lpc.c > > > > *(residual++) = *(data++) - (sum >>

In the precompute_partition_info_sums_ function, instead of selecting 64-bit accumulator when the signal bps is larger than 16, revert to the original approach based on partition size, but make room for few extra bits to not overflow with unusual signals where the average residual magnitude may be larger than bps. It slightly improves the performance with standard encoding levels and 16-bit files

Erik de Castro Lopo wrote: > Well FLAC__int32 is just a 32 bit integer and on all the platforms/ > architecures/compilers that FLAC supports FLAC__int32 and int are > the same. > > Personally I think the FLAC__xxxx stuff should go, to be replaced with > C standard int32_t, uint32_t, int16_t etc, at least for internal code. > I am slowly doing that when I touch code. > >

Erik de Castro Lopo <mle+la <at> mega-nerd.com> writes: > > Collin wrote: > > > Has anyone encountered a similar problem, or are there any known issues that > > could explain this? > > No known issues of this kind, but I would like to see a repeatable test > case so I can investigate further. > > Cheers, > Erik It turns out it was an error