similar to: PATCH: MSVC and M_LN2

This patch adds support for other compilers and systems including MSVC, Intel C compiler etc.. --- src/libFLAC/bitmath.c | 48 ------------- src/libFLAC/bitreader.c | 54 ++------------- src/libFLAC/include/private/bitmath.h | 120 ++++++++++++++++++++++++++++++--- 3 files changed, 116 insertions(+), 106 deletions(-) diff --git a/src/libFLAC/bitmath.c

Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Well first of all, none of them apply :-). I'll try to redo the necessary patches with git. > * Remove restrict definition from include/share/compat.h. Applied. BTW, I tried to use 'restrict' keyword with MSVS 2010 and 2012 and in fact they don't support it. Only --restrict is supported. > * libFLAC and

--- configure.ac | 7 +++++ src/libFLAC/bitreader.c | 12 ++------- src/libFLAC/bitwriter.c | 8 ++---- src/libFLAC/fixed.c | 18 +++++-------- src/libFLAC/format.c | 8 ++---- src/libFLAC/include/private/macros.h | 29 ++++++++++++++++++++ src/libFLAC/metadata_iterators.c | 17 +++---------

lvqcl wrote: > This patch allows MSVS to use M_LN2 const defined in math.h For this one, I'd prefer to see the _USE_MATH_DEFINES definition in the *.vcproj and FLAC.sln files. I'd be happy to have the removal of the two comments in the same commit. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

This patch allows MSVS to use M_LN2 const defined in math.h -------------- next part -------------- A non-text attachment was scrubbed... Name: mathln2.patch Type: application/octet-stream Size: 963 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20130904/14cd34db/attachment.obj

rutine -> routine Also MSVC complains that FLAC__uint32* (unsigned int*) is not of the same type as unsigned long* --- a\src\libFLAC\include\private\bitmath.h 2013-08-13 13:30:24.000000000 +0400 +++ b\src\libFLAC\include\private\bitmath.h 2013-08-14 10:20:51.484053700 +0400 @@ -78,12 +78,12 @@ return _bit_scan_reverse(v) ^ 31U; #elif defined(__GNUC__) && (__GNUC__ >= 4 ||

Hi, I was wondering how much worse FLAC performance would be if it was compiled integer-only, but while trying to do so (by adding #define FLAC__INTEGER_ONLY_LIBRARY 1 to config.h, just on x86_64-linux) I got this error > ./include/private/bitmath.h:134:5: error: operator '&&' has no left > operand bitmath.h:134 is the following line > #if &&

Anybody knows the reason for the following code (you can see it in flac/decode.c, flac/encode.c, libFLAC/fixed.c and libFLAC/stream_decoder.c) ? #if defined _MSC_VER || defined __MINGW32__ /* with MSVC you have to spoon feed it the casting */ residual_bits_per_sample[0] = (FLAC__float)((total_error_0 > 0) ? log(M_LN2 * (FLAC__double)(FLAC__int64)total_error_0 /

- INCLUDES is deprecated, and CPPFLAGS is an user-defined variable, use the proper AM_CPPFLAGS instead - Remove FLAC__INLINE definition, providing proper replacement for MSVC compilers. - Detect if we have C99 's lround and provide a replacement for windows... --- configure.ac | 32 ++++++++-------------------- examples/c/decode/file/Makefile.am

On Mon, Oct 30, 2006 at 11:13:25AM -0800, Josh Coalson wrote: > my apologies for not doing this before Miroslav... I will definitely > integrate it this time. Thanks. Sending latest version of the patch. Now it can seek in files that have large id3 tag (or any random data) at the end and it won't loop on streams with shuffled frames. -- Miroslav Lichvar -------------- next part

On Mon, Jan 24, 2005 at 06:31:21PM -0800, Josh Coalson wrote: > yes, a mere 2 years later it is checked in! > > speed improvement for me is roughly 17% testing flac files on > linux-i386. Thanks! In case you would like to check another old patch, I have attached updated patch for seekable stream decoder, originally posted on 09/07/2003. -- Miroslav Lichvar -------------- next

Ok, the patch from 2003 about improving seeking still didn't make it to CVS, so here is another try. I made some benchmarking with the test_seeking utility from flac sources to show how bad the current seeking is, especially without seektable. Track used for the experiment had about 50 minutes. In the following table is average number of seeks and number of decoded frames required for one

Hello, While building from git, I'm getting the following failure (help please): CC ogg_mapping.lo CCLD libFLAC.la Creating library file: .libs/libFLAC.dll.a .libs/bitreader.o: In function `FLAC__clz_soft_uint32': ./include/private/bitmath.h:46: multiple definition of `_FLAC__clz_soft_uint32' .libs/bitmath.o:./include/private/bitmath.h:46: first defined here .libs/fixed.o:

With gcc >= 4 and ELF, set default visibility to hidden and make visible only the symbols with FLAC_API or FLACPP_API. A convenience libFLAC-static.la is created for test_libFLAC as it depends on the hidden symbols. --- configure.ac | 8 +++++++- include/FLAC++/export.h | 13 +++++++++---- include/FLAC/export.h | 13 +++++++++---- src/libFLAC/Makefile.am | 10

On Sat, May 19, 2001 at 06:42:22PM -0400, Matt Zimmerman wrote: > I think this could be fixed by changing the (data_len > 0) test to be > (data_len > 0 && total_error_X > 0). Yes, this appears to have worked. I can now correctly encode and decode both my 8kHz/8-bit/mono sample, and a 44.1kHz/16-bit/stereo sample on Debian/alpha. Attached is a patch which combines this fix

I have optimized FLAC__fixed_compute_best_predictor_asm_ia32_mmx_cmov function and fixed bug when data_len == 0. Now the function is about 50% faster and flac -5 is about 5% faster on my box. I have tested it thoroughly, I think it can go to flac 1.0.4. -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/ia32/fixed_asm.nasm.orig 2002-01-26 19:05:12.000000000 +0100 +++

On Mon, Jul 02, 2001 at 09:50:38PM -0700, Josh Coalson wrote: > After some intense debugging, I found the problem. One block in the file > triggered a very rare bug in the LPC coefficient quantizer caused by > insufficient floating point precision. There is a snippet to compute the > log(base 2) of a number: > > floor(log(cmax) / M_LN2) > > It turns out on at least

> > After some intense debugging, I found the problem. One block in > > the file > > triggered a very rare bug in the LPC coefficient quantizer caused > > by > > insufficient floating point precision. There is a snippet to > > compute the > > log(base 2) of a number: > > > > floor(log(cmax) / M_LN2) > > > > It turns out on at

--- src/libFLAC/include/private/bitmath.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/libFLAC/include/private/bitmath.h b/src/libFLAC/include/private/bitmath.h index 42ce639..e5c7695 100644 --- a/src/libFLAC/include/private/bitmath.h +++ b/src/libFLAC/include/private/bitmath.h @@ -74,7 +74,7 @@ static inline unsigned int FLAC__clz_uint32(FLAC__uint32 v) { /* Never

for am in automake-$AM_NEEDED automake$AM_NEEDED \ automake automake-1.7 automake-1.8 automake-1.9 automake-1.10; do This code makes it check for automake-1.7 (AM_NEEDED evaluates to 1.7), then automake (unversioned wrapper), then 1.7 (again), 1.8, 1.9 and then 1.10 1) Why the check is generally ascending? Isn't it better use the most recent version that is known to work instead of