similar to: PATCH: FLAC__ prefix to precompute_partition_info_sums_...

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 -msse), then -msse2 and so on. Input file for test: 44.1kHz/16bit/stereo; best compression mode (flac

1) src/share/grabbag/snprintf.c, line 42: 'on systems with a norrmal ISO C99' 'norrmal' -> 'normal' 2) src/flac/encode.c, line 1661: '(eg, very short files, < 10000 fames)' 'fames' -> frames? samples? bytes? 3) configure.ac, line 140: 'AM_CONDITIONAL(FLAC__CPU_X86_64, test "x$cpu_x86_64" = xtrue)' Not sure about this, but

Erik de Castro Lopo wrote: >> 3) configure.ac, line 140: 'AM_CONDITIONAL(FLAC__CPU_X86_64, test "x$cpu_x86_64" = xtrue)' >> >> Not sure about this, but other names inside AM_CONDITIONALs begin with FLaC__, >> not FLAC__. A quote from configure.ac: "NOTE that for many of the AM_CONDITIONALs >> we use the prefix FLaC__ instead of FLAC__ since

Erik de Castro Lopo wrote: >> 3) configure.ac, line 140: 'AM_CONDITIONAL(FLAC__CPU_X86_64, test "x$cpu_x86_64" = xtrue)' >> >> Not sure about this, but other names inside AM_CONDITIONALs begin with FLaC__, >> not FLAC__. A quote from configure.ac: "NOTE that for many of the AM_CONDITIONALs >> we use the prefix FLaC__ instead of FLAC__ since

After working on some more plugins I realized that the naming for flac's ordinal types were not going to cut it. There is too much chance for conflicts with other libraries/programs with names like 'bool' and 'uint32' so I went back and prefixed all flac ordinal types with 'FLAC__'. It makes the code a little harder to read until you get used to it but should make the

This patch slightly changes precompute_partition_info_sums_ set of functions. It doesn't alter the logic of these functions. The idea is to simplify them to make the following patches more simpler (I still try to increase the calculations for 24-bit audio). -------------- next part -------------- A non-text attachment was scrubbed... Name: precomp_partitions_1.patch Type:

Here I attach a preliminary version of a patch for precompute_partition_info_sums_() function that should accelerate encoding of 24-bit input data. 1) SSE2, SSSE3 and AVX2 versions of this function should be updated, too 2) the patch also changes if(FLAC__bitmath_ilog2(default_partition_samples) + bps + FLAC__MAX_EXTRA_RESIDUAL_BPS < 32) into (in effect)

The commit http://git.xiph.org/?p=flac.git;a=commitdiff;h=0a0a10f358345f749e4a05021301461994f1ffc5 (from 31 Mar 2007) adds the following conditional: if(FLAC__bitmath_ilog2(default_partition_samples) + bps < 32) And the commit http://git.xiph.org/?p=flac.git;a=commitdiff;h=f081524c19eeafd08f4db6ee5d52a9634c60f475 has this: if(FLAC__bitmath_ilog2(default_partition_samples) +

WAIT A MINUTE. You signed up for this mailing list to write that? -----Original Message----- From: flac-bounces@xiph.org [mailto:flac-bounces@xiph.org] On Behalf Of Dirk Sent: Friday, February 24, 2006 4:51 AM To: flac@xiph.org Subject: [Flac] H A T E What retard did the Flac API? It looks like what CS students do short before they leave university to become consultants. It's bloated

Decoding flac files is also prone to producing fragmented files. NTFS has the ability to completely avoid fragmentation if it is told the file size before hand, but that would require using special Windows-only functions. Increasing the write buffer from the default 512 bytes to 10 MB already reduces the problem tremendously. -------------- next part -------------- diff --git

On Jan 2, 2007, at 1:56 PM, Josh Coalson wrote: >> OK, so I've been trying for a day now to get FLAC implementation in >> our apps. Suffice it to say that due to the "interesting" >> documentation [...] > > could you elaborate? Well, I've just never seen anything like it before. There's a step- through, to be sure, but I got more information out of

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

Thanks for the reply, But that still tries to read for itself from libogg... i need to be able to feed data only... it can never try and read for itself. That code is still trying to control the data flow. Basicly i need to operate like this. SetupCodec when i have data to give to the codec FeedDataToCodec(data) //Receive a bunch of callbacks somewhere returning me pcm data //Codec

Hey i've recently written some directshow filters for ogg vorbis and speex (www.illiminable.com/ogg/) and i thought i might add flac too... i've had a quick look at the C++ api and it appears that the decoding works by having a read callback to get it's data. In directshow everything is pushed into the decoder it can't ask for data when it wants... i'm just wondering if there

Erik de Castro Lopo wrote: > Well FLAC__int32 is just a 32 bit integer and on all the platforms/ > architecures/compilers that FLAC supports FLAC__int32 and int are > the same. > > Personally I think the FLAC__xxxx stuff should go, to be replaced with > C standard int32_t, uint32_t, int16_t etc, at least for internal code. > I am slowly doing that when I touch code. > >

> OK, attempting one more convergence on all this, here's > what I did: > > 1. Reverted back to rev 1.5 of src/libFLAC/ia32/Makefile.am > 2. Applied Matt's last cleanup patch of 8 files. I did not > apply the patch to src/test_unit/main.c since it looks wrong. > main.c is supposed to include the local bitbuffer.h, not > src/libFLAC/private/bitbuffer.h; I think the

On Mon, Jun 25, 2001 at 12:49:04PM -0700, Josh Coalson wrote: > After working on some more plugins I realized that the naming for flac's > ordinal types were not going to cut it. There is too much chance for > conflicts with other libraries/programs with names like 'bool' and 'uint32' > so I went back and prefixed all flac ordinal types with 'FLAC__'. It

What retard did the Flac API? It looks like what CS students do short before they leave university to become consultants. It's bloated beyond all recognition. The Documentation sucks ass. There are no good examples. DO YOU HATE LISTENING TO MUSIC? What retard decided to start EVERYTHING with "FLAC__"? That's obscene! Please compare your shit with the elegant vorbis API and

--- Evan Olcott <ev@audiofile-engineering.com> wrote: > > On Jan 2, 2007, at 1:56 PM, Josh Coalson wrote: > > >> OK, so I've been trying for a day now to get FLAC implementation > in > >> our apps. Suffice it to say that due to the "interesting" > >> documentation [...] > > > > could you elaborate? > > Well, I've

The previous patch was bugged. The output file wasn't truncated to correct size and was a bit off from rounding the WAVE/AIFF header to smallest sector size. And RAW output didn't benefit from the change. And the existing functions didn't need changes as outputfilename was already known. Attached is a fixed and improved version. -------------- next part -------------- diff --git