similar to: PATCH: use restrict keyword to make en/decoding faster

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:

Hello, Apologies if this has been done before. I just joined the list as this has bugged me for a while. I can compile FLAC 1.1.2 using Visual C++ 6.0 with no problems. However, when I try to compile the CVS source I get: Linking... utils.obj : error LNK2001: unresolved external symbol _snprintf grabbag_static.lib(stream_decoder.obj) : error LNK2001: unresolved external symbol

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. -------------- next part -------------- A non-text attachment was scrubbed... Name: lpc-msvs-warnings.patch Type: application/octet-stream Size: 1025 bytes Desc: not available Url :

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). -------------- next part -------------- A non-text attachment was scrubbed... Name: fixed.patch Type: application/octet-stream Size: 2503 bytes Desc:

I have been running a lot of large compression tests to see how well Martijn van Beurden's new presets do and was once again reminded how real the fragmentation problem still is. To have decent speed it's necessary to run multiple encoders in parallel. In my setup FLAC was compressing four files at the same time and each instance writes tiny bits of data to disk at once. A

Hi, I've been trying to use the FLAC lib for c++. I need to implement basic encoder function in my application, so i tried to include encoder.h , set everything to the default path, and included stream_encoder.cpp,stream encoder.cpp files in the project. Include is #include "FLAC++/encoder.h" i write something like this FLAC::Encoder::File test; i build, compile goes ok but then

> Oliver St?neberg wrote: > > > I finally got around to trying to update FLAC for the MAME/MESS > > project again. There were several issues I was able to fix and will > > submit patches later, but I hit one roadblock with GCC and clang: > > > > src/lib/libflac/libFLAC/stream_encoder.c:1696:43: error: cast from function call > > of type

Pulled from my Arch archive, this following patch seems to have made quite a difference in getting my ARM7TDMI chip to play FLAC (compression levels 0-2) on my ipod. I don't have benchmarks with hard numbers, but playing with skips vs playing without skips is a fairly noticeable difference. memcpy and memset on uClibc are optimized in asm for the ARM7TDMI in uClibc. Other hardware/libc

Hi, I finally got around to trying to update FLAC for the MAME/MESS project again. There were several issues I was able to fix and will submit patches later, but I hit one roadblock with GCC and clang: src/lib/libflac/libFLAC/stream_encoder.c:1696:43: error: cast from function call of type 'double' to non-matching type 'FLAC__int32' (aka 'int')

In the precompute_partition_info_sums_ function, instead of selecting 64-bit accumulator when the signal bps is larger than 16, revert to the original approach based on partition size, but make room for few extra bits to not overflow with unusual signals where the average residual magnitude may be larger than bps. It slightly improves the performance with standard encoding levels and 16-bit files

Or, I was originally thinking: rice_parameter = 0; k = partition_samples; if (k < mean) { int n = mean - k; rice_parameter += n; k <<= n; } (sorry for the hasty post) On Oct 11, 2013, at 10:34, Brian Willoughby wrote: > Hmm, maybe I'm missing something, but what about this: > > rice_parameter = 0; k = partition_samples; > int n = mean - k; > if (n >

stream_encoder.c has the following code: /* try to keep qlp coeff precision such that only 32-bit math is required for decode of <=16bps streams */ if(subframe_bps <= 16) { ... But FLAC can convert 16-bit input to 17-bit if mid-side coding is used. So, does it make sense to compare subframe_bps with 17? (The patch is attached. What do you think about it?) -------------- next part

Hi all, I was investigating the behaviour of the -p switch of flac. This switch should enable exhaustive search for the optimal qlp coefficient precision, but the resulting files are usually 0.5% larger then when not using the switch. I stumbled upon this code in stream_encoder > if(encoder->protected_->do_qlp_coeff_prec_search) { > min_qlp_coeff_precision =

Hi all, I am interested in building a stand alone Rice Encoder/Decoder, using FLAC source code as a starting point. I've read the theory behind it, and I am very interested in info theory. However, I am struggling with how exactly I would implement the theory in code. I'm a newbie to computer science (only 1 year experience). I have read the format and documentation links on the FLAC

Hi, We are using the libFLAC++ library to encode FLAC files with Vorbis comments in them and have had the FLAC 1.1.2 version fail consistently (access violation or segmentation fault) on both Windows and Linux. We tracked this down to the metadata code in the C++ API. The problem is in src/libFLAC++/file_encoder.cpp. There are two problems - firstly, a C-style cast is hiding a bad conversion

Martijn van Beurden <mvanb1 at gmail.com> ?????(?) ? ????? ?????? Wed, 24 Sep 2014 16:09:38 +0400: > Well, from the code it's clear that quite some effort was put > into making libFLAC usable on platforms that have no FPU, as > there is a integer-only define that actually works. I could > think of small handheld recorders like the Zoom H1 or something > like that to use

This patch adds two AVX2 files and adds AVX2 support code into init_stream_internal_() in stream_encoder.c. -------------- next part -------------- A non-text attachment was scrubbed... Name: 05_avx2.zip Type: application/zip Size: 7279 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20141003/1471b3d6/attachment-0001.zip

In stream_encoder.c there's the following code: #if defined FLAC__CPU_X86_64 /* and other 64-bit arch, too */ if(mean <= 0x80000000/512) { /* 512: more or less optimal for both 16- and 24-bit input */ #else if(mean <= 0x80000000/8) { /* 32-bit arch: use 32-bit math if possible */ #endif A) How to properly check for 64-bit architectures? I can check for "defined

On Thu, Jun 19, 2014 at 03:30:22PM +0400, lvqcl wrote: > BTW, what can you say about the following place in stream_decoder.c > in read_subframe_lpc_() function: > > /*@@@@@@ technically not pessimistic enough, should be more like > if( (FLAC__uint64)order * ((((FLAC__uint64)1)<<bps)-1) * ((1<<subframe->qlp_coeff_precision)-1) < (((FLAC__uint64)-1)

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) aaaaa; else #endif #ifdef FLAC__SSE2_SUPPORTED bbbbb; #endif This code is correct because if FLAC__SSSE3_SUPPORTED is defined then FLAC__SSE2_SUPPORTED is