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 actually used, and create a new one "FLPK" FlacPak. This format will be a generic way to compress files containing audio and binary data (files will be viewed as simply interleaved chunks of audio and non-audio data with some extensions such as interleaved and non-interleaved stereo streams, differing bit widths, etc). I will be using this primarily for instrument patch formats (such as SoundFont, DLS2, GigaSampler, etc), but it could be extended to other binary/audio formats as well. The encoder for FlacPak will have knowledge of the format it is compressing, the decoder on the other hand will be generic and simply re-compose the file using a table to re-interleave the blocks of audio and non audio data. Essentially all non-audio data will be concatenated and compressed along with a relocation table in the application meta data chunk (or perhaps multiple meta data chunks if it exceeds 16MB meta data limit). 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 pair of mono samples (in separate locations in the original file) could be encoded as stereo audio (and re-split on decode). Last I posted to this list, there wasn't a way to change encoding parameters on the fly with the current FLAC API, is this still the case? If it is, would it be possible to add multiple separate (serial) streams in the same file? In other words, if the current API doesn't allow changing parameters on the fly, could the FLAC encoder instance be closed and then re-opened with different parameters and the decoding side still work? Another question I have is about sample rate. Does this affect the encoding/decoding process at all or is it mainly informational for playback purposes? The samples in an instrument patch often differ in sample rate. I'm excited about finalizing this specification, since there is a real need for an open standard for instrument patch compression (there are already several proprietary formats out there that are a pain when it comes to other operating systems, businesses going bankrupt, etc). Any help anyone can give me would be greatly appreciated. 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 thinking that it would be nice to just have it look like a flac file, so some extraction of audio could be done treating it generically, but I realize that this isn't very useful to begin with (one would end up with a chunk of sample audio, but no way to extract individual samples without understanding the meta data chunk). There is also some little hacks that would need to be done to compress the binary data into multiple meta data chunks when it exceeds 16MB (probably not a likely situation though, in the case of instrument banks).> if you're talking about 2) then: > you can't change encoding params on the fly (yet) but in this > case I would advise against it even if you could, because you > are storing to your own container, and each clip may not even > be contiguous. better to use a fresh stream encoder for > each clip. your decoder will be aware of the boundaries > somehow and use fresh stream decoders for each clip. (I'd > advise against re-using the same stream decoder for the same > reason). >My previous thinking was of storing all the audio data together (so it would be made contiguous). But with the thought of using my own container, the encoded audio could in fact be stored serially with individual compressed binary chunks. I should probably do a comparison of header overhead between the two methods (its likely there isn't any difference, or very minimal). In the case of split stereo sample data one channel would still need to be relocated to another position in the file, but I like the idea of most of the data being in sequential order. Some of the samples might be quite small (like under 1k), from the format it appears that there is only about 8 or so bytes overhead for a single frame and sub frame header so I suppose there probably isn't really an issue with the frame size becoming a significant overhead, but I'm curious if combining small samples would make sense in that case. Likely its more trouble than its worth.> also, if using your own container, you don't really need the > STREAMINFO block, might as well just throw away all metadata > when encoding. >Looking at the API, would the stream encoder/decoder be the option to use for this? Or is there a more appropriate interface? Using that interface I suppose I could ignore the "fLaC" signature (at least for each sample) in the write callback, and I guess I would also need to ignore the STREAMINFO meta data block as well. Will the stream encoder/decoder still work in this regard? (The format specification says that the STREAMINFO block is mandatory, but is that the case with using the decoder as well?) I suppose it may also be necessary to have the "read" callback in the stream decoder forge a fLaC signature and STREAMINFO meta data block, but that seems a little hackish, but will do this if necessary.> Josh >Thanks a lot for the information, I'm excited about working on this project again. I'd like to try and make a campaign out of it, make a nice logo and little banner icons that people can put on web sites and the like. Its about time proprietary formats cease to be used for instrument compression (especially those that don't write clients for other operating systems). Even windows users have experienced this with sfpack, since they recently stopped supporting it. Nothing more annoying then downloading a zip or rar instrument file only to find it has also been compressed with sfark or sfpack. I guess the sfark people deserve some credit, they have at least been promising a Linux client for a few years now (still no sign of it though). I was thinking of making FlacPak associated with flac (seems appropriate since flac will be the primary technology used in the format), so I was wondering about basing the FlacPak logo on the one found on the flac web site (with the green/yellow/red level meter bars). How do you feel about this? Any graphics I come up with in this regard I would certainly clear with you before using it. Thanks again. Josh Green
--- 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 pair of mono samples (in > separate locations in the original file) could be encoded as stereo > audio (and re-split on decode). > > Last I posted to this list, there wasn't a way to change encoding > parameters on the fly with the current FLAC API, is this still the > case? > If it is, would it be possible to add multiple separate (serial) > streams > in the same file? In other words, if the current API doesn't allow > changing parameters on the fly, could the FLAC encoder instance be > closed and then re-opened with different parameters and the decoding > side still work?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. if you're talking about 2) then: you can't change encoding params on the fly (yet) but in this case I would advise against it even if you could, because you are storing to your own container, and each clip may not even be contiguous. better to use a fresh stream encoder for each clip. your decoder will be aware of the boundaries somehow and use fresh stream decoders for each clip. (I'd advise against re-using the same stream decoder for the same reason). also, if using your own container, you don't really need the STREAMINFO block, might as well just throw away all metadata when encoding.> Another question I have is about sample rate. Does this affect the > encoding/decoding process at all or is it mainly informational for > playback purposes? The samples in an instrument patch often differ in > sample rate.no, it will only really affect what the blocksize should be set to for the best compression. Josh __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree