similar to: Commonly getting FLAC__STREAM_ENCODER_VERIFY_MISMATCH_IN_AUDIO_DATA on valid audio

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

2013/2/8 Erik de Castro Lopo <mle+la at mega-nerd.com>: > Collin wrote: > >> It turns out it was an error on my part; sorry for the trouble. I misunderstood >> the format libflac was expecting my samples in. I found the wording in the >> documentation very confusing. >> >> My audio file has 2 channels and 16-bit samples, so I have to pull out each >>

2013/2/8 Erik de Castro Lopo <mle+la at mega-nerd.com>: > Collin wrote: > >> It turns out it was an error on my part; sorry for the trouble. I >> misunderstood >> the format libflac was expecting my samples in. I found the >> wording in the >> documentation very confusing. >> >> My audio file has 2 channels and 16-bit samples, so I have to

2013/2/9 Erik de Castro Lopo <mle+la at mega-nerd.com>: > Johnny Rosenberg wrote: > >> For example, when loading an audiofile with libsndfile, all the >> samples are converted to floating point numbers, > > With libsndfile, converting to float is optional. You can just as > easily read int or short. > >> which is what I want >> anyway, but the

Johnny Rosenberg wrote: > For example, when loading an audiofile with libsndfile, all the > samples are converted to floating point numbers, With libsndfile, converting to float is optional. You can just as easily read int or short. > which is what I want > anyway, but the conversion is done by dividing the integers from the > file with pow(2,bps-1), but when converting back,

2013/2/10 Erik de Castro Lopo <mle+la at mega-nerd.com>: > Johnny Rosenberg wrote: > >> Anyway, if I'm allowed to ask a libsndfile question here, > > Sorry, but no, this list is for FLAC related discussion. And of course you won't waste your time replying outside this mailing list? Is there a libsndfile mailing list? Hm? yet another stupid question, of course. If

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

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, I'm working on writing a FLAC encoding plugin for a personal cd ripping project of mine which uses paranoia for the raw audio extraction. My basic setup which follows gets me oddly high pitched audio with lots of noise (although the music IS somewhat recognizable). #include <FLAC/stream_encoder.h> FLAC__StreamEncoder *encoder; FILE *output_file_descriptor; encoder =

> 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

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

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

I think I've gotten FLAC__lpc_restore_signal() about as good as I'm going to get it. Here's what I have: -a new file, lpc_asm.s, which has the assembly routines -changes to cpu.h, cpu.c, and stream_decoder.c to enable them -changes to configure.in to support the new cpu stuff -a preliminary Makefile.am -maybe something else I'm forgetting Now automake complains that configure.in

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

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

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

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():

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

On Thu, Jun 19, 2014 at 03:30:22PM +0400, lvqcl wrote: > BTW, what can you say about the following place in stream_decoder.c > in read_subframe_lpc_() function: > > /*@@@@@@ technically not pessimistic enough, should be more like > if( (FLAC__uint64)order * ((((FLAC__uint64)1)<<bps)-1) * ((1<<subframe->qlp_coeff_precision)-1) < (((FLAC__uint64)-1)

Pulled from my Arch archive, this following patch seems to have made quite a difference in getting my ARM7TDMI chip to play FLAC (compression levels 0-2) on my ipod. I don't have benchmarks with hard numbers, but playing with skips vs playing without skips is a fairly noticeable difference. memcpy and memset on uClibc are optimized in asm for the ARM7TDMI in uClibc. Other hardware/libc