Erik de Castro Lopo wrote:
> I have committed an improvement on the above fix.
>
>
> https://git.xiph.org/?p=flac.git;a=commit;h=f34f31dac0032887887b5bbcb0944de055b757d0
>
> that reverts to the use of a FLAC_uint32 accumulator for files of less
> than 24 bits per sample.
>
> I still have no p
Recently I downloaded MSVC++2005 Express Edition and it turns out that it
wasn't possible to compile all files without several changes:
1) FLAC.sln has one extra "EndProject" line
--- a\FLAC.sln 2013-06-17 11:57:09.0 +0400
+++ b\FLAC.sln 2013-08-16 20:19:34.630486700 +0400
@@ -157,7 +1
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
#endif
+#if defined(_MSC_VER)
+#define _U
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 +7
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_ma
Erik de Castro Lopo 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 wit
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 - __
Martijn van Beurden wrote:
> As the changes necessary to keep everything working with 2005 are
> minimal (AFAIK only the third part of the patch lvqcl submitted is MSVC
> 2005 specific)
Yes, exactly: compat.h redefines restrict as __restrict, but only for VS 2005
and older. Unfortuna
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 @@
# ifd
libFLAC have three SSE-accelerated functions
FLAC__lpc_compute_autocorrelation_asm_ia32_sse_lag_N (N = 4, 8, 12). They
require lpc_order less than N.
The best compression preset (flac -8) uses lpc_order up to 12; it means that
during encoding FLAC also uses unaccelerated C function.
I'm not ver
Erik de Castro Lopo wrote:
Unfortunately this patch doesn't apply. How was it generated? Would it be
possible to send a patch generated by Git because those usually do work.
Erik
I'm not very familiar with git... I hope that now I did everything correctly.
The patch is in the attachment.
Erik de Castro Lopo wrote:
> Patch applied, tested, commited and pushed.
Great.
But, what about my other patches? I admit that many of them aren't necessary,
but (imho) a couple of them are important. I can explain in detail why I think
this.
___
fla
Erik de Castro Lopo 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. Onl
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
A preprocessor macro FLAC__ALIGN_MALLOC_DATA is defined in Makefiles but absent
in *.vcproj files. This patch adds it to libFLAC_static.vcproj and
libFLAC_dynamic.vcproj.
align_malloc.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@x
This patch fixes output directory for plugin_common_static.vcproj and
test_libs_common_static.vcproj
static_lib.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
All MSVC projects that generate .lib files have '_static' suffix in their
names; all but win_utf8_io.
This patch renames it so that it follows this naming convention.
win_utf8_static.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xip
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
More or less detailed explanation of this patch.
1. The first parameter of _BitScanReverse() and _BitScanReverse64() is a
pointer to unsigned long (4-byte int). However _BitScanReverse64() is called
with a pointer to FLAC__uint64 (8-byte int). IMHO it's a bug and this patch
changes the type o
Erik de Castro Lopo 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
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
lvqcl писал(а) в своём письме 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. He
Ulrich Klauer 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
A newer version of bitmath patch. It also replaces 'de Bruijn sequences' code
with calls to 32-bit intrinsics.
bitmath_v2.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:
>> 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
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_X86INTR
I try to make my code more clean and have a few questions:
1. GCC related: MinGW contains cpuid.h header file that defines __get_cpuid()
function. Is it standard? Or is it better to use inline asm to get cpuid info?
2. Is it good idea to do mаnual loop unrolling?
Unrolling FLAC__lpc_compute_autoc
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 .
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 wrote:
> The biggest of these tweaks weas to disable the intrinsics version
> fero FLAC__CPU_IA32 because I couldn't get this to compile on
> i386-linux (and we have the nasm versions). Still open to re-enabling
> this if someone can get it to work.
I know you're a skilled p
Erik de Castro Lopo 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 great
Erik de Castro Lopo 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
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 -mss
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 thin
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.
It seems that GCC creates inefficient code for 32bit * 32bit -> 64bit
multiplication
for 32-bit architecture. This problem affects
FLAC__lpc_compute
Martijn van Beurden писал(а) в своём письме 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.
>
> Str
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-de
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
fla
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
http://lists.xiph.org/mailman/li
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 f
With current settings, MSVS links debug version of flac.exe (and other .exe and
.dll files) with the release version of libogg_static.lib. MSVS issues a
"warning LNK4098: defaultlib 'libcmt.lib' conflicts with use of other libs; use
/NODEFAULTLIB:library"
What's the reason in this setting?
Wha
Ralph Giles wrote:
>> With current settings, MSVS links debug version of flac.exe (and other
>> .exe and .dll files) with the release version of libogg_static.lib.
>> MSVS issues a "warning LNK4098: defaultlib 'libcmt.lib' conflicts with use
>> of other libs; use /NODEFAULTLIB:library"
>
> Sounds
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 t
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
> yo
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 comma
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 pres
Erik de Castro Lopo wrote:
> Googling suggests that use of restrict is a little controvertial.
Maybe, but Opus encoder uses this keyword in its en-/decoding routines.
So I think it's not dangerous.
> Also, do you have any idea why this causes such a slow down in VS10 and
> VS12?
Without __restr
This patch adds flac_restrict to share/compat.h and adds it to
arguments of ...lpc_compute_residual...()/...lpc_restore_signal...() functions.
As a result,
FLAC__lpc_compute_residual_from_qlp_coefficients_wide_intrin_sse41()
now offers no advantage for 64-bit compiles and was removed from x86-64
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 it's
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
Erik de Castro Lopo wrote:
>> #define FLAC__U64L(x) x##ULL
>
> I like that one! If that works in VS2005 and later I see no reason to use
> anything else.
MSVS 2005 Express compiles the code...
#define FLAC__U64L(x) x##ULL
int test = FLAC__U64L(0x1234567890);
... and generates 0 errors, 2 warnin
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
___
flac-d
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
a
Currently the only way to compile FLAC using GCC w/o SSE support
is to disable asm optimizations (see configure.ac):
if test "x$asm_optimisation" = "xyes" ; then
XIPH_ADD_CFLAGS([-msse2])
fi
Also it's not possible to enable SSE4.1 intrinsic functions even
Erik de Castro Lopo wrote:
> I'l do a little more testing on this and the other patches before pushing
> to git.
According to my tests, the speed increase after the patch that changes
"call .get_eip0 / pop eax" to "call .mov_eip_to_eax / mov eax, [esp] / ret"
is negligible or absent.
OTOH, libFL
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.
Барт Гопник 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:
> "--best" preset is designed for highest compression, not for faster
> compression, isn't it?
>
IMHO it just means "highest reasonable", not "highest theoretically possible".
And please answer to the mailing list, not to me ditectly.
Барт Гопник 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.
___
Барт Гопник wrote:
> Yes, using "-p" and "-A" or more than one "-A" (up to 32) switches is
> really unreasonable, because using them very greatly increase the
> encoding time. But I did some tests and found that using "-r 8"
> instead of "-r 6" NOT greatly increase the encoding time (one of my
> t
>> 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
Барт Гопник 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 cla
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)
summ
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 suppo
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/
This patch adds RESIDUAL16_RESULT macro (analogous to the existing
RESIDUAL_RESULT macro).
It simplifies the code a little.
lpc_sse2.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-
It turns out that int64 shift is quite slow...
This patch changes the code from:
(FLAC__int32)(xmm.m128i_i64[0] >> lp_quantization)
into:
_mm_cvtsi128_si32(_mm_srli_epi64(xmm, lp_quantization));
Encoding of 24-bit .wav files with 32-bit FLAC became noticeably faster.
The new cod
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
http://lists.x
Erik de Castro Lopo wrote:
I think you forgot to attach the patch for this one :-).
Oops.
fast_shift.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Is Nasm always available when the target architecture is IA-32?
For example, FLAC has FLAC__lpc_compute_autocorrelation_asm_ia32_sse_lag_NN()
functions
that require NASM presence, and
FLAC__lpc_compute_autocorrelation_intrin_sse_lag_NN()
functions that require x86 intrinsics support.
FLAC makes
Git version of the FLAC encoder prints error message:
ERROR: Compression failed (ratio 1.xyz, should be < 1.0). Please contact the
developers.
in the following cases:
a) recompressing from FLAC 1.2.1 (sometimes)
b) encoding very short wav files (around 5k samples)
c) encoding white noise test si
Erik de Castro Lopo wrote:
> Does that explain it?
Sure. But maybe it makes sense to write "WARNING" instead of an "ERROR"?
Or to compare compress ratio with 1.01 (or 1.05 or 1.1) instead of 1.0?
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.
Erik de Castro Lopo wrote:
>> Sure. But maybe it makes sense to write "WARNING" instead of an "ERROR"?
>
> Well its an ERROR because the flac executable will exit with a non-zero
> exit code, so this condition can be caught in for example a shell script.
>
> If its only a warning, why would the ex
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/fla
MSVS profiler shows that the encoder spends too much time inside format_input()
when the input is 24-bit. The attached patch increases encoding speed:
FLAC -5: from 27.1 to 24.2 seconds
FLAC -8: from 76.2 to 73.1 seconds
(MSVS 2010, 32-bit flac.exe, 24-bit stereo input file)
For GCC compiles the
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:
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
__
Fixes typos in comments in these two files.
typo.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
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/mai
Erik de Castro Lopo wrote:
Applied with minor reformatting.
Thanks. And btw, about reformatting: currently stream_encoder.c contains the
following code:
#ifdef FLAC__SSSE3_SUPPORTED
if(encoder->private_->cpuinfo.ia32.ssse3)
a;
else
#endif
#ifdef FLAC__SSE2
There was a commit "Fall back to intrinsics if NASM is not available"
(
http://git.xiph.org/?p=flac.git;a=commit;h=d163ef456797ef4807138b0ecb5da9ff05e147e2
)
But CPU detection code for IA-32 uses ASM code, and cpuinfo.use_asm == false
when NASM isn't available. The attached patch fixes it. Now
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
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
mov{
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 prob
The second version of the patch for OS SSE support detection
part 1: fixes
part 2: new code
Any comments?
cpu_part1.patch
Description: Binary data
cpu_part2.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xip
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...
questionab
Martijn van Beurden wrote:
> FLAC already wasn't working on Windows 98 and older because of
> the UTF-8 implementation that was merged for flac 1.3.0, so no
> one will care I guess.
Very interesting.
Indeed, Dependency Walker shows that flac.exe generated by MinGW
uses two *W functions: CreateFil
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
1 - 100 of 556 matches
Mail list logo
