[flac-dev] Residual Error Encoding

[Dominic Mason]

To those interested:
     You mention on the website that you use a Rice style encoding scheme
for residual error encoding. After some experimentation, I believe I've
have discovered a method which might be more efficient.
     Take the signs away from the errors storing them each as a one bit
prefix. Now say we consider two errors. Each error will require at least
one bit (probably more) of overhead to say which Rice partition it is in.
However, if one writes the sum of both errors, and then the first error,
only one Rice partition is needed for the sum. The first error can go in a
new partition bounded by the sum. Therefore, though it will cost extra bits
by being in an oversized partition, it will gain bits by not requiring
which partition it is in to be described. And the sum can only become one
bit longer than the largest of the two errors. (If it is longer than the
largest error, then it must make for a fairly efficient partition for the
first error.) So, when all errors are combined in pairs, I usually save
space. Also, the sums might require fewer different partitions, since there
are fewer of them.
     But usually it is more efficient to combine the sums in pairs as well,
stating the first sum and the meta-sum. Continue as though building a
Huffman tree. At the end of this process, no Rice partitions will be
necessary. The only number with an undetermined magnitude in the block will
be the sum of all errors. (I encode it via logarithmic rice: suffix length
= 2^length of prefix.)
     This method has been more efficient than any I have style of Rice
encoding I have used. Perhaps you do something like this already. I'm
sorry. I don't know because I have not had the time to test Flac's rice
encoding. I'm working on Windows and haven't been able to build it
properly. (I'm trying to follow the instructions here:
http://mixxx.org/wiki/doku.php/build_windows_dependencies#libflac
)
     Anyhow...

                                             Hoping someone at least found
this interesting,
                                             -Dominic Mason


cz.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20160622/59450440/attachment.html>