similar to: Compressing sound fonts with FLAC

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

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

--- Josh Green <jgreen@users.sourceforge.net> wrote: > I stripped out all non-audio data from a few fonts > (which doesn't > usually amount to much, 50k in a font with a lot of > preset/instrument/sample overhead information). I > managed to save a good > 20k by gzipping this data and not making FLAC > compress it. Not that much > for all the effort. Although I

For those who are interested in checking out my initial specification for the FlacPak format, I updated the web pages at: http://swami.sourceforge.net/flacpak.php The direct link to the specification notes: http://swami.sourceforge.net/flacpak_format.php For those who weren't reading the previous threads, FlacPak is a format being designed to handle compression of files containing binary and

I found a bug with FLAC v0.6 raw encoding. It appears that the file pointer in the source file is not reset after seeking to the end for checking the size. I've attached a patch. I'm excited about FLAC!! I've been looking for a good GPL lossless RAW audio compressor for use with sound fonts. Sound font files contain 16 bit samples that are word aligned, so just treating it as raw

I posted to this list a couple years back and then again sometime a year ago about using Flac to compress SoundFont instrument files. I never got around to finalizing the specification for that project, and I have since realized that a more generic approach would be better. I registered the "SFFL" Sound Font FLAC application meta data ID. I would like to remove that, since it was never

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

Josh Coalson wrote: > I've been thinking about this, and here's what I > came up with. This kind of dovetails into the > discussion Mike Wren started about the etree > header. > > I was thinking about defining a FREEFORM metadata > block which may be of arbitrary size. The only > mandatory field would be a (say, 32-bit) id of > the owner. In your case, you

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

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

I'm trying to get SfArk (http://melodymachine.com/) to work under Wine. Yes, there's a (proprietary) Linux version on the website, but it won't decompress some files, so I need to use the Windows version. The installer runs fine, but when it's time to load the program Wine complains about "lsunpa32.dll". Which I think is strange, since it's installed along with the

On Mon, 2003-11-17 at 11:04, Josh Coalson wrote: > could you clarify your plan... are you thinking about > 1) encoding to a FLAC container and using metadata blocks > for everything that is not data? > 2) writing your own container? > > 1) seems kind of impractical to do in a general way. > I'm starting to also think that 2) is the best route. I was originally

I am making a program to obtain information from FLAC files in Visual Basic. NET language. If somebody needs it I can send it. I can also translate it to C #. But I have read the documentation and I have looked for in sdk 1.2.2 and I don't find how to get the frames number of the file and the used compression level (5 default and others) Can somebody help me? Greetings. Santiago Jimeno

If compression level is not default (!=5), is it stored? If compression level is stored in some case, where I can find it? Frames number works OK according to your instructions. Thank you ----- Original Message ----- From: "Josh Coalson" <xflac at yahoo.com> To: "Santiago Jimeno" <sjimeno at ya.com>; <flac at xiph.org> Sent: Tuesday, January 27, 2009 7:43

Flake is a completely independent codebase. When I used it years ago, I remember it being not only better compression but significantly faster as well. I believe some of the techniques used in libflake were added to libFLAC in 1.1.4. However, some of the improved compression in flake was due to options that are outside the FLAC 'subset', such as larger blocksize, greater number of

Greetings, I'm playing aroung with the library and try to encode some PCM samples out of a WAVE file. I recognized that my own encoding is bigger than the encoding with the command line tool and I can't figure out why it is so. I tried some API functions to get a better result but I missed. minimal test code: http://stinfwww.informatik.uni-leipzig.de/~mai02cal/test.c example wav:

Hi I am thinking of ripping albums to a single flac file with embedded cuesheet. As track and index points have to be on a 588 sample boundary due to the CD TOC standard working in 588 sample frames, I thought it may be beneficial to rip CDs with a blocksize of 588 samples. According to the format page on sourcefourge a stream is subset if "The blocksize bits in the frame header must be

I mean that the first statement [Subset streams must use one of 192/576/1152/2304/4608/256/512/1024/2048/4096 (and 8192/16384 if the sample rate is >48kHz).] published on https://www.xiph.org/flac/documentation_tools_flac.html#flac_options_blocksize page IS NOT EQUAL to second statement [The blocksize bits in the frame header must be 0001-1110. The blocksize must be <=16384; if the sample

I'm misleading about FLAC subset constraints... Please help me understand exact FLAC subset limitation.

Hi all, Google Security Team member, Michele Spagnuolo, recently found two potential problems in the FLAC code base. They are : CVE-2014-9028 : Heap buffer write overflow CVE-2014-8962 : Heap buffer read overflow For Linux distributions, the specific fixes for these two CVEs are available from Git here: