search for: flac__int32

I think I've gotten FLAC__lpc_restore_signal() about as good as I'm going to get it. Here's what I have: -a new file, lpc_asm.s, which has the assembly routines -changes to cpu.h, cpu.c, and stream_decoder.c to enable them -changes to configure.in to support the new cpu stuff -a preliminary Makefile.am -maybe something else I'm forgetting Now automake complains that configure.in

...ter); FLAC__bool FLAC__bitreader_read_rice_signed_block(FLAC__BitReader *br, int vals[], unsigned nvals, unsigned parameter); * function FLAC__bitreader_read_rice_signed(): unused * function FLAC__bitreader_read_rice_signed_block(): called from read_residual_partitioned_rice_() with a pointer to FLAC__int32, not to int (as its 2nd parameter). * function FLAC__bitreader_read_unary_unsigned(): sometimes it is called with a pointer to unsigned as its 2nd parameter, sometimes with a pointer to FLAC__uint32. Is it Ok to pass FLAC__int32* in a function that expects int* ? (the same question for FLAC__uin...

...====== RCS file: /cvsroot/flac/flac/src/libFLAC/stream_decoder.c,v retrieving revision 1.87 diff -c -r1.87 stream_decoder.c *** stream_decoder.c 20 May 2003 00:01:50 -0000 1.87 --- stream_decoder.c 25 Jul 2004 23:17:39 -0000 *************** *** 101,110 **** void (*local_lpc_restore_signal)(const FLAC__int32 residual[], unsigned data_len, const FLAC__int32 qlp_coeff[], unsigned order, int lp_quantization, FLAC__int32 data[]); void (*local_lpc_restore_signal_64bit)(const FLAC__int32 residual[], unsigned data_len, const FLAC__int32 qlp_coeff[], unsigned order, int lp_quantization, FLAC__int32 data[]);...

...lude/private/lpc.h @@ -61,6 +61,7 @@ void FLAC__lpc_compute_autocorrelation_asm_ia32_3dnow(const FLAC__real data[], unsigned data_len, unsigned lag, FLAC__real autoc[]); #endif #endif +#endif /* * FLAC__lpc_compute_lp_coefficients() @@ -146,17 +147,16 @@ void FLAC__lpc_restore_signal(const FLAC__int32 residual[], unsigned data_len, const FLAC__int32 qlp_coeff[], unsigned order, int lp_quantization, FLAC__int32 data[]); void FLAC__lpc_restore_signal_wide(const FLAC__int32 residual[], unsigned data_len, const FLAC__int32 qlp_coeff[], unsigned order, int lp_quantization, FLAC__int32 data[]); #ifn...

...e 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 'FLAC__int32' (aka 'int') [-Werror,-Wbad-function-cast] ...FLAC__int32 tukey_parts = (FLAC__int32)strtod(specification+14, 0); ^~~~~~~~~~~~~~~~~~~~~~~~~~~ src/lib/libflac/libFLAC/stream_encoder.c:1717:43: error: cast from function call of typ...

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

...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 'FLAC__int32' (aka 'int') > > [-Werror,-Wbad-function-cast] > > ...FLAC__int32 tukey_parts = (FLAC__int32)strtod(specification+14, 0); > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~ > > src/lib/libflac/libFLAC/stream_encoder.c:1717:43: err...

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 a personnal lack of understanding of the difference in C between *data and data[] ? Will changing const FLAC__int32 data[] to const FLAC__int32 *data will ruine everything ? Denis

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: FLAC__int32 *samplesArray[1] = { (FLAC__int32 *)data }; // data size if 4096 bytes if (!process(samplesArray, 1024)) die("return false"); it appears to encode ok, but when I pl...

...number due to WAVE size limitations */ -static FLAC__byte buffer[READSIZE/*samples*/ * 2/*bytes_per_sample*/ * 2/*channels*/]; /* we read the WAVE data into here */ +static FLAC__byte buffer[READSIZE/*samples*/ * 3/*bytes_per_sample*/ * 2/*channels*/]; /* we read the WAVE data into here */ static FLAC__int32 pcm[READSIZE/*samples*/ * 2/*channels*/]; int main(int argc, char *argv[]) @@ -71,13 +71,15 @@ memcmp(buffer+8, "WAVEfmt \020\000\000\000\001\000\002\000", 16) || memcmp(buffer+32, "\004\000\020\000data", 8) ) { + /* Ignoring for now as I work towards supporting 24bps fi...

...9;m having trouble with: http://archzoom.sourcecontrol.net/archzoom.cgi/eric@petta-tech.com--2005a-normalperson/flac--ipod--1.1.0--patch-19/src/libFLAC/arm/lpc_asm.s -- Eric Wong --- orig/src/libFLAC/lpc.c +++ mod/src/libFLAC/lpc.c @@ -293,6 +293,209 @@ void FLAC__lpc_restore_signal(const FLAC__int32 residual[], unsigned data_len, const FLAC__int32 qlp_coeff[], unsigned order, int lp_quantization, FLAC__int32 data[]) { + register const FLAC__int32 *qlp0 = &qlp_coeff[(order-1)]; + register FLAC__int32 sum; + register const FLAC__int32 *history, *qlp; + + history = &data[(-order)]; + + s...

...er due to WAVE size limitations */ -static FLAC__byte buffer[READSIZE/*samples*/ * 2/*bytes_per_sample*/ * 2/*channels*/]; /* we read the WAVE data into here */ +static FLAC__byte buffer[READSIZE/*samples*/ * BPS/8 /*bytes_per_sample*/ * 2/*channels*/]; /* we read the WAVE data into here */ static FLAC__int32 pcm[READSIZE/*samples*/ * 2/*channels*/]; int main(int argc, char *argv[]) @@ -73,14 +75,18 @@ int main(int argc, char *argv[]) memcmp(buffer+8, "WAVEfmt \020\000\000\000\001\000\002\000", 16) || memcmp(buffer+32, "\004\000\020\000data", 8) ) { +#if BPS == 16 fprintf(s...

lvqcl wrote: > Is it Ok to pass FLAC__int32* in a function that expects int* ? 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. As for pointers, all pointers are the same until you try an increment them. If you have some type, lets call it somety...

...; 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 a personnal lack of understanding of > > the difference in C between *data and data[] ? > > hmmm, not sure what the standard say...

...> 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 'FLAC__int32' (aka 'int') > [-Werror,-Wbad-function-cast] > ...FLAC__int32 tukey_parts = (FLAC__int32)strtod(specification+14, 0); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~ > src/lib/libflac/libFLAC/stream_encoder.c:1717:43: error: cast from functi...

...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 'FLAC__int32' (aka 'int') > > > [-Werror,-Wbad-function-cast] > > > ...FLAC__int32 tukey_parts = (FLAC__int32)strtod(specification+14, 0); > > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > src/lib/libflac/libFLAC/stream_en...

...9.5 ICC 64-bit: 81.2 VS10 64-bit: 81.1 VS12 64-bit: 83.3 According to a profiler, FLAC__lpc_compute_residual_from_qlp_coefficients_wide() is one of the most CPU consuming. I added __restrict keyword to its parameters. before it was: void FLAC__lpc_compute_residual_from_qlp_coefficients_wide(const FLAC__int32 *data, unsigned data_len, const FLAC__int32 qlp_coeff[], unsigned order, int lp_quantization, FLAC__int32 residual[]) after: void FLAC__lpc_compute_residual_from_qlp_coefficients_wide(const FLAC__int32 * __restrict data, unsigned data_len, const FLAC__int32 * __restrict qlp_coeff, un...

...k It turns out it was an error on my part; sorry for the trouble. I misunderstood the format libflac was expecting my samples in. I found the wording in the documentation very confusing. My audio file has 2 channels and 16-bit samples, so I have to pull out each individual sample, push it into a FLAC__int32, and fix endian-ness before I can pass it to libflac. The documentation made me think that libflac just wanted me to shove my 2-byte sample into a FLAC__int32. I wasn't aware that it wanted me to extend the sign, as well.

lvqcl wrote: > Erik de Castro Lopo wrote: > > >> FLAC__int16 s16buffer[FLAC__MAX_BLOCK_SIZE * FLAC__MAX_CHANNELS * sizeof(FLAC__int32)/sizeof(FLAC__int16)]; > >> > >> instead of > >> > >> FLAC__int16 s16buffer[FLAC__MAX_BLOCK_SIZE * FLAC__MAX_CHANNELS * sizeof(FLAC__int16)]; > > > > Really? Would you also write this? : > > > > FLAC__int32 s32buffer[FLAC__MAX_BLOCK_SIZE *...

Hi, I was doing some speed and compression comparisons with various apodization/windowing functions, and found out that the definitions for the bartlett and bartlett_hann window in the FLAC codebase have been wrong since their introduction. The attached patch fixes that. Furthermore, I found some peculiar behaviour of the gauss apodization that seems to expose bug. Using different windows