similar to: libFLAC docs

> > For those of you using CVS, I have added a libFLAC section to the > > documentation page. I'm not sure how detailed to make it but I > > think it's a good start. Let me know if there's anything else > > you'd like to have in there. > > > > >

Josh Coalson wrote: > > For those of you using CVS, I have added a libFLAC section to the > documentation page. I'm not sure how detailed to make it but I > think it's a good start. Let me know if there's anything else > you'd like to have in there. > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/flac/flac/doc/documentation.html?rev=HEAD >

Hello all I am using libFLAC in a corner application, compressing *a lot* of small signals. First is a general question: in our application we have signals in range 5-10 MHz, potentially 40MHz! Is there any potential problem with that?? The mac sample rate is limited in flac, but it doesn't really seem to be a problem. The output is stored as blob in a sqlite database, it *never *needs to be

Correction, the flac command-line does create a 40-byte Vorbis comment by default. I just never noticed it before. I’ve been using —no-padding all these years for minimal file sizes without realizing that I could save another 40 bytes. Anyway, since metaflac can remove the Vorbis comment using the standard library, then you should be able to create a solution without modifying libFLAC. Brian

I rethought it and it seemed like a bad idea to post a big file, so you can get it here: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/flac/junk/flac-1.0-src-candidate.tar.bz2 Josh __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/

Josh Coalson <xflac@yahoo.com> writes: > --- John Steele Scott <toojays@toojays.net> wrote: >> Back in October 2004, I did a bit of work on FLAC to get version >> 1.1.1 to >> build correctly under GNU/Linux/PPC. Only now have I realised that >> somewhere >> along the way something broke in FLAC's decoding. On my machine, >> roughly 50%

Its been a while since I was discussing a SoundFont compressor based on FLAC. I've recently implemented the compressor using an application metadata block with the ID 'SFFL' that I registered, which contains my own header and a block of zlib (gzip) compressed SoundFont info. The audio chunk (a block of consecutive 16 bit signed samples separated by 46 zero samples) is then encoded with

Hi all, I am interested in building a stand alone Rice Encoder/Decoder, using FLAC source code as a starting point. I've read the theory behind it, and I am very interested in info theory. However, I am struggling with how exactly I would implement the theory in code. I'm a newbie to computer science (only 1 year experience). I have read the format and documentation links on the FLAC

On Thu, 2007-04-05 at 02:27 -0700, Brian Willoughby wrote: > Josh (Green), > > Seems like the longest example in your list is a 15-second file. I > would like to see the same problem exhibited in a file that is of a > normal length. I have been recording full performances lasting > hours, and flac always compresses the files below 70% of the original > size. >

On Wed, 2002-07-17 at 15:34, Josh Coalson wrote: > > Have you seen the API changes in 1.0.3? Now all metadata is > parsed and at each decoder layer you can specify which blocks > get passed up to the metadata callback. See the > *_decoder_set_metadata_respond/ignore functions. > > Also, on the encoder size, you can now pass a list of arbitrary > metadata blocks to

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)

On Fri, Jul 20, 2001 at 03:01:54PM -0700, Josh Coalson wrote: > --- Matt Zimmerman <mdz@debian.org> wrote: > > > > automake will include ltmain.sh in the source distribution, so it > > should be > > used even if it isn't installed on the build system. In fact, it > > seems to > > always use the distributed version, and not the installed one

Hi all, I have uploaded a source tarball to sourceforge for testing. See the news item in the HTML docs for the changes (or look here: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/flac/flac/doc/html/news.html?rev=HEAD&content-type=text/html ) Download here: http://prdownloads.sourceforge.net/flac/flac-1.0.5_beta1.tar.gz?download The standard test of 'configure &&

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

--- Chris Csanady <cc@137.org> wrote: > Building the beta on the mac has one stumbling point: the ppc/as/ > libFLAC-asm.la is not currently built due to the configure define > FLaC__HAS_AS__TEMPORARILY_DISABLED, but it is expected to exist by > > libFLAC_la_LIBADD = ppc/as/libFLAC-asm.la > > in src/libFLAC/Makefile.am. After removing this line, it builds > and

Hi everybody, We have FLAC supported for input/output in REAPER (http://www.reaper.fm), and the problem is that when writing 24 bit FLAC files, the data isn't compressed (i.e. the FLAC is slightly larger than if it was writing to .WAV). The files play back fine, however, and 16 bit mode works great. We're using flac-1.1.2, built on win32 with MSVC6 w/ SP5 + VCPP, and NASM version 0.98.39

Hi, The GStreamer flac plugin broke due to libflac 1.1.0 and libflac 1.1.1 not being ABI/API compatible. Skimming through the archives I see that this breakage was intentional. I think it is quite common understanding that when you have a stable release of something you don't break your API, you only add to it. If you want to break the API that should be done by going to a new major number,

>This question comes up regularly on the Debian mailing lists, and there are >arguments for both approaches. I am against the practice of including a >debian/ directory in upstream source distributions for the following >reasons: >- For the same reason, the Debian maintainer would have to have write access to > the upstream CVS repository. This is often otherwise unnecessary

On Sat, Jul 21, 2001 at 04:06:14PM -0400, Matt Zimmerman wrote: > Argh. Maybe libtool will have to get involved after all. I'll work on it > this afternoon. I think I give up. automake and libtool assume that the compiler will be able to assemble stuff, and compilers don't generally understand NASM input. I don't like the strip_fPIC bit, since just about anything that could

I tried to send this message via gmane a couple of weeks ago but it never got through moderation. So maybe the moderator is on holiday, or there is some other problem in the gmane->flac-dev connection? -------------------- Start of forwarded message -------------------- Newsgroups: gmane.comp.audio.compression.flac.devel Subject: A couple of points about flac 1.1.1 on ppc/linux/altivec