Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: adpcm dequantization problem (Read 3843 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

adpcm dequantization problem

I just started  learning adpcm.

From the link below

http://wiki.multimedia.cx/index.php?title=IMA_ADPCM

diff = ((signed)nibble + 0.5) * step / 4,
                                  ^^
                                 
    = (signed)( nibble[2] * step + nibble[1]*step/2 + nibble[0]*step/4 + step/8)
                                                                                                        ^^^^
the term step/8 is not exist in the quatization process.

isn't the dequantization the inverse of quatization?

what's the reason for adding step/8

and what will happen if I ignore the step/8 in dequantization step?


adpcm dequantization problem

Reply #1
the term step/8 is not exist in the quatization process.

isn't the dequantization the inverse of quatization?


That page does look a little odd in the way it talks about sign/magnitude and then works with its bias value (which would still make sense but for the parenthesisation around the cast).

In general, bias would be expected in only one of the two processes.  If the quantiser (supposing a round-to-nearest-int quantiser in this case) rounds to -inf, then the set of values which would be rounded to x are [x,x+1), and adding 0.5 to the dequantised value puts it in the middle of that range for the minimum worst-case error.

If the quantiser added 0.5 then it would be rounding to nearest, and any result x must have been from the range [x-0.5,x+0.5), and x would already be in the middle of that range and have the minimum worst-case error.

A reason to round to -inf in the quantiser is to make best use of the range of possible values in a 4-bit number.  Since you normally end up with extra range on the negative side, or you end up with two zero values in sign/magnitude, adding 0.5 to all of those values balances things (at the cost of having no way to express 0).  In a more complicated codec you'd simply use a range of values that was not a power of two, and you would use an entropy coder to take up the slack of un-used bit patterns.