[Flac-dev] Questions about FLAC format from a java coder...
Miroslav Lichvar
lichvarm at phoenix.inf.upol.cz
Sun Oct 5 10:23:14 PDT 2003
On Sun, Oct 05, 2003 at 03:43:08PM +0000, Dan Stowell wrote:
> I'm trying to write a FLAC decoder for my Java audio app. Can I ask
> a couple of questions to this list about the format? I think there
> are a couple of things not-quite-mentioned in the official spec.
>
> RICE CODING: Which order are Rice-coded numbers stored in?
> (a) [sign-bit][low-order bits]["k" zeroes][1]
> (b) [sign-bit]["k" zeroes][1][low-order bits]
> (c) [sign-bit][low-order bits]["k" ones][0]
> (d) [sign-bit]["k" ones][0][low-order bits]
> (e) ...?
(e)
["k" zeroes][1][low-order bits][sign-bit]
> (And I am I correct in saying the sign bit is 1 for positive, 0 for
> negative?)
0 for positive, 1 for negative
> WASTED BITS PER SAMPLE: What does this mean? I can't find a
> reference to what my decoder should do with the
> wasted-bits-per-sample flag.
After decoding subframe decoder should bitwise shift all samples to left.
> FRAME BLOCKSIZE: If a frame's BLOCKSIZE is specified as 0000 ("get
> from STREAMINFO"), should I use the STREAMINFO "maximum blocksize"
> or "minimum blocksize"? Should the two always be equal in this case,
> and should I throw an exception if they aren't?
It can be used only in fixed block size stream, so both values should
be equal.
> RICE PARTITION SIZE: In a zero-partition-order Rice block, the
> documentation says the number of samples in the partition is equal
> to the frame's blocksize. Surely this should be equal to the
> frame's-blocksize-minus-the-predictor-order, since we shouldn't need
> to encode residual for the warmup samples?
You are right.
--
Miroslav Lichvar
More information about the Flac-dev
mailing list