similar to: FLAC/assert.h overwrites /usr/include/assert.h?

problem solved... sort of. not sure why 1.0.2 should be any different except for the different versions of automake/libtool I used to build the source release. --- Kyle Sallee <cromwell@kublai.com> wrote: > Date: Wed, 10 Jul 2002 19:41:27 -0400 (EDT) > From: Kyle Sallee <cromwell@kublai.com> > To: Josh Coalson <xflac@yahoo.com> > Subject: Re: Fwd: Re: [Flac-dev]

I always use --prefix, and it gets put in the right place (<prefix>/include/FLAC/assert.h), which I'm sure sheds no new light on this. I'd still like to know why FLAC__ASSERT() is necessary. K&R is very clear that the preprocessor is to remove calls to assert() if NDEBUG is defined. (Some compilers, including gcc, implicitly define NDEBUG when optimizing, but of course it can

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

On Jan 2, 2007, at 5:15 AM, Arek Korbik wrote: > The XCode project files you found are meant to be used with FLAC > 1.1.2. The FLAC repository now contains version 1.1.3 files, and there > have been interface changes in that latest revision > (http://flac.sourceforge.net/changelog.html#flac_1_1_3). That could > explain your problems with compilation. Well, now, no, I did download

On Fri, Nov 08, 2002 at 12:39:52PM -0800, Josh Coalson wrote: > --- Miroslav Lichvar <lichvarm@phoenix.inf.upol.cz> wrote: > > I have few notes: > > > > It seems there is changed API in CVS again. So, what about adding > > function like > > unsigned FLAC__format_frame_size(const FLAC__Frame *frame) > > which returns size of the frame in bytes. This

What is the advantage of removing an assert? - even FLAC_ASSERT() My understanding is that assert() is only compiled into the code with Debug builds, whereas with a Release build the assert() macro will generate no code at all. In other words, when you build for testing, the assert is there, but when you build the fully optimized version the assert will be removed anyway. Seems safer to leave

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

I have few notes: It seems there is changed API in CVS again. So, what about adding function like unsigned FLAC__format_frame_size(const FLAC__Frame *frame) which returns size of the frame in bytes. This can be useful, for example, in xmms plugin to display current bitrate like vorbis plugin does. If 'PERFORMER' field is missing in vorbis comment, it would be nice to display

I have just released a source distribution which is the candidate for the 1.0.3 release. At this time I would ask anyone who is willing to help test it to do the following: 1. download the tarball and unzip it: http://prdownloads.sourceforge.net/flac/flac-1.0.3_beta-src.tar.gz?download 2. do ./configure && make && make check This will build all code and run all the tests.

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 Thu, 27 Jan 2005, John Steele Scott wrote: > That looks fine to me as well. However, the best solution is something which > Luca suggested a few months ago, which is to use the functions defined in > altivec.h. These are C functions which map directly to Altivec machine > instructions. I am willing to help out, but I don't find the current lpc_asm.s > very easy to follow, and

Ok, here is a patch waiting for new CVS :). It works fine for me, but please check it before commiting... -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/bitbuffer.c.orig 2003-01-30 17:36:01.000000000 +0100 +++ src/libFLAC/bitbuffer.c 2003-01-30 21:53:18.000000000 +0100 @@ -51,6 +51,25 @@ */ static const unsigned FLAC__BITBUFFER_DEFAULT_CAPACITY = ((65536 - 64) *

OK, so I've been trying for a day now to get FLAC implementation in our apps. Suffice it to say that due to the "interesting" documentation and the inability to compile this thing from the source, I'm not sure we can do it yet. I am writing in to see if there's anything I'm missing before I make the conclusion that we have to wait... --- We write apps for OS

I'm trying to read two data sets in json format from a single .js file. I've tried fromJSON() in both RJSONIOIO and RJSON packages, but they require that the lines be pre-parsed somehow in ways I don't understand. Can someone help? > wheat <- readLines("http://mbostock.github.com/protovis/ex/wheat.js") > str(wheat) chr [1:70] "var wheat = [" "

I had a problem where the seekable_stream_decoder was getting stuck in an infinite loop sometimes. It looks like I'm not the only one that's had the problem: http://lists.xiph.org/pipermail/flac-dev/2004-February/001508.html see also sourceforge bug #1154585 The problem is easiest to reproduce with a small flac file. The one I'm using is only 45 kB. Simply write a routine that

Hi, I checked the archives, but I didn't find anything regarding this problem. FLAC__file_decoder_seek_absolute takes an incredibly long time to seek. What can I do about this? How do I fix it? Here's how I'm calling the function: if (argc > 2) { secs = atoi(argv[2]); seek_point = (FLAC__uint64) secs * sample_rate; printf("seeking to %d:%02d\n", secs/60,

Hi Flac developers! I'm using the seekable_stream_decoder API of libFLAC 1.03 and I'm stuck with a mysterious problem: my FLAC plugin works nicely as long as the seek_absolute() function is never used, but as soon as I seek around in a sample (ie. call seek_absolute() with an offset != 0), I cannot detect the end of a file anymore. decoder_get_state() never returns

Hi, we are implementing FLAC decode on an embedded device. FLAC, as you know, can have block sizes up to ~65K. For an embedded implementation, memory is limited: what would be the maximum block size we should support? We have seen the encoder encodes either 1152 or 4608 in its default setup. Should we support other block sizes? Also another unrelated question: given most existing files

I'm using seekable_stream_decoder, And., this is my write_callback. I'm not getting the required output. The PCM i get is not the proper music. Am I doing something wrong here? FLAC__StreamDecoderWriteStatus AFLACStreamPlayer::StreamWriteCb ( const FLAC__SeekableStreamDecoder *decoder, const FLAC__Frame *frame, const FLAC__int32 * const buffer[], void *client_data) { int Channels,

Josh, I added the following trivial implementation of the C++ file decoder FLAC::Decoder::File::get_decode_position() to my file_decoder.cpp file... bool File::get_decode_position(FLAC__uint64 *position) const { FLAC__ASSERT(is_valid()); return (bool)::FLAC__file_decoder_get_decode_position(decoder_, position); } I would humbly suggest it be included in future libFLAC++ releases.