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 ratio for 8 fonts of various sizes: sflac: 0.592 sfArk: 0.536 FLAC seems to be slightly faster (although I am running sfArk through wine), total time for 8 files: sflac: 12.81 seconds sfArk: 13.7 seconds 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 noticed that FLAC didn't do very well with the non-audio data (I didn't expect it to), so I do like the idea of separating this data and gzip/bzip'ing it. I think I can save more data by concentrating on the audio. The sample chunk in a sound font is composed of many samples, all 16 bit word aligned. Each sample can have its own sampling rate. These samples appear one after the other, each with 46 '0' pad samples at the end. I can see that this might not be optimal for FLAC. Any ideas of how to get FLAC to better compress these back to back samples? I'm probably going to be writing a utility that uses the library interface to FLAC. Lates.. Josh Green
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 looking over the FLAC format and saw the META data stuff. Is there anything that needs to be added in order to take advantage of this? Why not just a binary META data block that has some sort of identifier (a string maybe). That would allow arbitrary data to be stored. My other option (which I was originally thinking of) would be to use FLAC on the audio stuff, and zlib for the non-audio data, then just write my own custom format file which would basically just have a simple header and the two compressed blocks appended onto it. I'm not sure what would make the most sense. Should FLAC try to encorporate compression of sound fonts? This might not be that hard actually. If it had the capability of concatenating gzip/bzip compressed blocks with FLAC compressed blocks it would not really need to know too much of the internals of a sound font (nothing on the decoding side), just where the sample data begins and ends and I guess perhaps on a per sample basis when variable block length compression is available. iirc FLAC treats WAV files specially, and doesn't store some types of WAV information blocks. If arbitrary gzip/bzip compressed blocks could be inserted into the stream then any portion of a WAV file that isn't audio could be retained. Does this fit into FLAC's purpose?> > > 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 > it harder because right now flac only supports a > fixed blocksize (even though the format allows for a > varying blocksize). >I noticed that the max block size is 65535. Sample sizes in sound fonts can be of fairly arbitrary length (32 bit length), and many would exceed 64k, although many would be much smaller too. So breaking them into smaller blocks would be necessary for many samples. I guess varying blocksize compression is really what would be the best. Any ideas of when this might be available? Compression is good as things stand now, although not optimal. I compressed a 118MB sound font to 64MB with FLAC which was only 3MB difference to sfArk (only 170k of this is non-audio data which would be more significant with smaller sound fonts). Lates.. Josh Green
--- 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 noticed that FLAC > didn't do very well > with the non-audio data (I didn't expect it to), so > I do like the idea > of separating this data and gzip/bzip'ing it. >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 think I can save more data by concentrating on the > audio. > The sample chunk in a sound font is composed of many > samples, all 16 bit > word aligned. Each sample can have its own sampling > rate. These samples > appear one after the other, each with 46 '0' pad > samples at the end. I > can see that this might not be optimal for FLAC. > Any ideas of how to get FLAC to better compress > these back to back > samples? >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 it harder because right now flac only supports a fixed blocksize (even though the format allows for a varying blocksize). Josh __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/