search for: lvqcl

...flac-dev-owner at xiph.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of flac-dev digest..." > > Today's Topics: > > 1. 1.21 vs 1.3 encoding speed (Scott Brown) > 2. Re: 1.21 vs 1.3 encoding speed (lvqcl) > 3. Re: 1.21 vs 1.3 encoding speed (Scott Brown) > > > ---------- Forwarded message ---------- > From: Scott Brown <scottcbrown at gmail.com> > To: flac-dev at xiph.org > Cc: > Date: Fri, 25 Jul 2014 07:39:59 -0400 > Subject: [flac-dev] 1.21 vs 1.3 encoding spe...

There's an entry in the changelog: "Improved decoding efficiency of all bit depths but especially so for 24 bits (lvqcl)" A couple of comments: 1) The patch that improves encoding for all depths was proposed by Miroslav Lichvar <http://git.xiph.org/?p=flac.git;a=commit;h=4eab6313cd2198b5647d925bdb3847590505fa21> 2) "Performance checks" graph posted by Martijn van Beurden reminded me that the...

...You can reach the person managing the list at > flac-dev-owner at xiph.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of flac-dev digest..." > > Today's Topics: > > 1. [PATCH] for Darwin asm compile (lvqcl) > 2. Re: [PATCH] for Darwin asm compile (Ozkan Sezer) > > > ---------- Forwarded message ---------- > From: lvqcl <lvqcl.mail at gmail.com> > To: flac-dev at xiph.org > Cc: > Date: Sun, 12 Jun 2016 17:40:53 +0300 > Subject: [flac-dev] [PATCH] for Darwin asm comp...

lvqcl wrote: > I have a couple of questions: > > 1) Do you plan to release 1.3.1 pre1, pre2 etc or just 1.3.1 w/o any pre-releases? I had not planned to do a pre-release. > 2) Do you plan to release any official binaries (flac, metaflac, maybe something else)? Nor had I planned to releas...

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.000000000 +0400 +++ b\src\libFLAC\cpu.c 2013-08-16 21:46:42.177485300 +0400 @@ -285,14 +285,7 @@ # ifdef USE_TRY_CATCH_FLAVOR _try { __asm { -# if _MSC_VER <= 1200 - /* VC6 assembler

On Fri, Jun 20, 2014 at 1:05 AM, lvqcl <lvqcl.mail at gmail.com> wrote: > I cannot find anything about the size of METADATA_BLOCK_PICTURE block > in <http://xiph.org/flac/format.html>. Where did you read this? > METADATA_BLOCK_HEADER has a 24-bit field to encode the length of METADATA_BLOCK_DATA ; hence the limita...

...reach the person managing the list at > flac-dev-owner at xiph.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of flac-dev digest..." > > Today's Topics: > > 1. Re: PPC asm is disabled since Jan 2005 (lvqcl) > > > ---------- Forwarded message ---------- > From: lvqcl <lvqcl.mail at gmail.com> > To: flac-dev at xiph.org > Cc: > Date: Sun, 20 Jul 2014 13:55:57 +0400 > Subject: Re: [flac-dev] PPC asm is disabled since Jan 2005 > lvqcl wrote: > > During making a pat...

1) in config.h FLAC__HAS_X86INTRIN macro is always defined and empty, even if x86intrin.h is not available. 2) sse_os is defined as 'yes' or 'no', but AM_CONDITIONAL tests it for 'true': AM_CONDITIONAL(FLaC__SSE_OS, test "x$sse_os" = xtrue) It seems that it should be changed to AM_CONDITIONAL(FLaC__SSE_OS, test "x$sse_os" = xyes) 3) configure

Thomas Zander wrote: > If you want to share the patch, I am happy to repeat some testing on > Sandy Bridge and Core2 with clang. The patch changes many files, libFLAC/bitwriter.c and test_libFLAC/bitwriter.c among them. So now I wait for the decision for patches #3 and #4 that I posted yesterday. > The slower decoding speed for 24 bit content on x86_64 seems > surprising, but

Hugo Beauzée-Luyssen wrote: >> configure.ac: Allow the programs to be disabled >> configure.ac: Allow bench to be disabled >> configure.ac: Don't build any tests when they are explicitely disabled >> configure.ac: Allow examples to be disabled >> win_utf8_io: Avoid forbidden functions when building for WinRT/UWP >> >> configure.ac

The patch does the following: 1. splits lpc_x86intrin.c to lpc_intrin_sse.c and lpc_intrin_sse2.c 2. adds FLAC__lpc_compute_residual_from_qlp_coefficients_intrin_sse2() function to lpc_intrin_sse2.c 3. adds lpc_intrin_sse41.c with two ..._wide_intrin_sse41() functions (useful for 24-bit en-/decoding) 4. adds precompute_partition_info_sums_intrin_sse2() / ...ssse3() and disables

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,19,16, 7,26,12,18, 6,11, 5,10, 9 }; FLAC__uint32 v; int m;

On Dec 14, 2014, at 10:02 AM, lvqcl <lvqcl.mail at gmail.com> wrote: > Currently the header of a decoded WAV file can be different to the > original WAV file because FLAC doesn't preserve 'fmt ' chunk. > > For example: create a 24-bit stereo .wav file with WAVEFORMATEXTENSIBLE > header with channel m...

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

lvqcl wrote: > It doesn't know about uint32_t type, so the definition of cpu_xgetbv_x86() fails. > It can be fixed by adding "#include share/compat.h" to cpu.c (or by using > FLAC__uint32 from FLAC/ordinals.h). Ok, added share/compat.h. > When I fix this, the following proble...

About the removed assert in this commit: http://git.xiph.org/?p=flac.git;a=commitdiff;h=bc5113007a53be2c621d5eb5f4485eddf947ef37 It looks reasonable that if x.num_comments == 0 then x.comments is also NULL. Otherwise there's probably a leak somewhere that should be fixed. I found several places where the situation is reverse: comments can be 0 but num_comments is not; IMHO it makes sense

Erik de Castro Lopo wrote: >> There's the following code in stream_decoder.c: > > Like you, I don't see a lot of value in these. I think I'll decline > these. FLAC__lpc_restore_signal_asm_ia32_mmx compares 'order' argument with 4 and if it's greater then it jumps to FLAC__lpc_restore_signal_asm_ia32. I wonder why the same wasn't done for PPC/Altivec:

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

On Thu, 19 Jun 2014 05:00:39 +0400 lvqcl <lvqcl.mail at gmail.com> wrote: >Erik de Castro Lopo wrote: > >> It sees that the most serious bug in the flac bug tracker: >> >> https://sourceforge.net/p/flac/bugs/413/ >> >> has been fixed in git. This fix alone is worth a new release so its >&g...

I'd definately recommend binaries for download as suggested by lvqcl and Janne Hyv?rinen. All the fabolous work on the code base is of little use to me if I can not find binaries at the official site. Olav Sunde At 12:01 23.11.2014, Janne Hyv?rinen wrote: >On 23.11.2014 12:44, Erik de Castro Lopo wrote: >> lvqcl wrote: >>> 2) Do you plan to rele...