similar to: FlacPak - Free lossless instrument compression

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

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

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

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

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

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

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

> 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

> Message: 8 > Date: Fri, 29 Oct 2004 11:40:08 -0700 > From: Mark Knecht <markknecht@gmail.com> > Reply-To: Mark Knecht <markknecht@gmail.com> > To: Joel Konkle-Parker <jjk3@msstate.edu> > Subject: Re: [Wine]Guild Wars Client > Cc: wine-users@winehq.com > > On Fri, 29 Oct 2004 10:11:53 -0700, Mark Knecht <markknecht@gmail.com> > wrote: >>

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

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

Hello, Attached is a mail regarding question how to insert Date field using ROracle package. I am stuck with this problem and appreciate receiving help from gurus on this list. Code used mainly is: library(ROracle) ### --- Version 0.53 drv <- dbDriver("Oracle") con <- dbConnect( drv, "user/passwd") d <- data.frame(CDATE = "2004-03-10 10:12:00") ps

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