Talk:Smacker

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?

BTW, folks, please sign your comments when you add one. It helps the flow of discussion. It's one of the icons when you edit, second from the right, looks like this in Wiki:--~~~~. Thanks, --Multimedia Mike 00:27, 13 March 2006 (EST)

Answers to questions + more

1. It's straightforward. If we have 16bits stereo sound:
   • read bit flags
   • read trees #1, #2, #3, #4
   • read initial bases bytes right_hi, right_lo, left_hi, left_lo
   • unpack left_lo_delta using tree #1, left_hi_delta / #2, right_lo_delta / #3, right_hi_delta / #4
2. Good question. In fact, smacker itself doesn't know what to do. It just check bits and if it's says "no tree" skip tree loading, without any checks for this particular tree presence later. I believe there is no situations where these trees are not present, but used.
3. Yes, that was a mistake, spotted it long time ago.
4. Correct. Looks like I've messed with my calculations somewhere, aww...

One missed, but very important thing in the description. FrameSizes description should be corrected on this manner: Array of sizes (lengths) of each physical frame in the file. Addidionally, bit 0 of size indicates whenever frame is a keyframe or not. Bit 1 used for some other (unclear so far) purposes. NB: You DON'T need to shift these bits out to get the length. Instead, CLEAR them.

In Bit Streams please remove "except v4 audio, " part. It's wrong.

Hope this helps... --Multimedia Mike 09:50, 13 March 2006 (EST)

compressed audio

the audio chunk section mentions that compressed audio can be in either Huffman DPCM or Bink audio.

Is there a way to determine which is used? The file signature perhaps?

update: oh, just found it i think - bits 2-3 of the AudioRate field.

--Toshok 14:17, 25 March 2006 (EST)