[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