search for: flac__integer_only_librari

Has anyone tried to build flac with the INTEGER_ONLY_LIBRARY flag set lately? I'm getting link errors on IA32 for the SSE optimizations lpc_restore_signal_16_intrin_sse2 and lpc_restore_signal_wide_intrin_sse41. Looks like a define check is missing since the implementation of these functions is only included when not building for integer. I had to exclude them at libFLAC/stream_decoder.c:408

--- Bernd Löhr <B.Loehr@hermstedt.de> wrote: > Hi, > > I am using the FLAC encoder and decoder lib in it's integer only > version (FLAC__INTEGER_ONLY_LIBRARY) on a PPC405 system. > > I encounter complete different behaviour when setting random playback > > positions while decoding different flac encoded files. > If they have been encoded on a PC,

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

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

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

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

math.h file in MS VC++ _does_ have M_LN2 constant but it requires _USE_MATH_DEFINES: --- a\src\libFLAC\fixed.c 2013-08-13 13:30:24.000000000 +0400 +++ b\src\libFLAC\fixed.c 2013-08-14 10:14:07.873648300 +0400 @@ -34,6 +34,9 @@ # include <config.h> #endif +#if defined(_MSC_VER) +#define _USE_MATH_DEFINES +#endif #include <math.h> #include <string.h> #include

I received a message from C.R.Helmrich (he doesn't want to subscribe just to post a single message). The following message was posted by C.R.Helmrich [begin] Hi, I tested my own Win32 compile of pre1 and pre2 one or two weeks ago (flac.exe through foobar2000 for transcoding), and the results were as expected: no errors, roughly same speed on my Intel Core i...something mobile, very

On Thu, Apr 05, 2007 at 06:48:06PM +0200, Josh Green wrote: > It seems that generally Wavpack does a little better than FLAC at > compressing audio. But that is generally within a rather small margin. > 20% margin seems a little large to me though. There may indeed be no > problem with the FLAC reference implementation in regards to 24 bit and > its just having trouble compressing

When I was trying to find yesterday's xmms-plugin bug, i have noticed that seeking in stream without seek-table isn't very good. With attached patch it is much better. -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/seekable_stream_decoder.c.orig 2003-02-26 19:41:51.000000000 +0100 +++ src/libFLAC/seekable_stream_decoder.c 2003-07-09 23:49:35.000000000 +0200

Ok, here is a patch waiting for new CVS :). It works fine for me, but please check it before commiting... -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/bitbuffer.c.orig 2003-01-30 17:36:01.000000000 +0100 +++ src/libFLAC/bitbuffer.c 2003-01-30 21:53:18.000000000 +0100 @@ -51,6 +51,25 @@ */ static const unsigned FLAC__BITBUFFER_DEFAULT_CAPACITY = ((65536 - 64) *

On Thu, 2007-04-05 at 02:27 -0700, Brian Willoughby wrote: > Josh (Green), > > Seems like the longest example in your list is a 15-second file. I > would like to see the same problem exhibited in a file that is of a > normal length. I have been recording full performances lasting > hours, and flac always compresses the files below 70% of the original > size. >

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

The following series adds initial vector support for PowerPC64. On POWER9, flac --best is about 3.3x faster. Amitay Isaacs (2): Add m4 macro to check for C __attribute__ features Check if compiler supports target attribute on ppc64 Anton Blanchard (5): configure.ac: Remove SPE detection code configure.ac: Add VSX enable/disable configure.ac: Fix FLAC__CPU_PPC on little endian, and add