similar to: Developing SoundFont FLAC compressor using libFLAC

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

--- Josh Green <jgreen@users.sourceforge.net> wrote: > 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

--- Josh Green <jgreen@users.sourceforge.net> wrote: > I'll let the list know when SF-FLAC is finished, should anyone be > interested. I'm considering starting a FREE SoundFont compressor > campaign, so users will stop using SoundFont encoders that aren't > available on platforms such as Linux. This would also pressure some > of > the existing formats to release

Josh Coalson wrote: > yeah, flac doesn't have a 'gzip' fallback method > so any non-audio data will probably get stored > verbatim. I'm kind of reluctant to add a generic > compressor. If you wan't, you could come up with a > FLAC metadata block to store a gzip'ed chunk and I > could add that to the format. > I had the same thought when I was

On 06.11.2008 22:16, LRN wrote: > In stream_decoder.c function find_metadata_() checks whether a file is > valid or not. There are 4 cases it recognizes: > 1) file begins with 'fLaC' > 2) file begins with ID3 (skipped), followed by 'fLaC' > 3) file may begin with 11111111 111110?? sync code (or 11111111111110, > depends on endianess i suppose). That is - a raw

I've been doing some more tests with compressing sound fonts with FLAC. It compares quite well with sfArk which is a common compression used on the internet for sound fonts, unfortunately its not open. For the most part, in my tests, sfArk beats FLAC in compression, but thats not surprising as I am compressing entire sound fonts which include non-audio data as well. The average compression

Hi Guys, I was wondering what the idea behind the "Key Frame" settings are in the VP3 codec settings. As far as I could ascertain (from browsing through the source code) the VP3 codec ignores the lpbiPrev and lpPrev members of the ICCOMPRESS structure. My conclusion is thus that each frame passed to the codec is compressed individually and that the redundant information based upon

Hi, I searched the Internet to find an answers, but I didn't find anything useful, so I'm turning to you, maybe someone has the answer. I want to make a realtime broadcast from a Linux box. The source is the soundcard's line-in, and it sends the stream to an Icecast server. I would like to have realtime compressor/limiter functionalities on this Linux box, so the outgoing signal

Hi, I searched the Internet to find an answers, but I didn't find anything useful, so I'm turning to you, maybe someone has the answer. I want to make a realtime broadcast from a Linux box. The source is the soundcard's line-in, and it sends the stream to an Icecast server. I would like to have realtime compressor/limiter functionalities on this Linux box, so the outgoing signal

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

Good day! I'm creating HDL IP CORE (for using in FPGA) for theora encoder (now only I-frames). I don't undestand one moment. Now i develop such stages: 1. From RBG(byer) to YCbCr converter 2. DCT processing (8x8 pixels blocks) 3. Quantizator of DCT coeff. 4. Zig-Zag of quantized DCT coeff. and now i have uresolved last stage of compression - how i must send 8x8 blocks to huffman

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tried to do this, gcc complained a lot about undefined references. After a bit of mucking with the code, i came up with a few patches. This might be a good conversation starter. The build that i've got out of this does pass the testsuite. To enable LTO you just need to apply these (for non-W32 builds you probably only need one of the patches)

Josh: > fixed, thanks! Thanks. However, I think there is a better patch to fix these problems. I reworked this patch not long ago to do better testing for what inline to use in configure, and also a better way to calculate the size of the #defines in replaygain_analysis.c. This was submitted to the SourceForge bug tracker as bug 1701960. See here, and note attached patch.

Hi, I'm sorry to say that I've found the libFLAC++ interface and documentation pretty slim and baffling. What I need to do is add some application-specific metadata to a FLAC file (i'm using the FLAC++ fileencoder). It is currently just a string of characters, which doesn't need to be null-terminated. I've looked through the docs, i've looked through the tests, and

> > the best thing would be to try and set the > blocksize > > to match the length of the individual 'sample'. > if > > each sample is much shorter than the blocksize > then > > the encoder may not be able to generate an > efficient > > model of the signal. if the samples within the > > soundfont vary greatly in length that also makes >

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

My uncle recently bought a new computer and he wants me to help him install Guitar Pro. The thing is, he doesn't have Windows, and I'm thinking of installing Ubuntu with wine on the comp. Quiz time! Can you use wine, with GP, and if you can, deos it perform poorly in any ways?

Josh Coalson <xflac@yahoo.com> wrote: > thanks for the patch. No prob :) > also, if you have miroslav's patch again a more updated version > of bitbuffer.c that would be great. I have been meaning to get > around to applying it for a long time. This is Miroslav's patch, from the mailing list post I dug up in the archives: --- orig/src/libFLAC/bitbuffer.c +++

In stream_decoder.c function find_metadata_() checks whether a file is valid or not. There are 4 cases it recognizes: 1) file begins with 'fLaC' 2) file begins with ID3 (skipped), followed by 'fLaC' 3) file may begin with 11111111 111110?? sync code (or 11111111111110, depends on endianess i suppose). That is - a raw file with FLAC frames, without header (right?). 4) file begins

--- configure.ac | 7 +++++ src/libFLAC/bitreader.c | 12 ++------- src/libFLAC/bitwriter.c | 8 ++---- src/libFLAC/fixed.c | 18 +++++-------- src/libFLAC/format.c | 8 ++---- src/libFLAC/include/private/macros.h | 29 ++++++++++++++++++++ src/libFLAC/metadata_iterators.c | 17 +++---------