similar to: question about 0bea5fb commit

There are following functions in bitreader.c: FLAC__bool FLAC__bitreader_read_unary_unsigned(FLAC__BitReader *br, unsigned *val); FLAC__bool FLAC__bitreader_read_rice_signed(FLAC__BitReader *br, int *val, unsigned parameter); FLAC__bool FLAC__bitreader_read_rice_signed_block(FLAC__BitReader *br, int vals[], unsigned nvals, unsigned parameter); * function FLAC__bitreader_read_rice_signed():

On Thu, Aug 14, 2014 at 12:34 PM, lvqcl <lvqcl.mail at gmail.com> wrote: > Jose Pablo Carballo <jose.carballo at ridgerun.com> wrote: > >> - channels = 2; >> - bps = 16; >> + channels = ((unsigned)buffer[23] << 8) | buffer[22]; >> + bps = ((unsigned)buffer[35] << 8) | buffer[34]; >> total_samples = (((((((unsigned)buffer[43] << 8)

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

Hi all, In commit 3eb4094b859 I think I have fixed all the cast-align warnings. I have tested this in amd64/Linux (little endian) and powerpc64/Linux (big endian) and it passed all tests (including the new MD5 tests). I also did a little performance testing on amd64/Linux with a one hour long stereo WAV file and could not find any mesasurable difference between the old and the new code. I

Hi, In the last days I've been taking as reference the example found in examples/c/encode/file/main.c. With it I've been able to encode a 2ch, 16 bps, 44100 sample rate input WAV file to a FLAC file. Now I've been trying to modify this example to encode a 2ch, 24 bps, 96000 sample rate WAV file. I have to say I'm a bit lost on how I should read the input file in this case, and

Brian Willoughby <brianw at audiobanshee.com> ?????(?) ? ????? ?????? Sun, 31 Jan 2016 22:26:40 +0300: > My assumption is that the code was written to call flac_fopen() so that it is portable to every operating system, even those without fopen(). If you replace flac_fopen() with fopen(), then the tests won't compile on systems that don't have fopen(). I REALLY doubt it. Even if

It turns out that int64 shift is quite slow... This patch changes the code from: (FLAC__int32)(xmm.m128i_i64[0] >> lp_quantization) into: _mm_cvtsi128_si32(_mm_srli_epi64(xmm, lp_quantization)); Encoding of 24-bit .wav files with 32-bit FLAC became noticeably faster. The new code works only if quantization <= 32, but its max value is 15 so the code always work. (max_shiftlimit == (1

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

lvqcl wrote: > Erik de Castro Lopo wrote: > > >> FLAC__int16 s16buffer[FLAC__MAX_BLOCK_SIZE * FLAC__MAX_CHANNELS * sizeof(FLAC__int32)/sizeof(FLAC__int16)]; > >> > >> instead of > >> > >> FLAC__int16 s16buffer[FLAC__MAX_BLOCK_SIZE * FLAC__MAX_CHANNELS * sizeof(FLAC__int16)]; > > > > Really? Would you also write this? : > > >

> 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

I downloaded current version of FLAC sources and compiled it with: * GCC 4.8.1 (MSYS from http://xhmikosr.1f0.de/tools/) * Intel C++ Composer XE 2013 update 5 * MSVS 2010 SP1 * MSVS 2012 update 3 (SSSE3 and SSE4.1 code was disabled for all compilers) Stereo 24-bit WAV file was encoded with -8 preset. Encoding time, in seconds: GCC 32-bit: 209 ICC 32-bit: 130 VS10 32-bit: 116 VS12 32-bit: 114

Hi all, 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 time to work towards one. Things I need to do for this new release: * Deal with all current patches on the mailing list. * Review all bugs reported against 1.3.0 on the sf.net. * Testing and coordination of testing

Erik de Castro Lopo <mle+la <at> mega-nerd.com> writes: > > Collin wrote: > > > Has anyone encountered a similar problem, or are there any known issues that > > could explain this? > > No known issues of this kind, but I would like to see a repeatable test > case so I can investigate further. > > Cheers, > Erik It turns out it was an error

Hi, I was doing some speed and compression comparisons with various apodization/windowing functions, and found out that the definitions for the bartlett and bartlett_hann window in the FLAC codebase have been wrong since their introduction. The attached patch fixes that. Furthermore, I found some peculiar behaviour of the gauss apodization that seems to expose bug. Using different windows

Martijn van Beurden wrote: > Like I reported just before the release of 1.3.0 (mail of Fri, > 05 Apr 2013 08:25:10 +0200, to be specific), compiling on > Raspbian (Debian Wheezy, GCC 4.6) returns quite some warnings of > the type -Wcast-align. What happens if you change the definitions of s8buffer[] and ucbuffer_[] arrays as follows: static __attribute__((__aligned__(4))) FLAC__int8

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

Hello, I just tried to compile libFLAC (using Borland C++ Builder 6 on Windows). The compilers yells at me on line 233 of libFLAC/lpc.c *(residual++) = *(data++) - (sum >> lp_quantization); --> data is const and cannot be modified Funny thing is, if data is declared: const FLAC__int32 *data instead of const FLAC__int32 data[] everything is ok. Is this a bug in my compiler, or

Hi all, I'm attempting to encode raw audio data using libFLAC++. My audio data is 16 bit, mono, 16000Hz. I set all the appropriate parameters on the encoder and then call init(). Everything appears to be ok. I don't know how to properly convert from char *data to the FLAC__int32 *[] requested by the process function. I think this is where my problem is. If I call process() like this:

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

Currently apodization function is hardcoded, see commit <http://git.xiph.org/?p=flac.git;a=commitdiff;h=4e8fe85bceb245dfce07d1956b144e1cb6587c9f> FLAC is locale-dependent so "tukey(0.5)" doesn't work for locales with decimal comma. But "tukey(5e-1)" should be locale-independent so it is possible to re-add 'const char *apodization' member into