[Flac-dev] Re: Problem with CRAM and flac-1.1.2

[Josh Coalson]

sorry if I'm not reading this close enough, I'm ploughing through
a bunch of emails here, but the source of this problem is what I
consider a design defect in FLAC which uses frame numbers to save
space, and confusing logic for determining whether the frame number
or sample number is stored.  if I had it to do again I would just
have it store the sample number always.

if you are going to store the sample number, this complex logic
must be observed exactly, and even then, it may not be suitable
(e.g. cannot go back to using frame numbers after using sample
numbers in a frame).

--- Josh Green <josh at resonance.org> wrote:

> 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 header):
> http://flac.sourceforge.net/format.html#frame_header
> 
> 
> Not quite sure the best way to fix this.  I'd love to hear any
> ideas..
> 
> CRAM files usually consist of several audio samples all packed into
> the
> same file (with binary segments compressed with zlib).  FLAC is used
> to
> store only the compressed audio and no other FLAC headers
> (STREAMINFO,
> etc) are actually found in a CRAM file.  A single sample could (and
> is
> currently) compressed using a single block size.  It might be
> advantageous to change the block size between audio samples though,
> depending on the individual sample parameters (sample rate, length,
> etc), I have yet to determine a good method for guessing a good block
> size though.
> 
> Seems like it might be a little bit of a waste to add 2 bytes to
> every
> frame in this case (but I imagine that's probably a trivial amount). 
> I
> suppose the FLAC stream decoder could be re-created for each sample
> with
> the appropriate fixed block size STREAMINFO which is forged, but that
> leaves it up to CRAM to determine what block size is stored in the
> FLAC
> FRAME_HEADER and seems a little messy anyways.  Any input
> appreciated.
> 
> Best regards,
> 	Josh Green


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com