search for: bytes_per_sampl

...r.size from guint to gsize diff --git a/libswfdec/swfdec_audio_event.c b/libswfdec/swfdec_audio_event.c index fc05dcd..fa43359 100644 --- a/libswfdec/swfdec_audio_event.c +++ b/libswfdec/swfdec_audio_event.c @@ -188,7 +188,7 @@ swfdec_audio_event_decode (SwfdecAudioEvent *event) } skip = bytes_per_sample * (event->start_sample / granule); if (skip >= event->decoded->length) { - SWFDEC_WARNING ("start sample %u > total number of samples %u", + SWFDEC_WARNING ("start sample %u > total number of samples %"G_GSIZE_FORMAT, event->start_sample...

...0,10 @@ static void progress_callback(const FLAC__StreamEncoder *encoder, FLAC__uint64 b #define READSIZE 1024 +#define BPS 24 /* Bits per sample */ + static unsigned total_samples = 0; /* can use a 32-bit number due to WAVE size limitations */ -static FLAC__byte buffer[READSIZE/*samples*/ * 2/*bytes_per_sample*/ * 2/*channels*/]; /* we read the WAVE data into here */ +static FLAC__byte buffer[READSIZE/*samples*/ * BPS/8 /*bytes_per_sample*/ * 2/*channels*/]; /* we read the WAVE data into here */ static FLAC__int32 pcm[READSIZE/*samples*/ * 2/*channels*/]; int main(int argc, char *argv[]) @@ -73,14 +7...

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

...============================================================= --- main.c (revision 1) +++ main.c (working copy) @@ -39,7 +39,7 @@ #define READSIZE 1024 static unsigned total_samples = 0; /* can use a 32-bit number due to WAVE size limitations */ -static FLAC__byte buffer[READSIZE/*samples*/ * 2/*bytes_per_sample*/ * 2/*channels*/]; /* we read the WAVE data into here */ +static FLAC__byte buffer[READSIZE/*samples*/ * 3/*bytes_per_sample*/ * 2/*channels*/]; /* we read the WAVE data into here */ static FLAC__int32 pcm[READSIZE/*samples*/ * 2/*channels*/]; int main(int argc, char *argv[]) @@ -71,13 +71,15...

...d FLAC__MD5Final(FLAC__byte digest[16], FLAC__MD5Context *context); +void FLAC__MD5Final(FLAC__byte digest[EVP_MAX_MD_SIZE], FLAC__MD5Context *context); +#endif FLAC__bool FLAC__MD5Accumulate(FLAC__MD5Context *ctx, const FLAC__int32 * const signal[], unsigned channels, unsigned samples, unsigned bytes_per_sample); diff --git a/src/libFLAC/md5.c b/src/libFLAC/md5.c index e251d50..81439d5 100644 --- a/src/libFLAC/md5.c +++ b/src/libFLAC/md5.c @@ -5,6 +5,19 @@ #include <stdlib.h> /* for malloc() */ #include <string.h> /* for memcpy() */ +#ifdef HAVE_ALLOCA_H +# include <alloca.h> +#...

...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 ... OK > testing FLAC__MD5Accumulate (channels=1, bytes_per_sample=1) ... > FAILED, expected MD5 sum b2bb8775b7d5bf59c36c8637293a4602 but > got 419123315a22592e3170b67d0aa26916 However, using the binary on actual FLAC files (with flac -t) doesn't give any errors of mismatching md5 sums, so maybe the problem is in the test itself? ARM is big endian I...

Hi flac-dev, When we try to build libFLAC v1.3.1 using the Android NDK, we currently are getting an error in a couple files: ../../third_party/flac/src/libFLAC/md5.c:498:25: error: use of undeclared > identifier 'SIZE_MAX' > if ((size_t)channels > SIZE_MAX / (size_t)bytes_per_sample) > I filed a bug for it on the sourceforge bug tracker: https://sourceforge.net/p/flac/bugs/457/ This is fixed (in all NDK versions) by including limits.h. I've attached a simple patch that fixes the Android NDK build. Please let me know if theres any other process involved in getting t...

OK, thanks to the help of another forum user, I got my app compiled and working, but I now need to precache the OGG to memory. My current method somehow winds up in a loop or freezes the application. Here is y source for the decode/precache function. Why is it just freezing? I've let it run for about three minutes, thinking it was doing some heavy decoding, but I was wrong. Once this is

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

...nt64 samples_written, unsigned > frames_written, unsigned total_frames_estimate, void *client_data); > > #define READSIZE 1024 > > static unsigned total_samples = 0; /* can use a 32-bit number due to WAVE > size limitations */ > static FLAC__byte buffer[READSIZE/*samples*/ * 2/*bytes_per_sample*/ * > 2/*channels*/]; /* we read the WAVE data into here */ > static FLAC__int32 pcm[READSIZE/*samples*/ * 2/*channels*/]; > > int main(int argc, char *argv[]) > { > FLAC__bool ok = true; > FLAC__StreamEncoder *encoder = 0; > FLAC__StreamEncoderInitStatus init_s...

...a/libswfdec/swfdec_audio_event.c b/libswfdec/swfdec_audio_event.c index a82182d..8520bf9 100644 --- a/libswfdec/swfdec_audio_event.c +++ b/libswfdec/swfdec_audio_event.c @@ -154,6 +154,7 @@ swfdec_audio_event_decode (SwfdecAudioEv } } event->n_samples = event->decoded->length / bytes_per_sample * granule; + SWFDEC_LOG ("total 44100Hz samples: %u", event->n_samples); } static SwfdecAudioEvent * diff-tree 40854374b86f321fb816ce505f2ef170f59dfaf1 (from 9a75550335d3a4ea2276c7573634d12a81fc030b) Author: Benjamin Otte <otte at gnome.org> Date: Thu Oct 11 18:29:22 2007...