[Flac-dev] FlacPak

[Josh Coalson]

--- Josh Green <jgreen at users.sourceforge.net> wrote:
> 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.

it really depends on how small the samples are.  I can't image
a useful sample that is also small enough to be penalized by
the frame overhead, which is like you say, just a few bytes.

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

if the 40 or so bytes of fLaC + STREAMINFO is not too big to
ruin the compression of small samples, it may make the decoding
implementation easier.  if you want to remove all metadata,
the way to do it is use the stream encoder, and in your write
callback, if the 'samples' argument is 0, you know it's writing
metadata (true also for the 'fLaC' part), so you just don't write.
now you will have a raw FLAC stream.

the phrase about STREAMINFO being mandatory refers to using FLAC's
native container for file storage.  it's not clear in the docs.

on the decoding side, the stream decoder does not require the
metadata either,  when you start decoding, it will sync on the
first frame.  the consequences of not having a STREAMINFO block
means: 1) no MD5 checking; 2) you will have to decode a frame
before you can determine the sample rate, resolution, etc.

Josh


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree