search for: flac__

.../grabbag/snprintf.c, line 42: 'on systems with a norrmal ISO C99' 'norrmal' -> 'normal' 2) src/flac/encode.c, line 1661: '(eg, very short files, < 10000 fames)' 'fames' -> frames? samples? bytes? 3) configure.ac, line 140: 'AM_CONDITIONAL(FLAC__CPU_X86_64, test "x$cpu_x86_64" = xtrue)' Not sure about this, but other names inside AM_CONDITIONALs begin with FLaC__, not FLAC__. A quote from configure.ac: "NOTE that for many of the AM_CONDITIONALs we use the prefix FLaC__ instead of FLAC__ since autoconf triggers off 'A...

Erik de Castro Lopo wrote: >> 3) configure.ac, line 140: 'AM_CONDITIONAL(FLAC__CPU_X86_64, test "x$cpu_x86_64" = xtrue)' >> >> Not sure about this, but other names inside AM_CONDITIONALs begin with FLaC__, >> not FLAC__. A quote from configure.ac: "NOTE that for many of the AM_CONDITIONALs >> we use the prefix FLaC__ instead of FLAC__...

All(?) non-static functions have FLAC__ prefix. But precompute_partition_info_sums_32bit_asm_ia32_() and ..._intrin_sse2() and ..._intrin_ssse3() don't have it. This patch adds the prefix to them. -------------- next part -------------- A non-text attachment was scrubbed... Name: FLAC__prefix.patch Type: application/octet-stream Size...

Erik de Castro Lopo wrote: >> 3) configure.ac, line 140: 'AM_CONDITIONAL(FLAC__CPU_X86_64, test "x$cpu_x86_64" = xtrue)' >> >> Not sure about this, but other names inside AM_CONDITIONALs begin with FLaC__, >> not FLAC__. A quote from configure.ac: "NOTE that for many of the AM_CONDITIONALs >> we use the prefix FLaC__ instead of FLAC__...

After working on some more plugins I realized that the naming for flac's ordinal types were not going to cut it. There is too much chance for conflicts with other libraries/programs with names like 'bool' and 'uint32' so I went back and prefixed all flac ordinal types with 'FLAC__'. It makes the code a little harder to read until you get used to it but should make the interface more stable. It's all been checked in over the weekend. See include/FLAC/ordinals.h for the main changes. Josh __________________________________________________ Do You Yahoo!? Get perso...

Thanks for the reply, But that still tries to read for itself from libogg... i need to be able to feed data only... it can never try and read for itself. That code is still trying to control the data flow. Basicly i need to operate like this. SetupCodec when i have data to give to the codec FeedDataToCodec(data) //Receive a bunch of callbacks somewhere returning me pcm data //Codec

...etard did the Flac API? It looks like what CS students do short before they leave university to become consultants. It's bloated beyond all recognition. The Documentation sucks ass. There are no good examples. DO YOU HATE LISTENING TO MUSIC? What retard decided to start EVERYTHING with "FLAC__"? That's obscene! Please compare your shit with the elegant vorbis API and realize how much you suck. Ever heard of "file operations"? I CULTIVATED your whole shit into an analogy of that (see attachment) and still have to figure how to get the bitrates (because of your shitty...

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

...s. Increasing the write buffer from the default 512 bytes to 10 MB already reduces the problem tremendously. -------------- next part -------------- diff --git a/src/flac/decode.c b/src/flac/decode.c index 5e5e17a..9e9405c 100644 --- a/src/flac/decode.c +++ b/src/flac/decode.c @@ -251,6 +251,7 @@ FLAC__bool DecoderSession_construct(DecoderSession *d, FLAC__bool is_ogg, FLAC__ DecoderSession_destroy(d, /*error_occurred=*/true); return false; } + setvbuf(d->fout, NULL, _IOFBF, 10*1024*1024); /* 10MB output buffer to help reduce disk fragmentation */ } }

...seemed very intra-linked, very, shall we say - generated automatically... I'm used to Apple's documentation, which is very clean and clear. This seemed a little overkill - lists of functions, lists of headers, lists of classes, alphabetically (even though 99% of them all start with FLAC__), etc. It seemed a little "too much" where it looks like it could be a lot simpler - the API isn't really as complex as it looks like at first glance... Ev Technical Knowledge Officer Head Programmer/Designer Audiofile Engineering http://www.audiofile-engineering.com/ -----...

> OK, attempting one more convergence on all this, here's > what I did: > > 1. Reverted back to rev 1.5 of src/libFLAC/ia32/Makefile.am > 2. Applied Matt's last cleanup patch of 8 files. I did not > apply the patch to src/test_unit/main.c since it looks wrong. > main.c is supposed to include the local bitbuffer.h, not > src/libFLAC/private/bitbuffer.h; I think the

...n some more plugins I realized that the naming for flac's > ordinal types were not going to cut it. There is too much chance for > conflicts with other libraries/programs with names like 'bool' and 'uint32' > so I went back and prefixed all flac ordinal types with 'FLAC__'. It makes > the code a little harder to read until you get used to it but should make the > interface more stable. It's all been checked in over the weekend. See > include/FLAC/ordinals.h for the main changes. I don't know how you feel about adding a build-time dependency...

...etard did the Flac API? It looks like what CS students do short before they leave university to become consultants. It's bloated beyond all recognition. The Documentation sucks ass. There are no good examples. DO YOU HATE LISTENING TO MUSIC? What retard decided to start EVERYTHING with "FLAC__"? That's obscene! Please compare your shit with the elegant vorbis API and realize how much you suck. Ever heard of "file operations"? I CULTIVATED your whole shit into an analogy of that (see attachment) and still have to figure how to get the bitrates (because of your shitty...

...gt; shall we say - generated automatically... > > I'm used to Apple's documentation, which is very clean and clear. > This seemed a little overkill - lists of functions, lists of headers, > > lists of classes, alphabetically (even though 99% of them all start > with FLAC__), etc. It seemed a little "too much" where it looks like > > it could be a lot simpler - the API isn't really as complex as it > looks like at first glance... yes, the API docs are generated from headers by doxygen, and I personally don't find a lot of the sections...

...ions didn't need changes as outputfilename was already known. Attached is a fixed and improved version. -------------- next part -------------- diff --git a/src/flac/decode.c b/src/flac/decode.c index 5e5e17a..ed7eff8 100644 --- a/src/flac/decode.c +++ b/src/flac/decode.c @@ -263,6 +263,23 @@ FLAC__bool DecoderSession_construct(DecoderSession *d, FLAC__bool is_ogg, FLAC__ void DecoderSession_destroy(DecoderSession *d, FLAC__bool error_occurred) { if(0 != d->fout && d->fout != stdout) { +#ifdef _WIN32 + if(!error_occurred) { + FLAC__off_t written_size = ftello(d->fout);...

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

...etard did the Flac API? It looks like what CS students do short before they leave university to become consultants. It's bloated beyond all recognition. The Documentation sucks ass. There are no good examples. DO YOU HATE LISTENING TO MUSIC? What retard decided to start EVERYTHING with "FLAC__"? That's obscene! Please compare your shit with the elegant vorbis API and realize how much you suck. Ever heard of "file operations"? I CULTIVATED your whole shit into an analogy of that (see attachment) and still have to figure how to get the bitrates (because of your shitty...

...what CS students do short > before they leave university to become consultants. > > It's bloated beyond all recognition. The Documentation sucks ass. There are > no good examples. > > DO YOU HATE LISTENING TO MUSIC? > > What retard decided to start EVERYTHING with "FLAC__"? That's obscene! > > Please compare your shit with the elegant vorbis API and realize how much > you suck. > > Ever heard of "file operations"? I CULTIVATED your whole shit into an > analogy of that (see attachment) and still have to figure how to get the >...

...scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20140926/a0386298/attachment.htm -------------- next part -------------- diff --git a/src/flac/decode.c b/src/flac/decode.c index 5e5e17a..90e0b1a 100644 --- a/src/flac/decode.c +++ b/src/flac/decode.c @@ -101,7 +101,7 @@ static FLAC__bool is_big_endian_host_; static FLAC__bool DecoderSession_construct(DecoderSession *d, FLAC__bool is_ogg, FLAC__bool use_first_serial_number, long serial_number, FileFormat format, FLAC__bool treat_warnings_as_errors, FLAC__bool continue_through_decode_errors, FLAC__bool channel_map_none, replayga...

Hi, We are using the libFLAC++ library to encode FLAC files with Vorbis comments in them and have had the FLAC 1.1.2 version fail consistently (access violation or segmentation fault) on both Windows and Linux. We tracked this down to the metadata code in the C++ API. The problem is in src/libFLAC++/file_encoder.cpp. There are two problems - firstly, a C-style cast is hiding a bad conversion