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

Josh Green josh at resonance.org
Sun Jul 30 11:27:03 PDT 2006


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




More information about the Flac-dev mailing list