Difference between revisions of "Talk:Smacker"

From MultimediaWiki
Jump to navigation Jump to search
m
Line 10: Line 10:
   4. In the "Bit Streams" section, the resulting bytes from reading 5, 6, and 7 bits sequentially seem wrong.  I get 0x1C, 0x32,
   4. In the "Bit Streams" section, the resulting bytes from reading 5, 6, and 7 bits sequentially seem wrong.  I get 0x1C, 0x32,
       0x72, when I assume the bits are packed together.  If I skip ahead to byte boundaries after each read, I get 0x1c, 0x16, 0x6f.
       0x72, when I assume the bits are packed together.  If I skip ahead to byte boundaries after each read, I get 0x1c, 0x16, 0x6f.
Most of those questions can be easily answered if we also had the code to do decoding. Here are the comments on what is known:
# I suppose trees should be built in the same order as they used, this is the way it's done in other places.
# If tree is missing (in header) it should always give zero value for output.
# I agree with that.
# That is also correct. Smacker code reads stream as 32-bit little-endian integer and takes LSB out of it, shifting bit buffer to the right.
BTW, do you have working decoder or just trying to write one?

Revision as of 20:33, 12 March 2006

I've found some errors and places that were unclear to me, which are listed below:

  1. in the "Huffman DPCM" section, no indication is given as to the order of the trees to be read in.  There is documentation 
     on which order the Bases are in (high byte first, right then left) and which order to read the compressed data in (low byte
     first, left then right), but not which order to build the trees.
  2. Under "Huffman Trees" it makes mention of the low byte/high byte trees and says both are optional, but doesn't say how to
     interpret values from the 3rd tree if either one or both of the low/high trees are missing.
  3. The tree shown in "Reconstructing the tree" should have the nodes labeled from left to right 3, 4, 5, 6, 7, 8.  It
     presently shows 5, 3, 4, 6, 7, 8.
  4. In the "Bit Streams" section, the resulting bytes from reading 5, 6, and 7 bits sequentially seem wrong.  I get 0x1C, 0x32,
     0x72, when I assume the bits are packed together.  If I skip ahead to byte boundaries after each read, I get 0x1c, 0x16, 0x6f.

Most of those questions can be easily answered if we also had the code to do decoding. Here are the comments on what is known:

  1. I suppose trees should be built in the same order as they used, this is the way it's done in other places.
  2. If tree is missing (in header) it should always give zero value for output.
  3. I agree with that.
  4. That is also correct. Smacker code reads stream as 32-bit little-endian integer and takes LSB out of it, shifting bit buffer to the right.

BTW, do you have working decoder or just trying to write one?