similar to: FlacPak

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

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

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

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

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

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

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

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

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

A user of CRAM (http://swami.sourceforge.net/cram.php) sent in a bug report related to decoding of CRAM files. This issue occurs with flac-1.1.2 but not previous versions (such as flac-1.1.1). Note that the same file is used for this test (hopefully ruling out any issue with the encoder). Details of the issue: When calling FLAC__stream_decoder_process_single() the error callback is triggered

Replying to myself once again, since I seem to have found the answer I was looking for. Sorry for the noise. It seems CRAM is indeed misusing FLAC, since stated in the Notes section of the FLAC format for the FRAME_HEADER is the fact that only block size values 0110 and 0111 can be used for variable block size data (i.e., the block size is specified as an 8 or 16 bit value at the end of the

Yes, it's finally here. See the homepage for details, but here's a summary: - 10-15% decoder speedup - 24-bit input support restored - more robust plugins - new metadata block for Vorbis-style tags - vastly improved metadata editor - fixed bug with pipes and Windows - new libFLAC++, a C++ object wrapper around libFLAC - new metadata editing interface in libFLAC and libFLAC++ - and

> 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

Hello all, I am writing an implementation of a FLAC decoder and I am polishing up some details. The format <http://flac.sourceforge.net/format.html> page leaves some room for interpretation. Can anyone help me by clarifying the official rules about the following? Most of them are degenerate cases that probably don't happen in practice: Thanks, --Jonathan Can the bits per sample

Hi. I was wondering if there was any interest in extending the flac container format to support sample rates above the 655k current limit. Please note this is not for using ridiculously high sample rate sourced audio for some imaginary audible benefit. I've been involved in some experimentation with offline upsampling in software prior to delivery to an external DAC as a way to bypass the

I'm writing a program that plays FLAC files using the libFLAC API's. Is there a specific way I'm supposed to handle multiple STREAMINFO metadata blocks? For example, should I ignore all but the first, or all but the last? The format spec doesn't mention anything. Thanks, - Brian Waters

Federico Miyara wrote: ... > The file format allows some unused fields for future use, such as the > padding block. It could include a flag to indicate a change in the > format adding one more streaminfo byte which would allow up to 256 > channels (actually, 256 + 8), or it could trigger a new byte when 11111111. > > There is also an invalid block identifier (127) which could be

It's certainly best to honor what the specification says. My assumption is that a "stream" could also be a continuous broadcast, not just a file. With a hypothetical server streaming FLAC bitstreams, I would assume that the most recent STREAMINFO is valid until another one comes along. If you're writing a file player, then perhaps you can trust the spec and assume