On Fri, Feb 11, 2005 at 11:57:58AM -0800, Josh Coalson wrote:
> I am contemplating fixing this problem in the format eventually
> (along with others) but older decoders will not be able to read
> such streams, so if I do it, it will have to be done carefully
> to avoid disrupting users. I would bundle it up with other
> format changes and compression increases.
Would it be possible to add to your list a modification of partitioned
rice coding? Something like this:
RESIDUAL_CODING_METHOD_PARTITIONED_RICE
<4> Partition order.
- RICE_PARTITION+ There will be 2^order partitions.
+ RICE_PARTITION+ There will be
+ (frame's blocksize - prediction order + s - 1) / s
+ partitions, where s = frame's blocksize / 2^order
+ is partition size.
RICE_PARTITION
<4(+5)> ...
<?> Encoded residual. The number of samples (n) in the partition is
determined as follows:
* if the partition order is zero, n = frame's blocksize -
predictor order
* else if this is not the first partition of the subframe,
n = (frame's blocksize / (2^partition order))
- * else n = (frame's blocksize / (2^partition order)) -
- predictor order
+ * else n = (frame's blocksize - prediction order) % s
It would not break decoding of old files and it would allow:
* partition size <= prediction order, not really useful though
* reasonable partitioning for frames with blocksize != 2^something,
would be good for variable blocksize coding
--
Miroslav Lichvar
_______________________________________________
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
