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
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)
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
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
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
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 -
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 @@
#
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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) {
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
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
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
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
___
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
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
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
Барт Гопник 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
Барт Гопник 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
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
Барт Гопник 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
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
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:
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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.
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
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.
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
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
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
___
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
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
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
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
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:
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
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
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
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
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
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
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 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
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 --
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
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
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
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
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 =
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
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
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
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
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
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
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
1 - 100 of 403 matches
Mail list logo
