similar to: More FlacPak stuff

Thought I'd send an update on FlacPak a file format for compressing instrument files (although its more generically a method of compressing files containing binary and audio with most of the smarts being in the encoder file handlers). It uses zlib for compressing the binary data and FLAC (of course :) for compressing the audio. There is now a CVS tarball of libInstPatch which contains a

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

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

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

Hi, The following is with the latest (and last) puppetmaster/puppetd on FC5. I use puppet to configure a server and several workstations on my home network. This includes managing several files of >5Mbyte on the workstations. I have had problems recently with timeout errors on some of these files. These errors seem consistent for a particular puppet setup/configuration, but can change when

Curt Sampson wrote: > > > > I've thought of doing lossy compression before on instruments, > but I'd > > > > much rather stick to lossless, at least for now. > > Honestly, stick to lossless. I mean, to the point where you can get > your exact samples back. Sure, an S900 sample is not so great quality, > but having come from the era where I did the

I created a quick mini banner logo based on the flac logo and put it up for viewing (its not publicly linked yet). Let me know if this is ok with you, or if you would rather me come up with something original :) My only complaint about it, is that I like the font you used better. http://swami.sourceforge.net/flacpak.php Cheers. 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

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

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

--- 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: > The audio data will be encoded with FLAC and thats where I have some > questions. My current thinking is to combine audio of the same type > together to minimize changing of parameters in the FLAC stream. Same > sample type being data that has the same number of channels and bit > width. There will also be cases where a

On Tue, Nov 18, 2003 at 08:34:05PM -0800, Josh Green wrote: > > Steve Lhomme wrote: > > > > You might try to contact the makers of FruityLoops. Right now their > > samples packs are in Ogg format (stored in a WAV IIRC). They like open > > and free formats (they also use the LAME encoder). > > I've thought of doing lossy compression before on instruments,

On Wed, Nov 19, 2003 at 08:41:56AM -0700, tech@bishop.dhs.org wrote: > On Tue, Nov 18, 2003 at 08:34:05PM -0800, Josh Green wrote: > > > Steve Lhomme wrote: > > > > > > You might try to contact the makers of FruityLoops. Right now their > > > samples packs are in Ogg format (stored in a WAV IIRC). They like open > > > and free formats (they also

On Wed, 19 Nov 2003, Josh Green wrote: > I am curious though how one would get around the problems of looping > with a lossy algorithm. When decoding a vorbis stream would one have > the same number of samples as you encoded? The problem with looping > arises if the loop points aren't the same sample values, resulting in > a click. Some sort of algorithm could be run around the

--- tech@bishop.dhs.org wrote: > On Tue, Nov 18, 2003 at 08:34:05PM -0800, Josh Green wrote: > > > Steve Lhomme wrote: > > > > > > You might try to contact the makers of FruityLoops. Right now > their > > > samples packs are in Ogg format (stored in a WAV IIRC). They like > open > > > and free formats (they also use the LAME encoder). >

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

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

> Steve Lhomme wrote: > > You might try to contact the makers of FruityLoops. Right now their > samples packs are in Ogg format (stored in a WAV IIRC). They like open > and free formats (they also use the LAME encoder). I've thought of doing lossy compression before on instruments, but I'd much rather stick to lossless, at least for now. There are issues to be sorted out

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