similar to: FIxed rest of cast-align warnings

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

This has the advantage of being more efficient than the included routines and allows distros to centralize crypto mainteniance on a few libraries. --- configure.ac | 4 +- m4/ax_check_openssl.m4 | 124 +++++++++++++++++++++++++++++++++++++ src/libFLAC/Makefile.am | 2 +- src/libFLAC/include/private/md5.h | 8 ++- src/libFLAC/md5.c

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

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

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)

op 29-06-14 15:31, Erik de Castro Lopo schreef: > I would appreciate it if people could kick this around, test on other > platforms/architectures and test for performance regressions. These patches indeed fix the -Wcast-align warnings, but the new MD5 tests fail > +++ libFLAC unit test: md5 > > testing FLAC__MD5Init ... OK > testing that FLAC__MD5Final clears the MD5Context

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

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

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

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:

flac.exe crashes if I try to decode multichannel flac file with RG tags using the following command line: flac.exe -d --apply-replaygain-which-is-not-lossless test_6ch.flac The code in replaygain_synthesis project uses FLAC_SHARE__MAX_SUPPORTED_CHANNELS which is equal to 2. The fix just changes 2 to FLAC__MAX_CHANNELS. -------------- next part -------------- A non-text attachment was scrubbed...

Hello, First, thanks a lot for FLAC. A few questions. Apologies if this is not the right forum or if these questions have come up before; the SourceForge archive search didn't turn up anything. 1. Would it be possible for FLAC to support more than 8 channels? 2. If (1) is not desirable because it would break compatibility or some such, then is it possible to build a local copy

Hi all, I've found that the FLAC__FrameHeader struct's blocksize member has values limited to the range (0, FLAC__MAX_BLOCK_SIZE] where FLAC__MAX_BLOCK_SIZE is 65535. In the encoder, what determines the size of a block? Cheers, Erik -- ----------------------------------------------------------------- Erik de Castro Lopo -----------------------------------------------------------------

On Sat, Mar 8, 2014 at 7:49 AM, ??????? ?????? <rodionkarimov at yandex.ru>wrote: > 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

When I was trying to find yesterday's xmms-plugin bug, i have noticed that seeking in stream without seek-table isn't very good. With attached patch it is much better. -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/seekable_stream_decoder.c.orig 2003-02-26 19:41:51.000000000 +0100 +++ src/libFLAC/seekable_stream_decoder.c 2003-07-09 23:49:35.000000000 +0200

Here's what I listed in that email. Merging doesn't appear to be necessary. If you have any build problems, let me know. Note that my detection code is Darwin-specific. It's a BSD call (sysctl()), so a change to the platform-detection macros should enable it to work on other BSDs. However, I don't know what that would be, and I couldn't determine any safe way to do the check

FYI, I have checked in a few interesting things. One is a speedup to the decoder (about 15% improvement in overall decode time). Another is a new interface to FLAC file metadata. If you're curious look at include/FLAC/metadata.h. It is basically a collection of object manipulation routines and iterators that make it pretty easy to add/edit/delete FLAC metadata in files efficiently. The

Hi I've found bugs in vorbis-tools and wrote this patch to fix them: 1st part is to fix single-channel flac files. 2nd part fixes a problem with thread race causing lockup if you press Ctrl-C Ctrl-C sets sig_request.cancel, buffer thread exits if it sees sig_request.cancel However, if Ctrl-C was pressed here do { if (nthc-- == 0) { ----------------> Ctrl-C