4: 2009-11-17 (火) 12:07:37  |
現: 2024-01-08 (月) 12:59:03 ゲスト |
| - | * [[tek1]]の続き | + | TITLE:x |
| | + | * [[tek1]]の続き [#n6cd3da5] |
| | -ここではtek0からのアイデアの連続性やその他の読み物的なことについて書く | | -ここではtek0からのアイデアの連続性やその他の読み物的なことについて書く |
| | | | |
| - | * UC0のアイデア | + | * UC0のアイデア [#rb30220d] |
| | -UC0符号は、tek0でのdfの発展型である。 | | -UC0符号は、tek0でのdfの発展型である。 |
| | --ここで少しおさらいしておくと、dfはd3の発展型であった。つまりd3→df→UC0ということになる。 | | --ここで少しおさらいしておくと、dfはd3の発展型であった。つまりd3→df→UC0ということになる。 |
| | -ちなみに符号寿命という考え方は、LHAがたまに静的ハフマン符号を作り直しているらしいという話を聞き、なるほど効果がありそうだと思って入れた。実験したらいろいろ分かったので、全部を一気に切り替えるのではなく、複数の寿命を扱えるようにした。 | | -ちなみに符号寿命という考え方は、LHAがたまに静的ハフマン符号を作り直しているらしいという話を聞き、なるほど効果がありそうだと思って入れた。実験したらいろいろ分かったので、全部を一気に切り替えるのではなく、複数の寿命を扱えるようにした。 |
| | | | |
| - | * UC0 vs ハフマン | + | * UC0 vs ハフマン [#mf41a126] |
| | -まず、たとえば0～255などといったある程度狭い数値しか扱わないと確実にわかっている場合、ハフマン符号のほうが圧縮率の観点では有利である。しかし、任意の32bitの数値をエンコードするなどの用途になると、もはや4G個のハフマンテーブルを並べるわけには行かず、かといって動的ハフマンでもこの数は扱いにくいし速度が出ないので、UC0が有利である。 | | -まず、たとえば0～255などといったある程度狭い数値しか扱わないと確実にわかっている場合、ハフマン符号のほうが圧縮率の観点では有利である。しかし、任意の32bitの数値をエンコードするなどの用途になると、もはや4G個のハフマンテーブルを並べるわけには行かず、かといって動的ハフマンでもこの数は扱いにくいし速度が出ないので、UC0が有利である。 |
| | -LHAで使われているらしい方法として、32bit数値をそのままハフマンにかけるのではなく、総ビット数（0～31）をハフマン符号で表して、後続のbitをそのままビットストリームに並べるという方法があるらしい。この場合後続は先頭の1bitは必ず"1"なのでこれを省略するようだ。この方法のほうが圧縮率がUC0よりもいいかもしれない。 | | -LHAで使われているらしい方法として、32bit数値をそのままハフマンにかけるのではなく、総ビット数（0～31）をハフマン符号で表して、後続のbitをそのままビットストリームに並べるという方法があるらしい。この場合後続は先頭の1bitは必ず"1"なのでこれを省略するようだ。この方法のほうが圧縮率がUC0よりもいいかもしれない。 |
| | -ハフマンもUC0も展開速度を上げることはそんなに難しくはないが、速度を上げる方法を使うとプログラムは長くなる。速度を上げる方法を積極的に使わなくてもUC0は十分に速いが、ハフマンではtek0なみに遅くなる。 | | -ハフマンもUC0も展開速度を上げることはそんなに難しくはないが、速度を上げる方法を使うとプログラムは長くなる。速度を上げる方法を積極的に使わなくてもUC0は十分に速いが、ハフマンではtek0なみに遅くなる。 |
| | | | |
| - | * スケーラビリティ | + | * スケーラビリティ [#c0f7596e] |
| | -l2d3やtek0では、圧縮対象のファイルは4GBまでしか考えていなかったし、将来拡張したくなったときのための拡張フラグなどをまったく残していなかった。 | | -l2d3やtek0では、圧縮対象のファイルは4GBまでしか考えていなかったし、将来拡張したくなったときのための拡張フラグなどをまったく残していなかった。 |
| | -tek1では（ちなみにtek2も）、いずれは大きなディスクイメージを扱うことにも配慮し、OSACMPヘッダ部分のファイルサイズゾーンにs7s符号を使って4GB以上を表現できるようにしたし、拡張フラグ類も準備した。 | | -tek1では（ちなみにtek2も）、いずれは大きなディスクイメージを扱うことにも配慮し、OSACMPヘッダ部分のファイルサイズゾーンにs7s符号を使って4GB以上を表現できるようにしたし、拡張フラグ類も準備した。 |
| | --要するにパラメータ（ファイルサイズやバッファサイズ）のフォーマットに起因する上限がなければよいだけのことである。展開のことを考えれば、もちろん何らかの上限があるほうが好ましいが、それがいつか自らの可能性を縛る壁になるので、展開ルーチン側でチェックして対応できないものはできないといわせるほうが前向きであろう。 | | --要するにパラメータ（ファイルサイズやバッファサイズ）のフォーマットに起因する上限がなければよいだけのことである。展開のことを考えれば、もちろん何らかの上限があるほうが好ましいが、それがいつか自らの可能性を縛る壁になるので、展開ルーチン側でチェックして対応できないものはできないといわせるほうが前向きであろう。 |
| | | | |
| - | * こめんと欄 | + | * こめんと欄 [#edcfc8ef] |
| | | | |
| | #comment | | #comment |
