查看单个帖子
旧 2009-05-04, 03:26 PM   #1
yang686526
高级会员
 
注册日期: 06-11
帖子: 14579
精华: 1
现金: 224494 标准币
资产: 234494 标准币
yang686526 向着好的方向发展
默认 【转帖】ac2004 format spec. compression question

ac2004 format spec. compression question
ac2004 format spec. compression question
i'm looking at the spec for the compression, and near the top of
section 4.9 (compression) it says:
following the first literal run, there will be a set of compression opcodes that define 3 values:
compressedbytes 鈥?number of 鈥渃ompressed鈥?bytes that are to be copied to this location from a previous location in the data stream.
compoffset 鈥?offset backwards from the current location, where the 鈥渃ompressed鈥?bytes should be copied from.
litcount 鈥?number of uncompressed or literal bytes to be copied from the input stream, following the addition of the compressed bytes.
the thing which i cannot work out is where the "current location" (referred to in
the "compoffset" description) is.
i thought it should be the location at which the file pointer sits after having read
the "current" opcodes. but, this just gives me junk. i've tried going backwards
from a range of different "current locations", but again all to no avail.
if i knew for sure where the "current location" is, at least i'd know how to set
up my code properly.
it might be a bug in my reader, but it seems to handle reading of the "compressed"
section properly (it always finishes properly). but the data it ends up creating,
through concatenation of the literal & compressed file data, is junk.
for example, after creating the section map, the first two section number/size
pairs are valid:
[1] = 21536
[2] = 416
these first 16 bytes (ie: making up the four, 4 byte integers) are coming from
the first literal run of 17 bytes. but thereafter, the values coming out in the
section map are garbage (ie: they are coming from the first set of compression
opcodes): 0x4c and 0x01.
thanks
yang686526离线中   回复时引用此帖
GDT自动化论坛(仅游客可见)