--- On Sun, 4/5/09, Jonathan Lee <jonathan at sliid.org>
wrote:> Can the bits per sample change from frame to frame?
no, not in the native container (i.e. fLaC header + metadata +
frames). in a raw streaming situation where you are getting only
frames it might be advantageous to support it but I don't know of
anything that works like that.
> Can constant or verbatim subframes have left/side,
> right/side, or mid/side channel assignment? If so, does the
> difference channel have an extra bit per sample?
good question... yes it is possible and the difference channel
always has the extra bps.
> Is it a fatal error if the minimum frame size is larger
> than the maximum frame size (in STREAMINFO)? What about the
> minimum number of samples being larger than the maximum
> number of samples?
they're not fatal. the STREAMINFO is to help inform the decoder
but if you detect invalid values it should be treated as if those
values are unknown.
a decoder implementation with limited memory is allowed to fail
if it can't get accurate STREAMINFO that it needs though. this is
an implementation detail though.
> If the residue bit width is given by an escape code, can
> this escape code be zero? What is the effect of reading
> "zero" bits? (assuming that the stream is not
> advanced and 0 is the value read)
another good one. an escape code of 0 is invalid; should be
treated as reserved for use by a future encoder.
> The MD5 is calculated on the "unencoded data",
> but this leaves a lot of room for interpretation. Does this
> mean the data produced by the decoder, or the data that was
> passed to the encoded when the file was made? If it means on
> produced data, are the channels interleaved? Stored as big
> or little endian? If it means the original data, how can we
> be sure of the format of that data?
this is ill-specified, but it is the channel-interleaved signed
samples, samples truncated to the smalled number of bytes that
can represent the sample, then converted to bytes by shifting
LSBs 8 bits at a time into the MD5 accumulator. see
src/libFLAC/md5.c:format_input_()
> How do I handle negative QLPC shifts, officially? Treat
> them as positive left shifts? Or treat them as an error
> condition? Or treat them as a right shift with the shift
> index taken modulo 32 (as apparently happened with earlier
> versions of the reference code)?
this one's going to haunt me forever... the reference encoder has
avoided negative shifts entirely since 1.1.4. negative shifts
were meant to be positive shifts in the opposite direction but
they were implemented directly with << >> and in C negative shifts
are undefined.
treat as an error for now to avoid bad behavior but I need to
come back to this to specify exactly.
> If I read a signed value that is one bit, what is
> "1" equal to?
-1
> If a sample rate of zero is specified, is this a fatal
> error? Or should it be ignored?
it is technically an invalid sample rate, even though the codec
does not care about the sample rate (it is merely stored and passed
on for playback). I think the reference decoder does not fail on
it but it should.
Josh