similar to: Disk fragmentation

On 12/10/2015 5:58 PM, lvqcl wrote: > Erik de Castro Lopo wrote: >> lvqcl, >> >> Would you be able to have alook at this one? I think its >> Windows related: >> >> https://sourceforge.net/p/flac/feature-requests/114/ >> > > The relevant changes are >

Erik de Castro Lopo wrote: > lvqcl, > > Would you be able to have alook at this one? I think its > Windows related: > > https://sourceforge.net/p/flac/feature-requests/114/ > The relevant changes are <http://git.xiph.org/?p=flac.git;a=commitdiff;h=6a6207b52a86b1d7980a5233e297c0fc948bed7d> and

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

In 2007, user reported a segfault in FLAC::Encoder::File::progress_callback() when called from ~Stream(). Original report at https://sourceforge.net/p/flac/bugs/256/ Hello! Sorry, english is not my best language. I use libFLAC++ API. I have some problems. In libFLAC API all OK. Unhandled exception at 0x00000000 in Test.exe: 0xC0000005: Access violation reading location 0x00000000. Call stack

The underscores are wrong. The comment is also correct. Also remove the configure.ac option. Otherwise it tries to compile the windows unicode stuff which POSIX(cygwin) does not understand. --- configure.ac | 2 +- include/share/compat.h | 2 +- src/libFLAC/stream_decoder.c | 3 --- src/libFLAC/stream_encoder.c | 3 --- src/share/grabbag/file.c | 8 +------- 5 files

lvqcl wrote: > IMHO it's better to move setvbuf() out of libFLAC/stream_encoder.c > into flac/encode.c. Why do you thing that is better? > I can see two ways to do this: > > 1) Add a new function to libFLAC API that have access to > encoder->private_->file and can call setvbuf: > > FLAC_API FLAC__bool FLAC__stream_encoder_set_buffer_size(FLAC__StreamEncoder

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

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

Hi List, I recently was assigned a task to port FLAC Encoder to our embedded platform. Thanks to OO-like design of the libFLAC and throught documentation, that porting went like a charm. I had some problems with chmod/chown like routines while porting but I was able to safely remove that piece of code without any trouble. I have observed that the my application FLAC Encoder failes in

Miroslav Lichvar wrote: > Hm, does this mean that every process encoding FLAC files will now > need extra 10MB of memory? Is that ok for small devices with limited > memory? What small device do you have in mind? The smallest device I could possibly imagine *encoding* FLAC on is Rasberry Pi which has 512Meg of RAM. If you really are concerned about this (and knowing that it has little

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 >

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:

During my current dealings with the FLAC library I think I discovered a memory leak. After an encoder stream has finish()'ed, I believe you are supposed to use it again by calling init(). However, when verification is enabled, the init() routine will create a new stream decoder (to verify the data) without deleting (or reusing) the existing one. A small program demonstrating this is pasted

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

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