similar to: trying to write encoder - need help!

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)

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

samples in FLAC are always signed. they must be signed going into the encoder (flac converts unsigned samples to signed) and they come out of the decoder signed. Josh --- David Bishop <tech@bishop.dhs.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Followup to original question: how do I determine if a particular > flac file is > signed (and then, if

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

Hello. I create FLAC file decoding, processing and playing program and have the following question : how to convert FLAC 16 bit file data to 32 bit float buffer for CPU processing? I've already inplemented sound playing and tested it with sine wave - it works without problems; I even made writing into decoding buffer values of sine wave, instead of decoded FLAC file data, and it also works

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [meta: Thanks, Josh, for clearing that up] Continuing my quest to make everyone think I'm an idiot, could someone explain the following code to me? I.e., what the two for loops are accomplishing, and what, *exactly*, is in s16buffer when it's done. Assume I want to write a .wav file from this decoded flac*. Is it already in approximately

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

> 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

Hello all, I've been writing a basic encoder using libFLAC++. It seems to work fine, as in the resultant file is playable in any FLAC compatible player, however the compression ratio is very small - the main example being a 60MB file compressing to 54MB, i guess there's an option i've missed, but i cannot track it down. I was hoping someone could point it out for me:

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

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 Tue, Jan 13, 2004 at 02:04:48PM -0800, Josh Coalson wrote: > --- Denis Chatelain <listes@octopodus.com> wrote: > > 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 >>

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

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

I am getting large, corrupted native FLAC files when trying to call the encoder from inside the decoder. The metadata in the output file is OK. Is initializing and calling an encoder from inside a libFLAC decoder write callback supported? The encoder is initialized on the first write callback. Environment is Win 7 Ult, 64-bit, VS 2008, libFLAC 1.2.1. Here is some context. The static

- INCLUDES is deprecated, and CPPFLAGS is an user-defined variable, use the proper AM_CPPFLAGS instead - Remove FLAC__INLINE definition, providing proper replacement for MSVC compilers. - Detect if we have C99 's lround and provide a replacement for windows... --- configure.ac | 32 ++++++++-------------------- examples/c/decode/file/Makefile.am

Here is all-in-one patch, if this is a problem, i will try to make separated patches. Changes: plugin_common/ * FLAC__plugin_common__pack_pcm_signed_little_endian * accept FLAC__int32 *input[] * supports more channels * fixed clipping bug (BTW, random number generator in dither.c is low quality, it should be replaced, generator in replaygain is much better) *

The patch http://git.xiph.org/?p=flac.git;a=commitdiff;h=0bea5fb96436588b4e78c5be79bf174b9be7a202 changes the type of t value from FLAC__int32 to uint32_t, but only for 24-bit signed input samples. 24-bit *un*signed input still uses FLAC__int32 t. So I wonder - does it makes sense to change this type too? The patch is attached. -------------- next part -------------- A non-text attachment was