similar to: better seeking

Ok, the patch from 2003 about improving seeking still didn't make it to CVS, so here is another try. I made some benchmarking with the test_seeking utility from flac sources to show how bad the current seeking is, especially without seektable. Track used for the experiment had about 50 minutes. In the following table is average number of seeks and number of decoded frames required for one

Ok, here is a patch waiting for new CVS :). It works fine for me, but please check it before commiting... -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/bitbuffer.c.orig 2003-01-30 17:36:01.000000000 +0100 +++ src/libFLAC/bitbuffer.c 2003-01-30 21:53:18.000000000 +0100 @@ -51,6 +51,25 @@ */ static const unsigned FLAC__BITBUFFER_DEFAULT_CAPACITY = ((65536 - 64) *

On Mon, Jan 24, 2005 at 06:31:21PM -0800, Josh Coalson wrote: > yes, a mere 2 years later it is checked in! > > speed improvement for me is roughly 17% testing flac files on > linux-i386. Thanks! In case you would like to check another old patch, I have attached updated patch for seekable stream decoder, originally posted on 09/07/2003. -- Miroslav Lichvar -------------- next

On Mon, Oct 30, 2006 at 11:13:25AM -0800, Josh Coalson wrote: > my apologies for not doing this before Miroslav... I will definitely > integrate it this time. Thanks. Sending latest version of the patch. Now it can seek in files that have large id3 tag (or any random data) at the end and it won't loop on streams with shuffled frames. -- Miroslav Lichvar -------------- next part

Hello everyone! Can we add low-level seek functions into libFLAC? I'm using libFLAC in a program where file operations can't be completed synchronously from those user callback procedures that libFLAC calls when it needs to perform read, seek, etc. So I had to modify libFLAC in a way that it doesn't call any user callbacks while performing seeking. Although I added a dirty hack for

Anybody knows the reason for the following code (you can see it in flac/decode.c, flac/encode.c, libFLAC/fixed.c and libFLAC/stream_decoder.c) ? #if defined _MSC_VER || defined __MINGW32__ /* with MSVC you have to spoon feed it the casting */ residual_bits_per_sample[0] = (FLAC__float)((total_error_0 > 0) ? log(M_LN2 * (FLAC__double)(FLAC__int64)total_error_0 /

Erik de Castro Lopo wrote: > That's a really good question. Haven't was already dropped support for > MSVC6? If so, we should drop this #ifdef hackery. Can test this without > the hackery for versions of MSVC > 6? I don't have VC 2002/2003, but the oldest Visual Studio that FLAC supports is MSVS 2005 anyway. It can compile FLAC__uint64 -> FLAC__double conversion

I've upgraded to FLAC 1.1.3, and now I have some streams where seek does not work anymore, but they used to work before. After a bit of debugging, it looks like those streams (created a long time ago with an old version of FLAC) have a seek table where all the entries have a stream offset of 0. The result is that in the function seek_to_absolute_sample_, on line 3076 (file

ok, tried it out... passes test/test_seeking.sh and my "xmms twitch" test, checked in to CVS. thanks! Josh --- Miroslav Lichvar <lichvarm@phoenix.inf.upol.cz> wrote: > On Fri, Nov 03, 2006 at 10:01:42AM +0100, Miroslav Lichvar wrote: > > Thanks. Sending latest version of the patch. Now it can seek in > files > > that have large id3 tag (or any random data) at

And here is another one. It allows fast seeking in streams without total_samples information. There is a check for such streams in flac, so flac --skip doesn't work. If the check is removed, it will work with --force-raw-format only, there is an issue with wav and aiff header handling. -- Miroslav Lichvar -------------- next part -------------- ---

Christian Weisgerber <naddy@mips.inka.de> wrote: > #0 0x0000000040d18810 in FLAC__lpc_compute_residual_from_qlp_coefficients_wide > (data=0x49e4c014, data_len=110, qlp_coeff=0x7f7ffffece70, order=1, > lp_quantization=14, residual=0x4fced000) at lpc.c:745 > 745 residual[i] = > data[i] - (FLAC__int32)((qlp_coeff[0] *

seek_barrage() has variable n of type long int (which is 32bit usually). Then we see something like n = (long int)total_samples; So, why n has type long int, and not FLAC__int64 or some other 64-bit type?

--- include/share/compat.h | 8 ++++++++ src/flac/main.c | 37 +------------------------------------ src/share/grabbag/seektable.c | 31 +------------------------------ 3 files changed, 10 insertions(+), 66 deletions(-) diff --git a/include/share/compat.h b/include/share/compat.h index e9ac958..ff5c8af 100644 --- a/include/share/compat.h +++ b/include/share/compat.h

Hi, This patch improves compression a very tiny bit on average, but up to 0.1 percentage point for classical music. I haven't found any tracks that show worsening compression with this patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Improve-LPC-order-guess.patch Type: text/x-patch Size: 0 bytes Desc: not available Url :

Running the basic (--disable-thorough-tests) test suite, I get these failures round-trip test (rt-1-24-111.raw) encode... Segmentation fault (core dumped) ERROR FAIL: ./test_flac.sh fsd24-01 (--channels=1 --bps=24 -0 -l 16 --lax -m -e -p): encode...ERROR during encode of fsd24-01 FAIL: ./test_streams.sh on alpha and amd64. By contrast, i386 is fine. (All OpenBSD/4.2.) Could be a generic LP64

--- Miroslav Lichvar <lichvarm@phoenix.inf.upol.cz> wrote: > On Sat, Nov 09, 2002 at 06:02:33PM +0100, Miroslav Lichvar wrote: > > On Fri, Nov 08, 2002 at 07:12:35PM -0800, Josh Coalson wrote: > > > Yeah, it's useful, so now there is a > > > FLAC__seekable_stream_decoder_get_decode_position() and > > > FLAC__file_decoder_get_decode_position(). I

Hello! As I understand, there is versions of FLAC for Linux x64. Such question, whether is native x64-86 versions for OS Windows? Best regards, Valentin.

--- Miroslav Lichvar <lichvarm@phoenix.inf.upol.cz> wrote: > On Mon, Nov 06, 2006 at 08:50:44AM -0800, Josh Coalson wrote: > > ok, tried it out... passes test/test_seeking.sh and my > > "xmms twitch" test, checked in to CVS. thanks! > > Thanks! > > I see you have changed the channels and bps setting, this doesn't > work > when the decoder

This commit will break OS/2's EMX 0.9d library (GCC 2.8.1) which has been been replaced by klibc. Considering the age of EMX and lack of testing and that klibc contains so many improvements I think this is exceptable. --- include/FLAC/ordinals.h | 17 +++++++++-------- src/flac/main.c | 2 +- src/libFLAC/metadata_iterators.c | 2 +-

On Fri, Nov 08, 2002 at 07:12:35PM -0800, Josh Coalson wrote: > Yeah, it's useful, so now there is a > FLAC__seekable_stream_decoder_get_decode_position() and > FLAC__file_decoder_get_decode_position(). I haven't documented > them yet but you can see an example in > src/metaflac/operations_shorthand_seektable.c where I use it > during seektable creation. Ok, here is