[flac-dev] PATCH for MSVC: libFLAC and FLAC__ALIGN_MALLOC_DATA
Somehow MSVC projects don't have FLAC__ALIGN_MALLOC_DATA defined. --- a\src\libFLAC\libFLAC_static.vcproj 2013-08-13 13:30:24.0 +0400 +++ b\src\libFLAC\libFLAC_static.vcproj 2013-08-15 21:55:18.343822400 +0400 @@ -40,7 +40,7 @@ Name=VCCLCompilerTool Optimization=0 AdditionalIncludeDirectories=.\include;..\..\include - PreprocessorDefinitions=WIN32;_DEBUG;_LIB;FLAC__HAS_OGG;FLAC__CPU_IA32;FLAC__HAS_NASM;FLAC__USE_3DNOW;VERSION=\quot;1.3.0\quot;;FLAC__NO_DLL;DEBUG;FLAC__OVERFLOW_DETECT + PreprocessorDefinitions=WIN32;_DEBUG;_LIB;FLAC__HAS_OGG;FLAC__CPU_IA32;FLAC__HAS_NASM;FLAC__USE_3DNOW;FLAC__ALIGN_MALLOC_DATA;VERSION=\quot;1.3.0\quot;;FLAC__NO_DLL;DEBUG;FLAC__OVERFLOW_DETECT MinimalRebuild=true BasicRuntimeChecks=3 RuntimeLibrary=1 @@ -108,7 +108,7 @@ OmitFramePointers=true WholeProgramOptimization=true AdditionalIncludeDirectories=.\include;..\..\include - PreprocessorDefinitions=WIN32;NDEBUG;_LIB;FLAC__HAS_OGG;FLAC__CPU_IA32;FLAC__HAS_NASM;FLAC__USE_3DNOW;VERSION=\quot;1.3.0\quot;;FLAC__NO_DLL;FLaC__INLINE=_inline + PreprocessorDefinitions=WIN32;NDEBUG;_LIB;FLAC__HAS_OGG;FLAC__CPU_IA32;FLAC__HAS_NASM;FLAC__USE_3DNOW;FLAC__ALIGN_MALLOC_DATA;VERSION=\quot;1.3.0\quot;;FLAC__NO_DLL;FLaC__INLINE=_inline RuntimeLibrary=0 BufferSecurityCheck=false UsePrecompiledHeader=0 --- a\src\libFLAC\libFLAC_dynamic.vcproj2013-08-13 13:30:24.0 +0400 +++ b\src\libFLAC\libFLAC_dynamic.vcproj2013-08-15 21:54:54.005430300 +0400 @@ -40,7 +40,7 @@ Name=VCCLCompilerTool Optimization=0 AdditionalIncludeDirectories=.\include;..\..\include - PreprocessorDefinitions=WIN32;_DEBUG;_WINDOWS;_USRDLL;FLAC_API_EXPORTS;FLAC__HAS_OGG;FLAC__CPU_IA32;FLAC__HAS_NASM;FLAC__USE_3DNOW;VERSION=\quot;1.3.0\quot;;DEBUG;FLAC__OVERFLOW_DETECT + PreprocessorDefinitions=WIN32;_DEBUG;_WINDOWS;_USRDLL;FLAC_API_EXPORTS;FLAC__HAS_OGG;FLAC__CPU_IA32;FLAC__HAS_NASM;FLAC__USE_3DNOW;FLAC__ALIGN_MALLOC_DATA;VERSION=\quot;1.3.0\quot;;DEBUG;FLAC__OVERFLOW_DETECT MinimalRebuild=true BasicRuntimeChecks=3 RuntimeLibrary=1 @@ -119,7 +119,7 @@ OmitFramePointers=true WholeProgramOptimization=true AdditionalIncludeDirectories=.\include;..\..\include - PreprocessorDefinitions=WIN32;NDEBUG;_WINDOWS;_USRDLL;FLAC_API_EXPORTS;FLAC__HAS_OGG;FLAC__CPU_IA32;FLAC__HAS_NASM;FLAC__USE_3DNOW;VERSION=\quot;1.3.0\quot;;FLaC__INLINE=_inline + PreprocessorDefinitions=WIN32;NDEBUG;_WINDOWS;_USRDLL;FLAC_API_EXPORTS;FLAC__HAS_OGG;FLAC__CPU_IA32;FLAC__HAS_NASM;FLAC__USE_3DNOW;FLAC__ALIGN_MALLOC_DATA;VERSION=\quot;1.3.0\quot;;FLaC__INLINE=_inline RuntimeLibrary=0 BufferSecurityCheck=false UsePrecompiledHeader=0 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH: MSVC and M_LN2
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.0 +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 private/bitmath.h @@ -42,7 +45,6 @@ #include FLAC/assert.h #ifndef M_LN2 -/* math.h in VC++ doesn't seem to have this (how Microsoft is that?) */ #define M_LN2 0.69314718055994530942 #endif --- a\src\libFLAC\lpc.c 2013-08-13 13:30:24.0 +0400 +++ b\src\libFLAC\lpc.c 2013-08-06 19:17:00.765482100 +0400 @@ -34,6 +34,9 @@ # include config.h #endif +#if defined(_MSC_VER) +#define _USE_MATH_DEFINES +#endif #include math.h #include FLAC/assert.h @@ -52,7 +55,6 @@ #ifndef FLAC__INTEGER_ONLY_LIBRARY #ifndef M_LN2 -/* math.h in VC++ doesn't seem to have this (how Microsoft is that?) */ #define M_LN2 0.69314718055994530942 #endif ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH for bitmath.h: 1 typo, 1 warning
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.0 +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 || (__GNUC__ == 3 __GNUC_MINOR__ = 4)) /* This will translate either to (bsr ^ 31U), clz , ctlz, cntlz, lzcnt depending on - * -march= setting or to a software rutine in exotic machines. */ + * -march= setting or to a software routine in exotic machines. */ return __builtin_clz(v); #elif defined(_MSC_VER) (_MSC_VER = 1400) -FLAC__uint32 idx; +unsigned long idx; _BitScanReverse(idx, v); -return idx ^ 31U; +return (unsigned)idx ^ 31U; #else return FLAC__clz_soft_uint32(v); #endif ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] About the usefulness of fast_float_math_hack.h
fast_float_math_hack.h works only when __ICL is defined (that is, when FLAC is compiled with Intel compiler). But current Intel compilers don't have mathf.h file. Instead, mathimf.h should be used, and mathimf.h is not compatible with the standard math.h. Maybe it's time to remove fast_float_math_hack.h? It is useful only for those who use ICC compiled FLAC and use --apply-replaygain-which-is-not-lossless switch with hard -6dB limiting. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] PATCH for MSVC++ 2005 Express
Erik de Castro Lopo mle...@mega-nerd.com wrote: Is there not a later free (as in free beer) version? There are also 2008, 2010 and 2012 versions. VS2012 Express requires Win7 to run (though it can create programs compatible with WinXP). VS2010 Express works on WinXP. It is possible to compile x86-64 programs with it, but it requires Platform SDK (also free). VS2005 and 2008 Express editions cannot create 64-bit apps. If there is, it makes little sense to keep maintaining project files for the old free version. VS2005 and VS2008 use *.sln and *.vcproj files to store project settings, while 2010 and 2012 use *.sln, *.vcxproj (note x: vc_x_proj) and *.vcxproj.filters files. And it's not possible to easily downgrade project files from VS2010 format to VS2008 format. I think that moving from VS2005 to VS2010 or 2012 is a good isea, but... for example, Winamp team still uses Visual Studio 2008 to build Winamp and all necessary libraries including libFLAC.dll. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH for bitmath.h, part 2
I noticed another problem, now with _BitScanReverse64: --- a\src\libFLAC\include\private\bitmath.h 2013-08-16 23:02:38.869769500 +0400 +++ b\src\libFLAC\include\private\bitmath.h 2013-08-19 18:46:37.424494400 +0400 @@ -136,9 +136,9 @@ return sizeof(FLAC__uint64) * CHAR_BIT - 1 - __builtin_clzll(v); /* Sorry, only supported in win64/Itanium.. */ #elif (defined(_MSC_VER) (_MSC_VER = 1400)) (defined(_M_IA64) || defined(_WIN64)) -FLAC__uint64 idx; +unsigned long idx; _BitScanReverse64(idx, v); -return idx ^ 63U; +return (unsigned)idx ^ 63U; #else /* Brain-damaged compilers will use the fastest possible way that is, de Bruijn sequences (http://supertech.csail.mit.edu/papers/debruijn.pdf) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH for cpu.c
1) Some time ago all project files for MSVC 6 were removed; it makes sense to
remove the code that is necessary only for MSVC 6 and older compilers.
--- a\src\libFLAC\cpu.c 2013-08-13 13:30:24.0 +0400
+++ b\src\libFLAC\cpu.c 2013-08-16 21:46:42.177485300 +0400
@@ -285,14 +285,7 @@
# ifdef USE_TRY_CATCH_FLAVOR
_try {
__asm {
-# if _MSC_VER = 1200
- /* VC6 assembler doesn't know SSE, have
to emit bytecode instead */
- _emit 0x0F
- _emit 0x57
- _emit 0xC0
-# else
xorps xmm0,xmm0
-# endif
}
}
_except(EXCEPTION_EXECUTE_HANDLER) {
@@ -307,14 +300,7 @@
/* http://www.codeproject.com/cpp/gccasm.asp */
/* http://www.hick.org/~mmiller/msvc_inline_asm.html */
__asm {
-# if _MSC_VER = 1200
- /* VC6 assembler doesn't know SSE, have to emit
bytecode instead */
- _emit 0x0F
- _emit 0x57
- _emit 0xC0
-# else
xorps xmm0,xmm0
-# endif
inc sse
nop
nop
2) MSVC produces warnings if FLAC__USE_3DNOW is not defined : variable
FLAC__CPUINFO_IA32_CPUID_EXTENDED_AMD_xxx of static storage duration was
declared but never referenced
--- a\src\libFLAC\cpu.c 2013-08-16 21:46:42.177485300 +0400
+++ b\src\libFLAC\cpu.c 2013-08-16 22:18:34.549866800 +0400
@@ -96,10 +96,12 @@
/* these are flags in ECX of CPUID AX=0001 */
static const unsigned FLAC__CPUINFO_IA32_CPUID_SSE3 = 0x0001;
static const unsigned FLAC__CPUINFO_IA32_CPUID_SSSE3 = 0x0200;
+#ifdef FLAC__USE_3DNOW
/* these are flags in EDX of CPUID AX=8001 */
static const unsigned FLAC__CPUINFO_IA32_CPUID_EXTENDED_AMD_3DNOW =
0x8000;
static const unsigned FLAC__CPUINFO_IA32_CPUID_EXTENDED_AMD_EXT3DNOW =
0x4000;
static const unsigned FLAC__CPUINFO_IA32_CPUID_EXTENDED_AMD_EXTMMX =
0x0040;
+#endif
/*
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] New routine: FLAC__lpc_compute_autocorrelation_asm_ia32_sse_lag_16
Erik de Castro Lopo mle...@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 FLAC__ALIGN_MALLOC_DATA : Looks sane but doesn't apply. * MSVC and M_LN2 : Looks sane but doesn't apply. It is also possible to add /D _USE_MATH_DEFINES as an additional option to libFLAC_static.vcproj and libFLAC_dynamic.vcproj. Don't know what is better. What do you think? * bitmath.h: 1 typo, 1 warning : I don't see why the type has to change. Declarations from MSDN: unsigned char _BitScanReverse(unsigned long * Index, unsigned long Mask); unsigned char _BitScanReverse64(unsigned long * Index, unsigned __int64 Mask); FLAC uses them as: _BitScanReverse(FLAC__uint32* idx, FLAC__uint32 v); and _BitScanReverse64(FLAC__uint64* idx, FLAC__uint64 v); AFAIK unsigned long is not the same type as FLAC__uint32 (= unsigned int) but it doesn't really matter since both of them are 4-byte unsigned integers. However, _BitScanReverse64 expects a pointer to a 4-byte uint, but it is called with a pointer to a 8-byte uint. The garbage in the most significant 4 bytes of idx is discarded then and the result of FLAC__bitmath_ilog2_wide() is correct. Still I think it's a bug. Also I noticed that all projects with '_static' suffix produce static library files (*.lib), projects with '_dynamic' suffix produce dynamic library files (*.dll), and projects without suffixes produce executables (*.exe). The only exception is win_utf8_io. Should it be renamed to win_utf8_io_static? ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH: M_LN2 for MSVS
This patch allows MSVS to use M_LN2 const defined in math.h mathln2.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH for iffscan.c
There's a typo in iffscan.c, line 64: fprintf(stderr, %ERROR patch attached. iffscan.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH: M_LN2 for MSVS
Erik de Castro Lopo mle...@mega-nerd.com wrote: 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. Sure, why not. Patch attached. m_ln2_vcproj.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] About de Bruijn sequences in bitmath.h
Found this code: ftp://ftp.samba.org/pub/unpacked/ntdb/lib/ccan/ilog/ilog.c
Tests show that it's faster to use the following code in
FLAC__bitmath_ilog2_wide():
static const unsigned char DEBRUIJN_IDX32[32]={
0, 1,28, 2,29,14,24, 3,30,22,20,15,25,17, 4, 8,
31,27,13,23,21,19,16, 7,26,12,18, 6,11, 5,10, 9
};
FLAC__uint32 v;
int m;
m=(_v0xU)5;
v=(FLAC__uint32)(_vm);
v|=v1;
v|=v2;
v|=v4;
v|=v8;
v|=v16;
v=(v1)+1;
return m+DEBRUIJN_IDX32[v*0x77CB531U270x1F];
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] About de Bruijn sequences in bitmath.h
lvqcl lvqcl.m...@gmail.com писал(а) в своём письме Sat, 07 Sep 2013 00:08:27
+0400:
Found this code: ftp://ftp.samba.org/pub/unpacked/ntdb/lib/ccan/ilog/ilog.c
Tests show that it's faster to use the following code in
FLAC__bitmath_ilog2_wide():
Oops, wrong code was posted. Here's correct version:
static inline unsigned FLAC__bitmath_ilog2_wide(FLAC__uint64 v)
{
...
...
...
static const unsigned char DEBRUIJN_IDX32[32]={
0, 1,28, 2,29,14,24, 3,30,22,20,15,25,17, 4, 8,
31,27,13,23,21,19,16, 7,26,12,18, 6,11, 5,10, 9
};
FLAC__uint32 w;
int m;
m=(v0xU)5;
w=(FLAC__uint32)(vm);
w|=w1;
w|=w2;
w|=w4;
w|=w8;
w|=w16;
w=(w1)+1;
return m+DEBRUIJN_IDX32[w*0x77CB531U270x1F];
...
...
}
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] About de Bruijn sequences in bitmath.h
Ulrich Klauer ulr...@chirlu.de wrote:
The canonical location is at CCAN: http://ccodearchive.net/info/ilog.html
Note that the code is licensed LGPL. On the other hand, the author is
Xiph.org's Timothy Terryberry, so he might be willing to relicense.
Thanks for the information.
I just thought that for x86 architecture it's faster to simply use 32-bit
intrinsic:
/* FLAC__bitmath_ilog2(x) == _BitScanReverse(x) == 31 - __builtin_clz(x) */
static inline unsigned FLAC__bitmath_ilog2_wide(FLAC__uint64 v)
{
#if _64bit_intrinsic_is_available
...
...
...
#else
if (v0xU)
return 32+FLAC__bitmath_ilog2((FLAC__uint32)(v32));
else
return FLAC__bitmath_ilog2((FLAC__uint32)v);
#endif
}
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] PATCH: bugfixes for bitmath.h
Erik de Castro Lopo mle...@mega-nerd.com wrote: However _BitScanReverse64() is called with a pointer to FLAC__uint64 (8-byte int). IMHO it's a bug I would not call that a bug, just a result of trying to write cross platform code and relying on functions that are not specified by any standard. Well, the calls of _BitScanReverse/_BitScanReverse64 are inside #ifdef _MSC_VER, so it's MS-specific code, not cross-platform. _BitScanReverse64 writes 4 least significant bytes of idx, the 4 most significant bytes are not initialized and contain some garbage. FLAC__bitmath_ilog2_wide() returns unsigned. If sizeof(unsigned)==4 then these 4 most significant bytes are discarded and the result is correct. But if sizeof(unsigned)==8 then FLAC__bitmath_ilog2_wide() will usually return incorrect value. But as I said it is MS-only code, so sizeof(unsigned) is always 4. 4. Am I right that FLAC__bitmath_ilog2_wide() and FLAC__bitmath_ilog2() return the same value if their argument is less than 2^32? Then FLAC__bitmath_ilog2_wide() works correctly only when compiled with GCC: it should return idx, not idx^63U. Also the result of de Bruijn sequences is off by 1. This also needs more investigation. Your patch changes the output of this function for any given input. There is a comment An example of what FLAC__bitmath_ilog2() computes. One can see that FLAC__bitmath_ilog2() == BitScanReverse() == 31 - CountLeadingZeroes(). And it seems that FLAC__bitmath_ilog2_wide() == BitScanReverse64() == == 63 - CountLeadingZeroesLongLong(). About de Bruijn: Ulrich Klauer posted a link to http://ccodearchive.net/info/ilog.html From this page: This can also be thought of as the location of the highest set bit, with counting starting from one (so that 0 returns 0, 1 returns 1, and 2**31 returns 32). For FLAC__bitmath_ilog2()/ilog2_wide() counting starts from zero. --- And by the way: FLAC__bitmath_ilog2_wide() is for integer-only encoder. IMHO this encoder is for platforms with very slow or absent FPU, and the inclusion of MS-specific code to this function looks a bit bizarre. I measured a speed of various implementations of FLAC__bitmath_ilog2_wide() on my Core2 CPU before I realized that it's pointless. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH: x86-64 support and SSE intrinscis code
It's not possible to use ia32/*.nasm code in 64-bit compiles. There's still no 64-bit asm code in FLAC. I'm not familiar with asm too, so I wrote SSE-accelerated code using intrinsics. This code uses two new preprocessor macros: FLAC__CPU_X86_64 (analogous to FLAC__CPU_IA32) and FLAC__HAS_X86INTRIN (analogous to FLAC__HAS_NASM) Patch for cpu.c/cpu.h adds CPU features (sse3, ssse3) detection code for x86-64 architecture. Another patch adds SSE-accelerated functions: FLAC__lpc_compute_autocorrelation_intrin_sse_lag_4() FLAC__lpc_compute_autocorrelation_intrin_sse_lag_8() FLAC__lpc_compute_autocorrelation_intrin_sse_lag_12() FLAC__lpc_compute_autocorrelation_intrin_sse_lag_16() FLAC__lpc_compute_residual_from_qlp_coefficients_16_intrin_sse2() Note that the new code works only if both FLAC__CPU_X86_64 and FLAC__HAS_X86INTRIN macros are defined somewhere in config files. Appropriate changes in *.vcproj, makefiles, configure.ac files are necessary. Unfortunately MSVS 2005 Express Edition doesn't support creation of 64-bit programs. cpu.patch Description: Binary data intrin.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] PATCH: x86-64 support and SSE intrinscis code
Erik de Castro Lopo wrote: When should FLAC__HAS_X86INTRIN be defined? What header file should I be checking for? Ah, should be checking for x86intrin.h. I simply don't know. In MSVS there's no x86intrin.h, but it has intrin.h. There is a segfault happening in the new code when compiling with -DDEBUG. Trying to track it down. I suspect that it's inline asm code for cpuid. It will be replaced with __get_cpuid(). ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] PATCH: bugfixes for bitmath.h
Erik de Castro Lopo mle...@mega-nerd.com wrote: 3. FLAC__bitmath_ilog2_wide() cannot be compiled with MSVC: it has 'if (v == 0)...' statement followed by a variable (either idx or DEBRUIJN_IDX64) definition. But all calls of this function have FLAC__ASSERT statements that ensure that its argument is greater than 0. So this 'if()' can be removed. I'd actuall prefer to remove those ASSERTS, because they get bypassed for the production compiles anyway. I thought that these ASSERTs mean that the encoding algorithm ensures: the argument of FLAC__bitmath_ilog2_wide() is always 0. In this case there's no need to compare it with 0 inside the function. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] PATCH: x86-64 support and SSE intrinscis code
Erik de Castro Lopo mle...@mega-nerd.com wrote: -msse for SSE code, -msse2 for SSE2 code, -msse4.1 for SSE4.1 code Yes, that was it. Brain fart. These flags were not needed on x86_64. Erik But now all C code is compiled with -msse2 and it won't work on older CPUs. Isn't it better to compile only necessary files with this flag? ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] Performance and precompute_partition_info_sums_32bit_asm_ia32_()
Previously I wrote that precompute_partition_info_sums_32bit_asm_ia32_() only makes encoding slower. Now I managed to compile flac with GCC 4.8.1, with this function enabled and disabled. NASM was enabled, SSE intrinsics disabled. Then I added -msse option (so that all C code was compiled with -msse), then -msse2 and so on. Input file for test: 44.1kHz/16bit/stereo; best compression mode (flac -8); CPU = Core i7. Here are the results (1st column: SSE instruction set, 2nd column: the state of precompute_partition_info_sums_32bit_asm_ia32_(), 3rd column: encoding time in seconds, smaller=better): no SSE disabled53.9 no SSEenabled55.2 SSE1 disabled53.9 SSE1 enabled55.3 SSE2 disabled51.9 SSE2 enabled53.1 SSE3 disabled51.8 SSE3 enabled53.2 SSSE3disabled45.7 SSSE3 enabled51.4 SSE41disabled46.1 SSE41 enabled51.6 SSE42disabled46.1 SSE42 enabled51.6 Conclusions: 1) flac is always faster when precompute_partition_info_sums_32bit_asm_ia32_() is disabled. 2) Some C code benefits noticeably from SSSE3 instructions; at least when compiled with GCC 4.8.1. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] PATCH: x86-64 support and SSE intrinscis code
Erik de Castro Lopo wrote: Hmm, compiling just one or two flags with these flags is somewhat difficult. Currently my intrinsic code is split into 5 files: lpc_intrin_sse.c lpc_intrin_sse2.c lpc_intrin_sse41.c stream_encoder_intrin_sse2.c stream_encoder_intrin_ssse3.c I'll see if I can think of some way around this. That would be great. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] GCC generates slow code for IA32
Martijn van Beurden mva...@gmail.com писал(а) в своём письме Sun, 22 Sep 2013 14:45:31 +0400: On 22-09-13 10:31, lvqcl wrote: I measured encoding speed of 24-bit WAV files. It turns out that 32-bit encoder made by GCC is ~1.7x times slower than 32-bit encoder made by MSVS. Strange, I'm not able to reproduce your findings. I did found something rather odd though. I thought MSVC, ICL and GCC would produce the same files, but for some reason a GCC compile creates slightly smaller files. Looks like there is some GCC-specific code that influences compression ratio? I haven't noticed that in any of the tests I did before. GCC is a bit slower, but nowhere near 1.7x Sorry I forgot to mention that I tested only -8 preset as the most CPU intensive. Input file is 44.1/24/stereo, test CPU is Core2 Q9300. Tested FLAC encoders: * 32-bit from Rarewares * 64-bit from Rarewares * 32-bit from http://www.saunalahti.fi/~cse/temp/flac-1.3.0-win32.zip * 32-bit from http://www.icer.nl/misc_stuff/flac-1.3.0-final-minGW.zip I also downloaded MSYS-MinGW 4.8.1 from http://xhmikosr.1f0.de/tools/ and compiled 32-bit and 64-bit versions of FLAC 1.3.0 myself. Encoding time, in seconds, for 64-bit builds: rarewares: 84.9 s (ICL) my compile: 90.9 s (MinGW 4.8.1) for 32-bit builds: rarewares: 137.5 s (ICL) saunalahti: 120.9 s (MSVS 2012) icer.nl:204.8 s (MinGW) my compile: 234.4 s (MinGW 4.8.1) 234.4/120.9 = 1.94 and 204.8/137.5 = 1.49, and 1.7 is somwhere between these ratios. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH for configure.ac
1) adds FLAC__ALIGN_MALLOC_DATA for x86_64 arch 2) removes XIPH_ADD_CFLAGS([-msse]) (-msse2 implies -msse) 3) fixes a typo conf_ac.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] A small PATCH for replaygain_synthesis
a) replaces float literal by double (there's no point to multiply double variable 'sample' by float const) b) replaces ifdef __ICL -- if 0 (even intel compiler doesn't have mathf.h) rg_synth.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCHES for cpu.h/cpu.c
The first patch adds SSE4.1/SSE4.2 detection. The second patch removes union data in struct FLAC__CPUInfo and replaces it with #ifdefs. Reason: currently it's possible to set or get data.ia32.sse3 value from x86-64 code, etc. It's a potential source of errors (at least that's true for me). (the 2nd patch requires the 1st to be applied) 1_sse4detect.patch Description: Binary data 2_no-union.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH: move M_PI definition to share/compat.h
Analogous to M_LN2 patch: the patch moves definition of M_PI from src/libFLAC/window.c and src/test_streams/main.c to include/share/compat.h M_PI.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH for libFLAC vcproj
Somehow libFLAC_dynamic.vcproj and libFLAC_static.vcproj don't define FLAC__HAS_X86INTRIN. has_intr.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] About unused/obsolete asm code
Erik de Castro Lopo wrote: Maybe its time to either improve or remove that code. I posted a patch that adds SSE2/SSSE3 versions of precompute_partition_info_sums_(). I didn't remove the old code; just changed #if defined ... to #if defined ... 0. Currently there are two useless asm files: * bitreader_asm.nasm (defines FLAC__bitreader_read_rice_signed_block_asm_ia32_bswap) * stream_encoder_asm.nasm (defines precompute_partition_info_sums_32bit_asm_ia32_) and I doubt that they will become useful again. BTW, after removing bitreader_asm.nasm from build it will be possible to remove local_bitreader_read_rice_signed_block from struct FLAC__StreamDecoderPrivate and call FLAC__bitreader_read_rice_signed_block() directly (IOW, revert the patch http://git.xiph.org/?p=flac.git;a=commit;h=ff6a5604da5c7223a075e58ca532d7ad375d ). Or to make bitreader_read_from_client_() function static again (it was static before http://git.xiph.org/?p=flac.git;a=commit;h=c63cf41cccba25a268f235e83ed8603adc0ac3ec ). ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] PATCH: modify/add intrinsics code
lvqcl wrote: The patch does the following: Does the patch work for linux git? Windows git cannot apply a patch that was created itself. (It writes LF in diffs for .c/.cpp/.h/ files and CRLF in diffs for .sln/.vcproj files, and then rejects the patch because of CRLF sequences. It accept this patch after I replaced all CRLF - LF). ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] MSVS: debug flac.exe uses release libogg_static.lib
Ralph Giles wrote: The way we've been doing the Opus stuff is to have the project files expect a build in a parallel checkout. so: c:\dev\flac\FLAC.sln expects to find an ogg build in c:\dev\ogg\win32\VS2010\ Not as obvious as having a monolithic build, but it seems to work once you've figured it out. And each arch and target can reference the corresponding target in the dependency. Good idea, but... there are 5 folders in libogg/win32: VS6, VS2003, VS2005, VS2008 and VS2010. And FLAC provides solution/project files for MSVS 2005. Should FLAC project files refer to libogg/win32/VS2005? But I suspect that developers use mostly newer versions (2008/2010/2012). ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] PATCH: modify/add intrinsics code
Erik de Castro Lopo wrote: Does the patch work for linux git? Windows git cannot apply a patch that was created itself. It looks like that patch was created with the 'git diff' command and hence cannot be applied using the 'git am' command. It does however apply using the patch command. To test the patch file I did the following: git diff master file.patch git checkout master git branch test git checkout test git apply file.patch And I see: error: patch failed: src/libFLAC/libFLAC_dynamic.vcproj:268 error: src/libFLAC/libFLAC_dynamic.vcproj: patch does not apply error: patch failed: src/libFLAC/libFLAC_static.vcproj:243 error: src/libFLAC/libFLAC_static.vcproj: patch does not apply Maybe it's a minor glitch in Windows version if Git. It seems that it automatically converts LF to CRLF in text files during clone/pull, but .vcproj files already use CRLF as line endings, and this somehow results in this problem. Have these patches that I apply look correct when you update your FLAC tree? Yes. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] Again about encoding speed of different compiles
I downloaded current version of FLAC sources and compiled it with: * GCC 4.8.1 (MSYS from http://xhmikosr.1f0.de/tools/) * Intel C++ Composer XE 2013 update 5 * MSVS 2010 SP1 * MSVS 2012 update 3 (SSSE3 and SSE4.1 code was disabled for all compilers) Stereo 24-bit WAV file was encoded with -8 preset. Encoding time, in seconds: GCC 32-bit: 209 ICC 32-bit: 130 VS10 32-bit: 116 VS12 32-bit: 114 GCC 64-bit: 79.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, unsigned order, int lp_quantization, FLAC__int32 * __restrict residual) Encoding time, in seconds: GCC 32-bit: 180 (16% speedup) ICC 32-bit: 121 (7.5%) VS10 32-bit: 439 (sic!) VS12 32-bit: 440 (sic!) GCC 64-bit: 72.8 (9%) ICC 64-bit: 75.0 (8%) VS10 64-bit: 75.7 (7%) VS12 64-bit: 77.7 (7%) Also I wonder what other functions can also benefit from `restrict' keyword?.. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH for rice_parameter calculation
MSVS profiler shows that the following code in stream_encoder.c takes
several percent of CPU time:
for(rice_parameter = 0, k = partition_samples; k mean; rice_parameter++, k
= 1)
;
this code is equivalent to:
rice_parameter = 0; k = partition_samples;
while(k mean) {
rice_parameter++; k = 1;
}
The idea was to accelerate it:
rice_parameter = 0; k = partition_samples;
while(k*2 mean) {
rice_parameter+=2; k = 2;
}
while(k mean) {
rice_parameter++; k = 1;
}
or:
rice_parameter = 0; k = partition_samples;
while(k*4 mean) {
rice_parameter+=3; k = 3;
}
while(k mean) {
rice_parameter++; k = 1;
}
After tuning the code for 16-/24-bit WAV and 32-/64-bit compiles
I wrote more complex code (see attach). It doesn't look pretty but
it's faster than the current version. For highest compression preset,
24-bit input and 32-bit exe the encoding speed increases by 6..7%.
rice_parameter.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] about win_utf8_io - win_utf8_io_static patch
I noticed that the patch that renamed win_utf8_io to win_utf8_io_static (http://git.xiph.org/?p=flac.git;a=commit;h=2e165ec569b1511a41fe7714d2f598a89aca0565) also changed line endings in win_utf8_io_static.vcproj from CRLF to LF. Not a big problem (MSVS understands this file anyway), but IMHO it's better to use Windows line endings for win-specific file. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] unsigned long long suffix
share/compat.h contains the following code: /* adjust for compilers that can't understand using LLU suffix for uint64_t literals */ #ifdef _MSC_VER #define FLAC__U64L(x) x #else #define FLAC__U64L(x) x##LLU #endif I tested MSVS 2005 and indeed it doesn't support LLU suffix, but it can compile a code with ULL suffix. Also, http://gcc.gnu.org/onlinedocs/gcc/Long-Long.html mentions ‘ULL’ suffix, not ‘LLU’. I don't know about VS2003 or earlier versions, but if FLAC supports only Visual Studio 2005 and newer, it's possible to reduce this code to: #define FLAC__U64L(x) x##ULL Another version: /* adjust for compilers that can't understand using ULL suffix for uint64_t literals */ #ifdef _MSC_VER #define FLAC__U64L(x) x##ui64 #else #define FLAC__U64L(x) x##ULL #endif ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH: FLAC__U64L definition
It defines FLAC__U64L(x) simply as x##ULL. ULL.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH: FLAC__ prefix to precompute_partition_info_sums_...
All(?) non-static functions have FLAC__ prefix. But precompute_partition_info_sums_32bit_asm_ia32_() and ..._intrin_sse2() and ..._intrin_ssse3() don't have it. This patch adds the prefix to them. FLAC__prefix.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH: match calls and returns
According to Agner Fog, ...you must make sure that all calls are matched with returns. Never jump out of a subroutine without a return and never use a return as an indirect jump. (see paragraph 3.15 in microarchitecture.pdf and examples 3.5a and 3.5b in optimizing_assembly.pdf) Basically this patch replaces call.get_eip0 .get_eip0: pop eax with call.mov_eip_to_eax .get_eip0: and .mov_eip_to_eax: mov eax, [esp] ret get_eip.diff Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH: asm versions for two _wide() functions
As I wrote earlier, GCC generates slow ia32 code for FLAC__lpc_compute_residual_from_qlp_coefficients_wide() and FLAC__lpc_restore_signal_wide(). So 24-bit encoding/decoding is slower for GCC compile than for MSVS or ICC compile. I took FLAC__lpc_compute_residual_from_qlp_coefficients_asm_ia32 and FLAC__lpc_restore_signal_asm_ia32 asm functions and wrote their _wide versions. wide_asm.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Windows linking problems
Brendan Bolles wrote: If someone would be so kind as to take a look, I have a branch set up, ready to show you the problem (after you download the Premiere SDK). I've posted this as a GitHub issue here: It looks like the linker cannot find libFLAC_static.lib and libFLAC++_static.lib. By default FLAC moves them to objs/release/lib/ (or objs/debug/lib/) folder. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Why Rice order in --best switch is limited to 6?
Барт Гопник wrote: Why value of -r switch in --best is limited to 6? The maximum Rice order is 8 (not 6) for the stream to be Subset compatible. Because -r 8 is noticeable slower? The size difference is 0,0003%, the speed difference is 30...40%. BTW, you can also use -A=... options to increase compression ratio. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Why Rice order in --best switch is limited to 6?
Барт Гопник wrote: I think -r 8 is highest reasonable. E.g. from 5 to 12 values of -compression_level switch in FFMPEG uses value 8 of Rice order parameter. But FFMPEG uses flake encoder, not libFLAC. So their optimal values may differ. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Windows linking problems
Was that a problem in the vcproj files shipped with FLAC or your own personal ones? If it was for the ones shipped with FLAC would you be able to provide a patch or even description of the changes required so that someone on this list can generate a patch? It was the project that came with FLAC. Might not be considered a problem, just a slightly non-standard configuration. In the Visual Studio project properties, under C/C++ Code Generation is the Runtime Library setting. I think linking to Multi-threaded DLL is more standard than just Multi-threaded which would copy the Windows libraries into the thing you're building. As I've found on other platforms too, linking errors often don't produce messages that are very helpful toward figuring out what's going wrong. Just a comment for those who doesn't use MS Visual Studio: Multi-threaded runtime library means static linking. All necessary functions from MS Visual C++ runtime are statically linked into .dll/.exe file. Multi-threaded DLL runtime library means dynamic linking: a program requires msvcr80.dll/msvcr90.dll/.../msvcr120.dll to work. Often this means that a MS Visual C++ 20YY redistributable package must be installed into user's system. Also: README file, section Building with MSVC: build libogg_static.lib (load win32\libogg_static.sln, change solution configuration to Release and code generation to Multi-threaded (/MT), then build). So FLAC linking mode was deliberately set to static aka Multi-threaded. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Exact FLAC subset constraints
Барт Гопник wrote: Any progress? http://git.xiph.org/?p=flac.git;a=commit;h=09229aa967251ce840e43d300d27a915495e75db commit 2007-07-31, author: Josh Coalson, committer: Josh Coalson document blocksize strategy bit, RESIDUAL_CODING_METHOD_PARTITIONED_RICE2, new subset sample rates, subset clarification, variable blocksize clarification Before: The blocksize bits in the frame header must be 0001-0101 or 1000-1110, specifying a fixed-blocksize stream (the exception being the last block as described in the table) and a few allowable blocksizes. This also means that the STREAMINFO metadata block must specify equal mininum and maximum blocksizes. If the sample rate is = 48000Hz, the blocksize must be =4608, i.e. blocksize bits 0001-0101 or 1000-1100. After: The blocksize bits in the frame header must be 0001-1110. The blocksize must be =16384; if the sample rate is = 48000Hz, the blocksize must be =4608. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Exact FLAC subset constraints
Also found this: http://lists.xiph.org/pipermail/flac-dev/2008-May/002550.html http://lists.xiph.org/pipermail/flac-dev/2008-May/002559.html ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH for lpc_asm.nasm
1) Two comments ;ASSERT(lp_quantization = 31) in the new functions ..._wide_asm_ia32() -- just to mention this constraint. (max. possible value of lp_quantization is 15, so it's not a problem) 2) mov cl, ... was replaced with mov ecx, ... (again Agner Fog, optimizing_assembly.pdf) summary: write to a partial register may result in false dependencies between instructions, so it is better to avoid it. (also bitreader_asm.nasm and stream_encoder_asm.nasm both have mov ecx, ... instructions, and no mov cl, ...). cl_to_ecx.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] PATCH: add FLAC__SSE_SUPPORTED and FLAC__SSE2_SUPPORTED
Erik de Castro Lopo wrote: Yes, I think src/libFLAC/include/private/cpu.h would be a better place for this SSE version support stuff. Would you be able to do it or should I? OK, the attached patch adds FLAC__SSE*_SUPPORTED and also moves their definitions to cpu.h. It also adds GCC 4.9 support (http://gcc.gnu.org/gcc-4.9/changes.html: It is now possible to call x86 intrinsics from select functions in a file that are tagged with the corresponding target attribute without having to compile the entire file with the -mxxx option) I also found that I wrote #ifdef _MSC_VER instead of #if defined _MSC_VER || defined __INTEL_COMPILER. The second attached patch fixes this. 1_sse_support.patch Description: Binary data 2_ifdefs.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH
This patch removes #define inline __inline definition from src/libFLAC/include/private/macros.h because it exists in include/share/compat.h. macro_inline.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH for FLAC__precompute_partition_info_sums_intrin_sseNN
This patch removes conversion from __m128i to FLAC__uint64. Encoding speed slightly increased (1...2% for FLAC -8). precomp_part.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH for FLAC__precompute_partition..., part 2
Just realized that it's also possible to do the same with if(bps = 16) branch of code and remove FLAC__uint32 abs_residual_partition_sum variable. precomp_part2.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH: IA32 and NASM
Erik de Castro Lopo wrote: Or does it make sence to add the following code: Yes it does. The patch is attached. intrin_if_no_nasm.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH for bitmath.h
FLAC__bitmath_ilog2_wide() function is still problematic: 1) it cannot be compiled with MSVS 2) it returns correct results only when compiles with GNUC 3) it mentions LGPL which isn't good for a BSD-licensed library Here's the patch that should fix these issues. (about LGPL - CC0 change: http://lists.xiph.org/pipermail/flac-dev/2013-September/004356.html ) bitmath.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH: don't use intrinsics when they're slower
More thorough en-/decoding tests show that sometimes the functions that use intrinsics are slower (or not really faster) than old plain C functions. After this patch the encoder doesn't use these new functions when their usefulness is questionable no_slow_intrin.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH don't use intrinsics when they're slower, Version 2
A newer version of the patch. Replaces the previous (ie. http://lists.xiph.org/pipermail/flac-dev/2014-February/004553.html) version. no_slow_intrin_v2.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH: fix pragma warning
Changes invalid (and commented) #pragma warning ( enable : 4800 ) with correct #pragma warning ( default : 4800 ) Also adds #pragma warning ( disable : 4800 ) to src/test_libFLAC++/encoders.cpp (analogous to src/test_libFLAC++/decoders.cpp) warning4800.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH: FLAC__STRCASECMP definition
Move FLAC__STRCASECMP to share/compat.h and remove it from src/flac/main.c and src/share/grabbag/cuesheet.c strcasecmp.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH: strtoull
For MSVS, share/compat.h redefines strtoull as _strtoui64, and there's no need in local__strtoull(). strtoull.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH: FLAC__I64L macro
Changes the definition of FLAC__I64L macro (analogous to FLAC__U64L macro in compat.h) flac_i64l.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH: coding style fixes
a) A previous patch for stream_encoder_intrin_.c removes
definitions of abs_residual_partition_sum variables but leaves
unnecessary empty line after it. The first attached patch removes them.
b) The second attached patch fixes coding style for lpc_asm.nasm:
mov{space}ebp, esp
to
mov{tab}ebp, esp
etc.
precompute_empty_lines.patch
Description: Binary data
lpc_asm.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH for FLAC__VENDOR_STRING definition
Since FLAC project don't support MSVC6 there's no need in hacks. format.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH: fix comments
1) FLAC__seekable_stream_decoder_reset() was renamed to FLAC__stream_decoder_reset() many years ago 2) I tried to update comments in precompute_partition_info_sums_(). fix_comment1.patch Description: Binary data fix_comment2.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH: OS SSE support detection for GCC on Windows
libFLAC for Windows compiled with GCC/MinGW can't detect SSE OS support: it can't use GCC+Linux detection code and can't use MSVC+Win32 code that uses SEH (__try/__except). So it doesn't use any SSE/SSE2/etc routines. One way to fix it is to call configure script with --enable-sse (flac will probably crash on Win95/WinNT4 but who cares). Another way is to add a new code just for GCC+Win32 case. The patch is attached. ...One thing that worries me is the comment in cpu.c: /* sigill_handler flavor resulted in several crash reports on win32 */ but the corresponding ticket #307 ( http://sourceforge.net/p/flac/bugs/307/ ) doesn't reveal any details. cpu_gcc_win32.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] x86_64 SSE2/SSE41 optim not used
Olivier Tristan wrote: In stream_decoder.c when assigning lpc restore function, only IA32 processor benefits from SS2 and SSE4.1 optimization. Shouldn't it be the case for x86_64 processor as well ? I tried, and it didn't make decoding faster. (And even SSE4.1 for IA-32 is... questionable) OTOH, flac decoding is really very fast. It's very hard to make it even faster. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] PATCH: OS SSE support detection, version 2
Erik de Castro Lopo wrote: part 1: fixes part 2: new code Any comments? Applied cpu_part2.patch. Thanks! Thanks. I hope that this code will help to avoid bug reports such as http://sourceforge.net/p/flac/bugs/409/ (it seems that the author of this report compiled FLAC without --enable-sse option). OTOH, SSE support is unavailable only in Win95 and WinNT. Also, as Martijn van Beurden pointed out, flac.exe doesn't support Win95 (and also 98/Me) since version 1.3.0, and nobody complained about it. Maybe it's better and simpler to change configure.ac so that --enable-sse is on by default if the target OS is Windows? About part 1:does it have any problems? I can split it into several patches (1 fix = 1 patch) or explain the changes in it in detail. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] PATCH: OS SSE support detection, version 2
Erik de Castro Lopo wrote: About part 1:does it have any problems? I can split it into several patches (1 fix = 1 patch) or explain the changes in it in detail. I didn't apply patch1 because I mis-read your comment here: http://lists.xiph.org/pipermail/flac-dev/2014-March/004582.html So, for the patches in this email: http://lists.xiph.org/pipermail/flac-dev/2014-March/004577.html Should I apply patch2? Should I revert patch1 which has already been applied? First I wrote the patch to cpu.c and posted it here: http://lists.xiph.org/pipermail/flac-dev/2014-March/004576.html Then I posted a second version of this patch (so the patch above is obsolete): http://lists.xiph.org/pipermail/flac-dev/2014-March/004577.html This second version was split into two files: * the first part contains fixes ( CALLBACK - WINAPI, updated URLs in comments, r(sse) - 0(sse), etc) * and the second part contains a code for SSE support detection when a compiler is MinGW/GCC and target OS is Win32. The latest change in configure.ac makes this second part mostly useless because by default it will be thrown away by preprocessor. So, about the patches from http://lists.xiph.org/pipermail/flac-dev/2014-March/004577.html * The patch cpu_part1.patch should be applied; * The patch cpu_part2.patch (already applied) is almost useless now, so why keep it? It can be useful only for those who want to use MinGW/GCC to compile Win95-compatible libFLAC.dll or Win95/WinNT4 compatible flac.exe. Do these people exist? ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] PATCH: OS SSE support detection, version 2
Erik de Castro Lopo wrote: It looks like I applied the the part1 patch and didn't apply the part2 patch. Please check commit 99d5154f436b389758d6a9020e448b8dbedb14bc. Well, it's part2 as far as i can see... My message contained 2 attached files: 1) cpu_part1.patch that begins with diff --git a/src/libFLAC/cpu.c b/src/libFLAC/cpu.c index 43592ad..ec390d5 100644 --- a/src/libFLAC/cpu.c +++ b/src/libFLAC/cpu.c @@ -142,7 +142,7 @@ static const unsigned FLAC__CPUINFO_IA32_CPUID_EXTENDED_AMD_EXTMMX = 0x0040; # define USE_TRY_CATCH_FLAVOR /* sigill_handler flavor resulted in several crash reports on win32 */ # ifdef USE_TRY_CATCH_FLAVOR # else - LONG CALLBACK sigill_handler_sse_os(EXCEPTION_POINTERS *ep) + LONG WINAPI sigill_handler_sse_os(EXCEPTION_POINTERS *ep) 2) and cpu_part2.patch that begins with diff --git a/src/libFLAC/cpu.c b/src/libFLAC/cpu.c index ec390d5..df97789 100644 --- a/src/libFLAC/cpu.c +++ b/src/libFLAC/cpu.c @@ -151,6 +151,23 @@ static const unsigned FLAC__CPUINFO_IA32_CPUID_EXTENDED_AMD_EXTMMX = 0x0040; return EXCEPTION_CONTINUE_SEARCH; } # endif +# elif defined(_WIN32) defined(__GNUC__) +# undef USE_FXSR_FLAVOR +# ifdef USE_FXSR_FLAVOR ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Wrong warning in encoder for 24bits WAV
Olivier Tristan wrote:
I've just faced a wrong warning trying to encode a 24 bits WAV file
if(wFormatTag == 1) {
if(bps != 8 bps != 16) {
if(bps == 24 || bps == 32) {
/* let these slide with a warning since they're
unambiguous */
flac__utils_printf(stderr, 1, %s: WARNING:
legacy WAVE file has format type %u but bits-per-sample=%u\n,
e-inbasefilename, (unsigned)wFormatTag, bps);
AFAIK only 32bits file require a format of 3 while it's fine for 8, 16
and 24bits
FLAC expects wFormatTag == 0xFFFE when bitdepth is not 8 or 16.
See http://msdn.microsoft.com/en-us/library/windows/desktop/dd757713.aspx
If wFormatTag is WAVE_FORMAT_PCM, then wBitsPerSample should be equal to 8 or
16.
[...]
If wFormatTag is WAVE_FORMAT_EXTENSIBLE, this value can be any integer multiple
of 8.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] building issue on OSX GCC 4.2 / Xcode
Olivier Tristan wrote: Hi Guys, The current trunk do not build with GCC 4.2 on OSX when compiling cpu.c cpuid.h does not exists and __get_cpuid() is not defined This version of GCC is required if you want to support pre 10.7 systems which are still pretty common. It seems other project had the same issue https://bugzilla.mozilla.org/show_bug.cgi?id=836824 So they simply added defined (HAVE_CPUID_H) to the preprocessor condition... Don't know much what would be the right fix. Any idea ? Patch attached. I hope it will fix the problem. cpuid.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] About attempt to fix differences between x86 FPU and SSE calculations
More specifically, about this patch: http://git.xiph.org/?p=flac.git;a=commitdiff;h=70b078cfd5f9d4b0692c33f018cac3c652b14f90 I downloaded the latest code from git (flac-70b078c), disabled all SSE optimizations in the code and compiled it (GCC 4.8.2). This patch doesn't change FLAC output. Either gcc is too smart and optimizes this new code back to the old, or this fix is MSVS-specific. Or both. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH for test_libFLAC.vcproj
Currently test_libFLAC is broken for MSVS. This patch adds two new files (md5.c and md5.h) to test_libFLAC.vcproj. test_libflac.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] About attempt to fix differences between x86 FPU and SSE calculations
Olivier Tristan o.tris...@uvi.net писал(а) в своём письме Fri, 21 Mar 2014 22:41:00 +0400: Check with -mfpmath=387 to be sure that x87 FPU code is used and not some SSE optim made by GCC I added XIPH_ADD_CFLAGS([-mfpmath=387]) into configure.ac Still the result is different from SSE version. --- MSVS adds two instructions to the generated code after the patch: fld DWORD PTR [eax] inc ecx fmulST(0), ST(1) add eax, 4 fstpDWORD PTR tv2337[esp+20]- this: (copy from FP stack to tmp) fld DWORD PTR tv2337[esp+20]- and this (copy from tmp to FP stack) faddDWORD PTR [ebx+ecx*4-4] fstpDWORD PTR [ebx+ecx*4-4] However GCC doesn't do this: lea ecx, [eax+2] fld DWORD PTR [edx+ecx*4] fmulst, st(1) faddDWORD PTR [ebx+ecx*4] fstpDWORD PTR [ebx+ecx*4] Also MSVS doesn't add these instructions if Floating Point Model is set to Fast (/fp:fast). ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] [PATCH] for include/share/compat.h
This file has the following code: #ifdef _WIN32 /* All char* strings are in UTF-8 format. Added to support Unicode files on Windows */ [...] #define flac_stat _stat64_utf8 #else [...] #ifdef _WIN32 #define flac_stat _stat64 #else #define flac_stat stat #endif #endif The second #ifdef _WIN32 doesn't make much sense. flac_stat.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] [PATCH] Suppress MSVS warnings for lpc.c
When compiling lpc.c for x86-64 architecture MSVS issues warnings: warning C4028: formal parameter _N_ different from declaration because of flac_restrict modifier. This patch suppresses these warnings. lpc-msvs-warnings.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH: bugfix for the previous patch
I found a bug in my code, in FLAC__CPU_X86_64 branch: encoder-private_-local_fixed_compute_best_predictor_wide is always sets to FLAC__fixed_compute_best_predictor_wide_intrin_sse2. The fix is attached. if_else_fix.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH: WAVEFORMATEXTENSIBLE_CHANNEL_MASK is ignored when decoding
Currently FLAC doesn't read the contents of WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag in a decoded FLAC file and doesn't write correct channel mask to a WAV file. (d-channel_mask == 0 inside DecoderSession_process() function in decode.c) The attached patch fixes this problem but I'm not sure that it doesn't have any side effects... Also, maybe it's better to call FLAC__stream_decoder_set_metadata_respond() somewhere? mask.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH: WAVEFORMATEXTENSIBLE_CHANNEL_MASK, version 3
It seems that it's possible to make slightly less intrusive patch. mask_v3.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] make fullcheck fails: strtod/atof and locale
make fullcheck fails on my computer: flac cannot recognize --skip option that contains decimal point, e.g. --skip=1.234. System locale uses comma as a separator, so strtod/atof expect comma, not point, and make fullcheck fails. Here's what I can see in FLAC source code: atof() function found in: file: src/share/grabbag/seektable.c function: grabbag__seektable_convert_specification_to_template() (option: -S) strtod() function found in: src/flac/main.c parse_option() (--apply-replaygain-which-is-not-lossless) src/flac/utils.c local__parse_timecode_() = flac__utils_parse_skip_until_specification() (--skip, --until) src/libFLAC/stream_encoder.c FLAC__stream_encoder_set_apodization() (-A gauss, -A tukey) src/share/grabbag/cuesheet.c local__parse_ms_() = local__cuesheet_parse_() = grabbag__cuesheet_parse() src/share/grabbag/replaygain.c parse_double_() = grabbag__replaygain_load_from_vorbiscomment() *** comments *** 1) local__parse_ms_() have strspn(s, 0123456789.) so decimal comma is not allowed in cuesheets 2) local__parse_timecode_() have strspn(s, 1234567890.,) so comma is allowed in --skip and --until options 3) grabbag__replaygain_load_from_vorbiscomment() uses the following sequence: setlocale(LC_ALL, C); use printf/strtod; setlocale(LC_ALL, saved_locale); so RG tags always have decimal point 4) flac and metaflac: main() calls setlocale(LC_ALL, ) which sets default system locale 5) Probably it's better to use local version of strtod() that accepts both comma and point as separators (just as FLAC uses local_strdup or flac_snprintf). ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] strtod/atof and locale
Some previous patches to fix locale-dependent atof/strtod: http://git.xiph.org/?p=flac.git;a=commitdiff;h=4e8fe85bceb245dfce07d1956b144e1cb6587c9f#patch2 http://git.xiph.org/?p=flac.git;a=commitdiff;h=aa285f3ac18a9825e9081af87545c8406e10f2d1 http://git.xiph.org/?p=flac.git;a=commitdiff;h=4b0f27011bba9fbbb2a7cae5325f6ada68c57a43#patch2 http://git.xiph.org/?p=flac.git;a=commitdiff;h=d75a07c968db0ec3d7e630c1080f9a8210f7c9b1#patch2 1) I don't understand the 3rd patch because both atof and strtod are locale-dependent 2) Patch 4 should fix the problem with flac tests but it doesn't work here on Windows platform + MinGW. I wrote earlier that make fullcheck fails on my computer but it's probably MinGW-specific. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] FLAC utilities for Monkey's Audio GUI: useful?
FLAC solution for MSVS contains two projects: flac_mac and flac_ren. They are intended to work together with Monkey's Audio GUI frontend ( http://www.monkeysaudio.com/images/screenshot.png ) as explained here: http://wayback.archive.org/web/20060428142919/http://flac.sourceforge.net/documentation.html#monkey Version 4.01b2 (February 17, 2006) still have out-of-box support for WavPack. Version 4.06 (March 17, 2009) doesn't have out-of-box support for 3rd-party codecs; I cannot find versions 4.02-4.05. The commit http://git.xiph.org/?p=flac.git;a=commit;h=34cc68f24abfab632ed211237a52aaa61270234a (22 Dec 2006) removes any mention about flac_mac.exe and flac_ren.exe from english html documentation. Russian docs were removed in 2013 as very outdated. I also suspect that Monkey's Audio GUI frontend isn't a very popular tool these days. So I propose to remove flac_mac and flac_ren from the sources because they became useless; just as in_flac was removed some time ago. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] FLAC utilities for Monkey's Audio GUI: useful?
Erik de Castro Lopo wrote: That makes sense. Unless anyone objects, I will remove these in a week's time. Patch for FLAC.sln attached. flac_mac.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] Bug: incompatibility with MSVS 2005
src/libFLAC/memory.c cannot be compiled with MSVS 2005 (and probably VS2008 too) after this commit: http://git.xiph.org/?p=flac.git;a=commitdiff;h=7cbecbae9f70be770f7651d09531fec0de6f9cf5 because MSVS2005 doesn't provide stdint.h. According to MSDN, uintptr_t is defined in STDDEF.H and other include files. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH for replaygain_synthesis
flac.exe crashes if I try to decode multichannel flac file with RG tags using the following command line: flac.exe -d --apply-replaygain-which-is-not-lossless test_6ch.flac The code in replaygain_synthesis project uses FLAC_SHARE__MAX_SUPPORTED_CHANNELS which is equal to 2. The fix just changes 2 to FLAC__MAX_CHANNELS. rg_crash.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH for fixed.c/fixed.h
Tests show that FLAC__fixed_compute_residual/FLAC__fixed_restore_signal are slightly faster when flac_restrict modifier is added to their arguments. (Encoding speed increase for flac -8 is about 2%. The difference is not very big yet measurable). fixed.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH for stream_decoder.c and stream_encoder.c
This patch adds/changes several comments ad slightly reorganizes the code that deals with SSE accelerated functions. No speed increases or decreases. stream_en_de_coder.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] PATCH for fixed.c/fixed.h
lvqcl wrote: Tests show that FLAC__fixed_compute_residual/FLAC__fixed_restore_signal are slightly faster when flac_restrict modifier is added to their arguments. (Encoding speed increase for flac -8 is about 2%. The difference is not very big yet measurable). Sorry, there was an error: encoding speed increase is about 0.5% for 32-bit encoder and ~0% for 64-bit. encoding speed increase is equal to 1.5-2% for 32-bit encoder compiled without -msse2 option (I commented out this string in configure.ac to do some other tests and forgot to revert this change). So, this patch makes little sense. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] Performance tests of the current version (git-b1b6caf)
Current sources (git-b1b6caf) were compiled with GCC 4.8.2 and GCC 4.9.0 with various -msseN options (the default is -msse2). Then I took two WAV files (one is 16-bit and the other is 24-bit) and compressed them using best compression mode. The results are in the table below. (please remember that the resulting value is an encoding time, not encoding speed) CPU: Intel Core i7 950 (up to SSE4.2) FLAC version: git-b1b6caf Encoding option: -8 Result: encoding time, seconds (less is better) --- 16 bit input -m option | 32 bit codec | 64 bit codec | GCC 4.8.2 | GCC 4.9.0 | GCC 4.8.2 | GCC 4.9.0 (none) |51.6 |35.5 | | sse2 |36.3 |33.7 |33.0 |30.8 ssse3|34.8 |33.9 |31.5 |30.8 sse4.1 |34.8 |33.5 |33.0 |29.4 --- --- 24 bit input -m option | 32 bit codec | 64 bit codec | GCC 4.8.2 | GCC 4.9.0 | GCC 4.8.2 | GCC 4.9.0 (none) |85.4 |46.4 | | sse2 |73.2 |44.8 |41.7 |40.5 ssse3|71.5 |45.2 |40.0 |40.4 sse4.1 |47.1 |44.8 |41.7 |40.8 --- ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH for replaygain_synthesis
The file src/share/replaygain_synthesis/include/private/fast_float_math_hack.h redefines 'tanh' as 'tanhf'. This file is intended for Intel Compiler only, but it includes outdated mathf.h and doesn't work with current versions of ICC. The fixes are trivial though, and I compiled 2 versions of flac.exe: with this 'hack' turned off an on. The difference in decoding speed is very close to measurement inaccuracy: for 32-bit encoder the decoding time decreases from 94.5s to 94.0s, for 64-bit it increases from 82.6s to 82.9s. (the option for this test was: --apply-replaygain-which-is-not-lossless=Ln0) So this hack is really useless today, and the first patch removes fast_float_math_hack.h from the sources. MSVS profiler shows that tanh calculation doesn't require too much CPU resources, the real problem is an integer division (int_64/int_32) in this line: val64 = dither_output_() / conv_factor; Since all possible values of conv_factor are powers of 2, it's possible to replace division with shift. The second patch does this. Decoding time decreases from 94.5s to 64.1s for 32-bit ICC compile, and from 82.6s to 50.0s for 64-bit ICC compile. * P.S. Actually, shift ( x n ) and division ( x / (1n) ) can give different results if x 0. The difference is very small though: WAV files differ by 1 LSB. And probably shift gives better results than division. Let's compare shift by 2 and division by (12) == 4: *** shift *** argumentresult 12, 13, 14, 15 -3 8, 9, 10, 11 -2 4, 5, 6, 7 -1 0, 1, 2, 3 -0 -4, -3, -2, -1 - -1 -8, -7, -6, -5 - -2 *** division *** argument result 12, 13, 14, 15 -3 8, 9, 10, 11 -2 4, 5, 6, 7 -1 -3, -2, -1, 0, 1, 2, 3 -0 -7, -6, -5, -4 - - -1 -11,-10,-9, -8 - - -2 So, shift results in small DC offset (1/2 LSB), division results in small 'nonlinearity' near 0. 1__remove_ffmhack.patch Description: Binary data 2__apply_gain.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] make fullcheck fails: strtod/atof and locale
Erik de Castro Lopo wrote: Does adding: export LANG=C LC_ALL=C to the top of the file test/test_grabbag.sh help? No. But all tests in test_grabbag.sh passed OK, it's test_flac.sh that fails. And test_flac.sh already have this 'export' command in the beginning. I found this page -- http://sourceforge.net/p/mingw-w64/bugs/307/ Quote: This is not a problem with mingw-w64 but a problem with setlocale() which we import from MS dlls. And indeed, flac.exe imports setlocale from MSVCRT.DLL. So no wonder that it's not fully POSIX compatible and doesn't care about environment variables. BTW, FLAC documentation (e.g. http://xiph.org/flac/documentation_tools_flac.html ) doesn't mention the fact that decimal separator is locale-dependent; IMHO this fact should be mentioned there. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] make dllimport/dllexport attributes work with mingw (and others)
Ozkan Sezer seze...@gmail.com писал(а) в своём письме Sat, 24 May 2014 10:16:15 +0400: - changes the _MSC_VER condition to universally _WIN32: MSVC, as well as GCC supports this. MSYS/MinGW 4.8.3, 4.9.0 can't compile code from git after this patch: format.c:47:22: error: variable 'FLAC__VERSION_STRING' definition is marked dllimport FLAC_API const char *FLAC__VERSION_STRING = VERSION; ^ format.c:47:22: warning: 'FLAC__VERSION_STRING' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] format.c:49:22: error: variable 'FLAC__VENDOR_STRING' definition is marked dllimport FLAC_API const char *FLAC__VENDOR_STRING = reference libFLAC VERSION 20130526; ^ format.c:49:22: warning: 'FLAC__VENDOR_STRING' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] ... ... FLAC_API_EXPORTS macro is defined in libFLAC_dynamic.vcproj, FLACPP_API_EXPORTS macro is defined in libFLAC++_dynamic.vcproj, but MinGW/GCC makefiles don't define them anywhere. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] make dllimport/dllexport attributes work with mingw (and others)
Erik de Castro Lopo wrote: Ozkan Sezer wrote: My apologies, obviously sent an old testing patch. Correct one is attached (declspec2.diff). Compilation tested using MinGW (gcc-3.4.5, binutils-2.20), and MinGW-w64 (gcc-4.5.4, binutils-2.21.90.) lvqcl, Can you please validate this new patch? It works, but only if i call ./configure without arguments. And it fails if i call ./configure with --disable-shared, --enable-static or both --disable-shared --enable-static. (If I use ./configure without arguments then flac.exe requires libFLAC-8.dll, which in turn requires libgcc_s_sjlj-1.dll. Adding --disable-shared makes flac.exe standalone: it doesn't need those libraries thst are foreign to Windows systems). ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] make dllimport/dllexport attributes work with mingw (and others)
Ozkan Sezer wrote: flac.exe built with mingw with or without the dllimport/dllexport patch always requires libFLAC-8.dll (because flac/Makefile.am has libFLAC.la in flac_LDADD and not libFLAC-static.la), and the patch doesn't make it any more or any less dependent on any 'foreign' dlls: the patch doesn't change the existent situation in that regard. If I'm missing something, please explain. I don't know how all this autoconf machinery works, but if I want to compile flac.exe that requires only system libraries (kernel32.dll and msvcrt.dll) then I simply use the following command: ./autogen.sh ./configure --enable-static --disable-shared make It worked earlier, and it works now with the current git sources. In this case libFLAC.la contains the following lines: # The name that we can dlopen(3). dlname='' # Names of this library. library_names='' # The name of the static archive. old_library='libFLAC.a' When ./configure is called without arguments, these lines contain: # The name that we can dlopen(3). dlname='libFLAC-8.dll' # Names of this library. library_names='libFLAC.dll.a' # The name of the static archive. old_library='' So libFLAC.la can point either to dynamic or to static library. * Also: your patch adds the following lines to several Makefile.am files: if OS_IS_WINDOWS win_utf8_lib = $(top_builddir)/src/share/win_utf8_io/libwin_utf8_io.la endif zzz_LDADD = ... $(win_utf8_lib) ... On my system win_utf8_io is always a static library and is statically linked to the libFLAC library, so it's not necessary to explicitly link flac.exe with libwin_utf8_io.la. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] Bug in FLAC or in GCC or somewhere else?
I noticed that 32-bit flac (from git) compiled with GCC 4.8.3 or 4.9.0 calculates incorrect ReplayGain values. The most common value it produces is -55.17 dB. It is possible to avoid this bug by compiling src/share/replaygain_analysis/replaygain_analysis.c a) either without -msse2 option b) or with -O2 instead of -O3 c) another solution is to add -mfpmath=sse option along with -msse2. For GCC 4.9.0 it's enough to add __attribute__ ((__target__ (arch=i686))) or __attribute__ ((__target__ (fpmath=sse))) to the following functions in replaygain_analysis.c: analyzeResult(), GetTitleGain() and GetAlbumGain(). Can anybody confirm this? ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] Typos in the FLAC codebase
1) src/share/grabbag/snprintf.c, line 42: 'on systems with a norrmal ISO C99' 'norrmal' - 'normal' 2) src/flac/encode.c, line 1661: '(eg, very short files, 1 fames)' 'fames' - frames? samples? bytes? 3) configure.ac, line 140: 'AM_CONDITIONAL(FLAC__CPU_X86_64, test x$cpu_x86_64 = xtrue)' Not sure about this, but other names inside AM_CONDITIONALs begin with FLaC__, not FLAC__. A quote from configure.ac: NOTE that for many of the AM_CONDITIONALs we use the prefix FLaC__ instead of FLAC__ since autoconf triggers off 'AC_' in strings. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Typos in the FLAC codebase
Erik de Castro Lopo wrote: 3) configure.ac, line 140: 'AM_CONDITIONAL(FLAC__CPU_X86_64, test x$cpu_x86_64 = xtrue)' Not sure about this, but other names inside AM_CONDITIONALs begin with FLaC__, not FLAC__. A quote from configure.ac: NOTE that for many of the AM_CONDITIONALs we use the prefix FLaC__ instead of FLAC__ since autoconf triggers off 'AC_' in strings. I this was was a bug in and earlier version of autoconf, but I fixed it anyway, just for the sake of uniformity. But such names (FLaC__NO_ASM, FLaC__CPU_IA32, FLaC__CPU_PPC, FLaC__USE_3DNOW, ...) begin with 'FLaC__' only in configure.ac. In all source files (.c, .h, .cpp) they begin with 'FLAC__' (all caps). ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Typos in the FLAC codebase
Erik de Castro Lopo wrote: But such names (FLaC__NO_ASM, FLaC__CPU_IA32, FLaC__CPU_PPC, FLaC__USE_3DNOW, ...) begin with 'FLaC__' only in configure.ac. In all source files (.c, .h, .cpp) they begin with 'FLAC__' (all caps). Is this possibly the cause of the issue you mentioned in the email titled Bug in FLAC or in GCC or somewhere else?. I don't think so. This bug can be fixed by replacing -O3 by -O2, so preprocessor macros don't matter. Also the problem disappears if I add printf(elems = %u, elems); just before upper = (Int32_t) ceil (elems * (1. - RMS_PERCENTILE)); ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Two questions about RG in flac
Ozkan Sezer wrote: With gcc-3,3,6, 3,4,6, 4.3.0 and gcc-4.9.1 (svn r210839) the output is normal: Sum = 64.00 (should be equal to 64) With gcc-4.8.3 (release version) it's broken: Sum = 206158430272.00 (should be equal to 64) With clang-3.4.1 (compiled with gcc-4.8.3) the output is normal again. This is on i686-linux (fedora9, glibc-2.8, kernel-2.6.27.35) Thank you for testing. However, I compiled my test with gcc 4.9.1 20140604 from dongsheng-daily ( http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/dongsheng-daily/4.9/ , file gcc-4.9-win32_4.9.1-20140604.7z) and it still fails... ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Two questions about RG in flac
Robert Kausch wrote: The problem seems to be that sum is interpreted as a 64 bit value if SSE2 was used in the loop (the lower 32 bits of the result give the expected value). If sum is evaluated another time before or after (!) the printf, the problem goes away. For example, changing the last line to return sum + 1; lets the problem disappear. I confirmed the bug with GCC 4.6.3 on Ubuntu. As on Windows, only 32 bit code generation is affected. Thank you for testing. You should file a bug report with the GCC team. Done: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61423 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Typos in the FLAC codebase
Erik de Castro Lopo wrote: 3) configure.ac, line 140: 'AM_CONDITIONAL(FLAC__CPU_X86_64, test x$cpu_x86_64 = xtrue)' Not sure about this, but other names inside AM_CONDITIONALs begin with FLaC__, not FLAC__. A quote from configure.ac: NOTE that for many of the AM_CONDITIONALs we use the prefix FLaC__ instead of FLAC__ since autoconf triggers off 'AC_' in strings. I this was was a bug in and earlier version of autoconf, but I fixed it anyway, just for the sake of uniformity. IMHO for the sake of uniformity it's better to revert this commit http://git.xiph.org/?p=flac.git;a=commit;h=151739921b74fbf31420358a5fbeb094efa017ed because before it there was only one place of non-uniformity: line 140 in configure.ac, now there are several .c and .h files with all-caps FLAC__*** (FLAC__CPU_IA32, FLAC__HAS_NASM, FLaC__HAS_OGG) and suddenly FLaC__CPU_X86_64. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PATCH: workaround for a GCC bug #61423, second version
Patch A: (gccbug-v2-a.patch) It replaces fp code with integer. Basically it changed ceil(x * (1.-0.95)) with (x/20 + x%20?1:0). This also slightly changes calculated RG value, so test_replaygain.sh was also updated. Why RG value differs? Because double(1.-0.95) double(0.05). If x==20 then ceil(x * (1.-0.95)) == 2, while ceil(x * 0.05) == 1 and (x/20 + x%20?1:0) == 1. So the new code behaves differently than the old. But IMHO the new behavior is more correct than the old one. Patch B: (gccbug-v2-b.patch) It adds -mfpmath=sse option to configure.ac after -msse2 option. Should fix the bug according to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61423#c2 According to my tests, it doesn't affect encoding speed. Any of the two patches fix the problem here, so choose the better... but I'd like to see both of them applied, just in case. gccbug-v2-a.patch Description: Binary data gccbug-v2-b.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] R128gain metaflac
Olav Sunde wrote: has anyone looked at adding R128gain code to metaflac so we can select to use this calculation for RP tags rather than replay gain? Why metaflac only? flac is also able to calculate RG values. And, as far as I can see R128GAIN (http://r128gain.sourceforge.net/) is a standalone app, not a library. So probably it would be difficult to reuse its code in flac/metaflac. There is also libebur128 (https://github.com/jiixyj/libebur128/) - libebur128 is a library that implements the EBU R 128 standard for loudness normalisation. All source code is licensed under the MIT license; foobar2000 uses it to calculate ReplayGain values. The use of R128 also raises the question about REPLAYGAIN_REFERENCE_LOUDNESS tag. Currently flac/metaflac writes REPLAYGAIN_REFERENCE_LOUDNESS=89.0 dB but doesn't use it when decoding (it seems that nothing uses this tag). R128 defines reference level differently, so this tag makes little sense for it. IMHO it's better not to write this tag when (meta)flac uses R128 algorithm. (David Robinson, the author of ReplayGain, thinks that such tags are useless: http://www.hydrogenaud.io/forums/index.php?s=showtopic=67823view=findpostp=603622) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
