圧縮・復元 相談室

アルゴリズムは別スレで

アルゴリズムを別にしたら
語るべき事は何もありません

（ﾟ∀ﾟ　）2

ん？ZIPからどうやってファイルを取り出すかは
ZIPアルゴリズムを完全に理解しなくたっていいでしょ。

　　　∋oノハヽo∈　／￣￣￣￣￣￣￣
　　　　 从oﾟーﾟ从＜　新スレおめでとうございま−す♪
　　　= ⊂ 　　）　　 ＼＿＿＿＿＿＿＿
　　　= (__/"(__)　トテテテ　

>>4
既存のライブラリを使用せずにZIPからファイルを取り出すのなら
アルゴリズムも、それなりに理解する必要はあるし
ライブラリを使用するなら環境に依存した問題で
特に難しい事ではないので環境にあったスレで聞けば問題なし

>>4
Lhasa使えよ！

俺はライブラリの使いかたが知りてーんだよ
VBでどうすればいい？

要は>>1を不可逆圧縮しちまえってこった。

むしろ>>1の脳みそが不可逆圧縮だな。

どんなライブラリーでも使える共通インターフェース
みたいなのないの？

×ライブラリー
○ライブラリ

×インターフェース
○インタフェース

>>12
何を根拠に○×を付けてるのか教えてくれ

×ライブラリ
○ライーブラリ

×インタフェース
○イーンタフェース

3音節以上はーをつけない

>>12-13
こっちでやってくれ
http://pc3.2ch.net/test/read.cgi/tech/1014691583/l50

母音はのばすとｶｺｲｲ

>>15
これは？
らいぶらりぃ
いんたぁふぇぃす

>>15
お前が決めたルールか？

ちんこはのばすとｶｺｲｲ

こっちでやってくれ
http://pc3.2ch.net/test/read.cgi/tech/1014691583/l50

ちんこーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

>>21
廃スレなんだし、いいでしょ

ボインとちんこ、どっちをのばすべきか？

>>16==21?
あげなければ良いんじゃないの？

ﾊｧ?

>>25＞あげなければ良いんじゃないの？
うわ・・
出たよ、雑談板ルール。
マジで冬厨増えたな。

共通インターフェースないのかな？見つかんなかった。
いろいろな圧縮ファイルに対応したいんだけど、全部の仕様
調べないとならないの。ヽ（`Д´）ﾉ ｳﾜｧｧｧﾝ

ひとつお前は勘違いをしている。
馬鹿がプログラミングできると思うなよ。

>>28
とりあえず統合アーカイバへ逝け。
そして不可逆圧縮されなされ。

勘違いって何？

仕様を調べる位が嫌なら
人様が作ってくれたものを使うな

されなされ
　↑
どおゐう意味？？

なんと統合アーカイバDLL使えばコマンドラインで操作する感覚で圧縮、展開できますよ！！

共通インターフェースなんて作るの簡単でしょ？
Win32のCreateFile,ReadFile,WriteFile,FirstFindあたりを
用意すればいいんでしょ。ﾀﾞﾒ？

>>33
You'd like to be compress in lossless method.

>>35
全然ダメ。

>>35
なんで（；´Д｀）

>>37だった

＞共通インターフェースなんて作るの簡単でしょ？
作れない癖に簡単だと分かるのか？ｱﾌｫよ

>>34
っつーかアレは exe をDLL化しただけっつー話も…
ライブラリっぽいのは書庫内のファイルを列挙できる部分だけのよーな。

ライブラリとフレームワークとコンポーネントとパッケージとモジュールとクラスの違いを教えてください

>>40
どこが難しいの？（　´∀｀）

>>43
そー思うなら とっとと作ってください。

逝かれてんのか、こいつ

ガキが話相手欲しがってるだけ
放置しとけ

なんか具体的に指摘できる人がいないみたいだね。
具体的に指摘できないやつは（・∀・）ｶｴﾚ!!

釣りｽﾝﾅ

結局ライブラリの使い方が分からん1が粘着に答えを求めるスレってことでいいの？

DNA系列や画像、音声などの圧縮を行うような、
特殊化されたライブラリのインタフェースまで統合したいの？

>>48 >>49
>>47

>>50
zip,lzh,rar,cabみたいな一般的なやつを考えてます。

統合アーカイバ行ってこい。
ついでに削除依頼も忘れずにな。

>>51
> zip,lzh,rar,cabみたいな一般的なやつを考えてます。
zip形式だが、Javaで、
java.util.zipパッケージ内のクラスを使うのはどう?
漏れは使ったこと無いけれど。

それか、邪道だがjakarta-antのzipタスクを使うのはどうかな。

Nohrのソースをぱくる

Noahだった。。。

>>53
＞java.util.zip
ストリーム（・∀・）ｲｲ!!

＞jakarta-antのzipタスク
これはよくわからなかった。
ビルドツールがZIPを生成するのかな。

＞Noah
みつけました。調べるよヽ(´ー｀)ノ

>>57
>ビルドツールがZIPを生成するのかな。
そうです。まずantの使い方を覚えるしかないかな。
Javaやるならant覚えると便利です。
antはJBuilder,Forte for Java, Eclipseからでも呼び出せますし。
でもjava.util.zipを使えるならantでZIPタスク使わなくてもいいね。

>>58
java.util.zip のは
ファイル名をうにこーどで格納するため
日本語のファイル名を扱った場合問題が出る。

まぁ問題を回避するコードを書くのはそんなに手間ではないが。

ant の zip タスクも同様の問題なかったっけ？

>>59
> java.util.zip のは
> ファイル名をうにこーどで格納するため
> 日本語のファイル名を扱った場合問題が出る。
> まぁ問題を回避するコードを書くのはそんなに手間ではないが。
> ant の zip タスクも同様の問題なかったっけ？
半角かな文字同様、日本語のShift_JISファイル名使うなんて問題外、
って言ってるのは今では古いですか?

antにしてもJavaにしても、

ソースを全部UTF-8(Unicode)で書いてしまえばいいんじゃよ。
コンパイルオプションのencodingにUTF-8を付ける。
それでもだめならnative2ascii( or antでnative2asciiタスク )を使う。

JavaもXMLもUTF-8が標準なのだ！
........解決になってないかな?

>>1 = MD5( >>1 )
あまりに単細胞なのでハッシュしても同じとは・・・恐るべし>>1

Rar!のリカバリレコードどうやってるか知ってる人いない？

512b/256bの多重チェックサムらしいんだけど

知ってるけどタダじゃ教えられないな。

WinXPで使ってる.zipライブラリってどうやって使う？

統合アーカイバDLLってコマンドラインの書き方統一されて無くて使いづらい。

>>63
☆
|＼
|∴∴
|・ω・`)＜おしえてよ
|ｏ□ｏ.
|―ｕ'

IP記録実験
http://qb.2ch.net/test/read.cgi/accuse/1042013605/

1 名前：ひろゆき ◆3SHRUNYAXA ＠どうやら管理人 ★ 投稿日：03/01/08 17:13 ID:???
そんなわけで、qbサーバでIPの記録実験をはじめましたー。

27 名前：心得をよく読みましょう 投稿日：03/01/08 17:20 ID:yL/kYdMc
SETTING.TXT管轄でないということは全鯖導入を視野に、か？

38 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:22 ID:rLfxQ17l
>>27
鋭いです。

73 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:27 ID:rLfxQ17l
＞ところで、IPが抜かれて何か今までと変わることってあるのでしょうか？
・今までより、サーバが重くなる。
・裁判所や警察からの照会があった場合にはIPを提出することがある。

>>352
ひろしま必死だなっと・・・

fewfwfeefwefw

IP記録実験
http://qb.2ch.net/test/read.cgi/accuse/1042013605/

1 名前：ひろゆき ◆3SHRUNYAXA ＠どうやら管理人 ★ 投稿日：03/01/08 17:13 ID:???
そんなわけで、qbサーバでIPの記録実験をはじめましたー。

27 名前：心得をよく読みましょう 投稿日：03/01/08 17:20 ID:yL/kYdMc
SETTING.TXT管轄でないということは全鯖導入を視野に、か？

38 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:22 ID:rLfxQ17l
>>27
鋭いです。

73 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:27 ID:rLfxQ17l
＞ところで、IPが抜かれて何か今までと変わることってあるのでしょうか？
・今までより、サーバが重くなる。
・裁判所や警察からの照会があった場合にはIPを提出することがある。

スレってなんですか？(´Д｀)

>>531がいいこと言った

まだっすかー？

★とトリップが違うじゃな。

半角板がおもしろい

ネット弁慶

>>932

そう思うねぇ　

マンコとかきまくれるのは2chだけ！！ということに変わりはない

母音はのばすとカコイイ

1個、10個、100個、1000個、万個。

関係無いのは分るけど、粘着サンしつこすぎます。

あー、そっか。まぁしょうがないですね。

質の低い書き込みを減らしたいのに
質の低い板を生かしておくのはどうしてなんでしょうか？

てゆうか、２ｃｈが来年あたり消滅している可能性もあるっしょ。

なんということだ・・・・
移住先をさがさないとな。

(；´Д`)ﾊｧﾊｧ

あっ、漏れと同じ串だ

賛成！えらい。よく思いついた、あんたは凄い！天才！神！シャッチョウサン！

======2==C==H======================================================

　　　　　　　　　２ちゃんねるのお勧めな話題と
　　　　　ネットでの面白い出来事を配送したいと思ってます。。。

===============================読者数： 139038人　発行日：2003/1/10

なにやら、連日メルマガだしてるひろゆきです。

そんなわけで、ログ記録実験ですが、いちいちサーバ指定するのが面倒なので、
全部のサーバに入れてみました。

重くなって落ちたりしてもご愛嬌ってことで。。。

んじゃ！

────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────

内部告発も何も、今までここで内部告発が行われ
世の為人の為になったことなどどれだけあっただろうか。
むしろ違法行為のほうがはるかに多いような気がしてならぬ。

winnyの発端となったスレッド
http://tmp.2ch.net/download/kako/1017/10175/1017590243.html

開発者はこのスレの氏

削除板に書き込む時いちいち設定し直すのが面倒臭いから

元々パク(ry

電波を演じてるのか、ほんものの電波なのか・・・
４００レス以上演技は続かないかな・・・

ウエー、ハッハッハ

288 ：ひろゆき ◆3SHRUNYAXA ：03/01/08 17:56 ID:rLfxQ17l
＞厨房板は本当に閉鎖なのか？
初耳。

質の低い書き込みの例

302 名前：心得をよく読みましょう ：03/01/11 21:57 ID:A+3kp3mQ
いやそんな今時な煽りやられてもな

ただ俺は「誰もお前には聞いてねーから大人しくROMってろや低脳」って言いたいんだよｗ
理解出来た？？

最高裁への上告は認められなくなったから、これで事実上判決確定だよ。
逆転も何もないって。
勢いで上告なんかしても一発で上告却下(門前払い)だよ。

二審も一審を支持。これに対して上告しようにも、
刑事訴訟と同様、自由に上告できるってもんでもないのです。
民事訴訟法312条 （上告の理由） 1項
「上告は、判決に憲法の解釈の誤りがあること
その他憲法の違反があることを理由とするときに、することができる。」
http://www.m-net.ne.jp/~doba/goto/hon.htm

ようするに上告しても今の制度では100％無駄。
これで完全終了ってことか。

少しは効果があるみたいだな。

ども。
ってことは IP 記録ってのはやっぱ揉めた時用の
"当事者同士でやってね"　っていうメッセージ & 仮 Flow なんですかね？

にしても　・・・うまく頭に入っていかないなぁ。。

？

（＾＾）

さーど じゃなくて さんど だろ。

（＾＾）

データ圧縮について勉強したいのですが
どんな本を読めばよいのかわかりません。
わかる方がいれば教えてください。

>>105
データ圧縮ハンドブック
http://www.pearsoned.co.jp/washo/prog/wa_pro30-j.html

不可逆な圧縮で、情報源が時間とともにゆっくりと変化していくものを
想定しています。
ちなみに今は、「情報と符号化の数理」という本を読んでいます。

「文書データ圧縮アルゴリズム入門」(CQ出版社)の復刊きぼんぬ！
漏れは大学の図書館で借りたこの本のおかげで圧縮にはまった。

このサイトはいいね
http://www.ingnet.or.jp/~kojif/mu/comp/

>ちなみに今は、「情報と符号化の数理」という本を読んでいます。
それを読めば十分というか
それより高度な内容の本はない。

>>107
培風館の他の書籍で、たとえば
現代シャノン理論、植松友彦著
情報源符号化・無歪みデータ圧縮、情報理論とその応用学会編
情報理論における情報スペクトル的方法、韓太舜著
情報理論、橋本猛著
などを読むとよいだろう。

（＾＾）

lzopはディレクトリ情報もてないの？

外人さんは凄いな。
どう圧縮したらLet It Be（レットイットビー）がレルピーになるのか小一時間・・・。
聞いた奴もレルピーと聞いてLet It Beと復元する能力に小一時間・・・。

>114

おまえはいいことにきがついた。
それが人間のもってる辞書圧縮機能というやつだよ

>>115
熟達すると、文脈だけで次に言いたいことがわかってしまう。
これを阿吽とか、ツーカーの仲とかいう。アイコンタクトもそれに入るかな。

あとは、反射神経、夢、なども人間に組み込まれた圧縮機能といえよう！

プッ

>117

ちんこ

□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□
□□□□□□□□■■□□□□□□□□□□□□□□□□□■■□□□□□
□□□■■■■■■■■■■■■■□□□□□□□□□□□■■■■□□□
□□■■■□□□□□□□□□□□□□□□□□□□□□□■■□□□□□
□□■□■■■■■■■■□□■□□□□■□□□■■■■■■■■■■■
□□■□□□□■■□■■□■■□□□□■□□■■■□■□□□□□■■
□□■□■■■■□□□■■□□■□□■■■□■□□□■□□□□□□□
□□■□□■■□□□□□■■■■□□□■□□■□■■■■■■■■□□
□□■□■■■■■■■■■■■□□□□■■■■□□□■□□□□□□□
□□■■■□□■■□■□□□■■□■■■□□■□□□■■□□□■■□
□□■■■■■■■■■■■■■■■□■□□□■□□□□■■■■■□□
□□■□□□□■■□■□□□□□□□□□□□■□■□■■□■■□■□
□■■□□□□■■□■■□□□□□□□□□■□□■□■■□■■□■□
□■□□□□■■□□□■■□□■■□□□■■□□■■■■□■■■■□
■■□□□■■□□□□■■■■■■□□□■□□□□□■■□■■□□□
□□□■■■□□□□□□□■■■□□□□□□□■■■■■■■■■■■
□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□

ttp://www.geocities.co.jp/Playtown-Denei/1184/satoimo/

他のスレにこんなのあったぞ

>>120
どーせなら4/1になってから披露すれば良かったのに。

>>121
どっかのスレに作者らしき奴が居たような気がする。

zipとgzip(zlib)ってアルゴリズムの組み合わせは一緒なんですか？
それでZipのアルゴリズムは”lz77->ハフマン”で正しいの？
するとどこらへんがzipとlhaは違うの？

タフマソ

>>123
gzip, lha のアルゴリズム的な違いはほとんどないです。
したがって、圧縮率もほぼ同等です。
ツールとしては、単体で圧縮しかできない(gzip)のか、
書庫化できる(LHA)のか、で大きく違うわけで。

（＾＾）

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

RARの圧縮アルゴリズムって
何使ってるんでしょう？

ここで聞かずに作者に聞け

━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―

　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

ﾎｫｰｼｭ！

それよりGIFはタダで使えるようになったのか？

日本では来年の6/19に特許が切れるらしいが。

「GIFの特許切れでPNGあぼーん」なんてほざいてるﾔｼ、ほんっと何もわかってないよな。

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

（＾＾）

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

みなさん、統合アーカイバプロジェクトのライブラリを使ってますか？

誰もいらっしゃいませんか？

各APIの関数名が統一されていないので、ダイナミックリンクが大変ですよね。
何故こんな仕様になっているんでしょうか？
　　　　unlha32.dll は Unlha、UnlhaOpenArchive、UnlhaCloseArchive、etc
　　　　unzip32.dll は UnZip、UnZipOpenArchive、UnZipCloseArchive、etc
　　　　ungca32.dll は UnGCA、UnGCAOpenArchive、UnGCACloseArchive、etc
　　　　tar32.dll は Tar、TarOpenArchive、TarCloseArchive、etc
　　　　（他にも色々）
これ、使いにくいですよね。

私は、こうやって解決（？）したんですが、皆さんはどうなさってますか？
　　　　std::string api = "Unlha";
　　　　unlha 　　　　= ( UNLHA 　　　　　)GetProcAddress( dll, ( api + "" 　　　　　　　　).c_str() );
　　　　openarchive = ( OPENARCHIVE )GetProcAddress( dll, ( api + "OpenArchive" ).c_str() );
　　　　......

（せっかくの統合アーカイバなのですから、スタティックリンクは勿体無いと思います）



更に、Unlha(...)、UnZip(...)、Tar(...)などのコマンドラインｵﾌﾟｼｮﾝの不統一が使いにくいなあと思います
unlha32.dll なら　　 x filename directory
unzip32.dll なら　　 -x filename directory
tar32.dll なら　　　 -x filename -o directory

これまた使いにくい。
こちらは解決が面倒で未だに手をつけていません。help me

それはもう、どーしようもない。カタチは統合になっただけで結局は別モノって感じ。
それなりに便利なんで感謝してますけど。
一応そこら辺の改善を含み、使いやすいアーカイバ関連のライブラリを作る
プロジェクトが興ったみたいだけど、まだモノは出来てない。どうなるのかな

お返事ありがとう
完全に汎用的に使えるラッパクラス/アプリケーションを制作中です

ini ファイルで dll ごとに設定を与えようと考えています。
（　各dll のパス、API接頭語、各コマンドラインオプション、などなど　）

クラス構成はこうなる予定です
　　CDLL　　　　　dll ダイナミック・リンクをラップしたクラス
　　CArchiver　　CommonArchiverLibraryProject のAPIをラップしたクラス
　　　　　　　　　　 Unlha(...)、Tar(...)などの違いを吸収します

CDLLのラッピングは一応完成。
CArchiverはラッピングのみ完成。次はコマンドラインオプション吸収を実装予定。
（その前に、ini ファイル用のクラスを作る予定）

面倒ですね。
Noah に丸投げしたほうが良いかもしれませんね。




> 一応そこら辺の改善を含み、使いやすいアーカイバ関連のライブラリを作る
> プロジェクトが興ったみたいだけど、まだモノは出来てない。どうなるのかな

とても気になります。
メーリングリスト内で興ったのでしょうか？

>>144
これかと
ttp://pc2.2ch.net/test/read.cgi/software/1046607695/

あと、解凍のみならともかく圧縮まで扱うなら、iniに設定を持たせるのは
無謀かと。

・SFX作成（書庫→SFX化と直接SFX化の二通りある)
・暗号化、ソリッド、分割などのオプション機能
・tgz/tbzなど、圧縮時に拡張子が変わる時はどうするか
・ファイルリスト仕様の微妙な違い

など、仕様が異なるところがかなりあるので設定がかなり膨れ上がりそう。

ファイルを圧縮するプログラムを作りたいのですが、まずなにからはじめたらいいのでしょうか

>>146
まずは、ファイルをコピーするプログラムを作る。
このときに、ファイルの入出力などの取り扱いについて学ぶ。

次に、圧縮のアルゴリズムなどについて学ぶ。
それから、上記のコピープログラムに、圧縮と展開を組み込む。

>>146
データ圧縮ハンドブックを買ってくる。
ソースを(コピペじゃなくて自分でキーボード叩いて)全部うつす。
コンパイルして遊ぶ。

SPECintベンチマークにcompressが含まれてて、これはとっても
並列化しにくいんですけれども、gzipなら割と簡単に並列化できるんじゃ
ないかと思いました。

　i)１ブロック読んで、中の部分文字列をハッシュ表に登録
　ii)ブロック内の各位置からの最長一致を求める。
　iii)エントロピー符号化

という順でやれば、各ステップは並列にできるのじゃないでしょうか。
gzipだと、エントロピー符号化もブロックごとの静的ハフマンだし…
ただ、ii)では無駄な位置に対しても投機的に最長一致を探すことになりますが。
並列化できないのは、ビット列の出力ですが、この時間は大きくないでしょうし。

>>149
i) と ii) を分ける理由が分からん。
ハッシュ関数換えるってんなら話は別だが。

>>150
並列化したら、
後に出てきた部分文字列の方を先に処理することもありえますから、
その際に、前に出てきた文字列が未登録だと
うまく圧縮できません（逐次処理と結果が変わります）。

PPMやべー
PPMに惚れそう

その高速性はあたかも弾丸のようだ。

>>152
もう惚れ済みですが何か？
7-zip [ ttp://7-zip.org/ ] とか、
ppmd(1) [ ttp://packages.debian.org/unstable/utils/ppmd.html ] とか。

zip や lha　とかってbitごとに辞書化してるんですか？
それともbyteごとなんでしょうか。
よく見る解説ページでは"aaabcccddddff"とかって
アルファベットだったりと概念的なものばかりでよくわからんのですが…

>>155
一般に圧縮ではバイト（あるいはそれ以上の大きさ)が用いられる。
あと、圧縮の説明にアルファベットがよく使われるのは”見える”からだと思われ。

なるほどー。
じゃあ何を判断にくぎってるんですか？たとえば
125 124 209 300 125 124 200 111
とかって画像データ があったとすると
125 124　が2つ
209　　　　が1つ
300　　　　が1つ
200 が１つ
111　　　　が１つ

ってのと
125 124 20　が2つ
9 300　　　 　が1つ
0 111

(失礼しました。続きを)

125 124 20　が2つ
9 300　　　 　が1つ
0 111　　　　　が1つ
の二通りにできますよね。じっさいのところどうやってるんでしょうか？

>>158
その違いが辞書の違い、すなわち、手法の違い。
LZ'77, LZ'78 くらいでよいから、参考書で勉強すべし。

なるほど。もちっと本読んで勉強します。
ありがとうございました

LZSSのソース（作者が使用してもよいと言ってる物）欲しいんですがどこにありますか？
へたれなのでアルゴリズムﾊﾟｸﾘたいのですが。

>>161
おまいは奥村先生の「最新アルゴリズム事典」を枕にして勉強しる。

>>161
おまいは奥村先生に足を向けて寝ていはいけない。
http://www.matsusaka-u.ac.jp/%7Eokumura/algo/

>>162-163
奥村先生のソースコードは落としましたがあれは本当にLZSSの基本実装みたいな形ですよね？
だもんで速度的にちょっといけてないかなーとへたれ心に思ってみてり。
因みにツリーを使わずハッシュを使うと特許に触れるんでしたっけ？

>>164
LHA, gzip はハッシュを使って実装されている。

つーか、へたれを自称する人は基本をおろそかにしてはいけない。
とりあえず、LHA か gzip のソースを読んでみてわからなかったら、
素直に奥村先生を拝むこと。

>>161
これはどうだ？
http://www.ingnet.or.jp/~kojif/mu/comp/

>>164
へたれだからこそｺﾋﾟﾍﾟなんだよ!
ハッシュ化するのは問題ないんですね。少し勉強して奥村先生コードに手を加えるか…。

>>166
確か最初に落としたけど研究目的以外はx(ﾒｯ)なんすﾖ。

>>164
LZSS系列だとツリー使っても特許の地雷だらけなのよね。
ハッシュ使っても地雷だらけ、ってのは変わらんけど。

>>168
特許の有効期限、いつになったら切れるんだ？

特許発効から20年ほど

MACのsit形式の仕様書はいつになったら公開されるんですか
不便でしようがありませんよ！

どこかに解析資料とかないでしょうか

>>171
こんなのとか。
ttp://www.stuffit.com/win/sdk/index.html

>20年ほど

長いよねぇ

>>172
ありがとう

登録制なのか…やだなぁ

ttp://www.cmagazine.jp/books/assyuku/index.html

この本とかはどうだろ？

>>10
　激しくﾜﾛﾀ（笑）。

>>171
ttp://www.speakeasy.org/~russotto/arseniccomp.html

圧縮といえば、2年くらい前にすげー大ボラ吹いた奴が
海外にいなかったっけ？

>>178
1/100に圧縮できるってヤツか?

あげ

おまえらエントロピーくらいわかってるよな？

圧縮・燃焼について語れ

ロータリーエンジンはすごいって事話す事になったんですか？

ロリータエンジン

LZ系で小さいやつ
(コードサイズが小さくて、
符号化・復号化だけで余計な機能がなく、
復号が速いやつ)
ない？
アプリにこっそり組み込んで使いたいんだが。

>>178-179
ZeoSyncｷﾀｰｗ
懐かしいな。

>>185
奥村LZSSでもつかっとけ

THCompが最強

>>185
MS-COMPRESSを呼び出すのが簡単かつ確実

>>189
WinでもAIXでも使えるのをおながいします。

昔の7行スレのやつ使うことにしました。
ちょっと遅いけどすげー小さいので。
ちなみに190は偽物です。

む、7行であったのか

>>192
7行のだと、Huffman, rangecoder, LZ77系, RLEなら、
それぞれ2つ以上の実装が出ていたはず。
LZ78とかBPEとかもあった。

>>192
これかな？
http://www.isl.cs.gunma-u.ac.jp/~shingo/make/7line/7line.html

違う

数MのXMLを短時間で圧縮解凍したいんですが、圧縮率とパフォーマンスのバランス
の取れた圧縮アルゴリズムってなんでしょう？

XML → 無駄なコード削除 → ブロックソーティング → MFT → ランレングス

　でやってみたんですが、圧縮率は満足なもののブロックソーティングが遅すぎて
使えませんでした。もちろん、高速化は可能だと思うのですが…

>>196
まずbzip2で試してみて、それでも遅ければブロックソートは向いてない、
十分な速度ならブロックソートの高速化が甘いかと。

ブロックソートの高速化についてはこちらなど
M.Hiroi's Home Page　ttp://www.geocities.co.jp/SiliconValley-Oakland/1680/
white page　ttp://homepage3.nifty.com/wpage/

すいません、javaで圧縮・解凍プログラムの作成を試みているのですが、
どこか良いサイトあれば教えてください。
jarでなくてgzipの話です、念のため。

そういったアルゴリズム関連の場合、
いきなりJavaソースを探すのではなく、
C/C++をJavaに翻訳することを薦める。

>199
javaには、圧縮関連のインタフェースが提供されているはずなのですが。。
圧縮クラスだとか圧縮メソッドのような。。

>>198

> 標準的な ZIP ファイル形式および ＧＺＩＰ ファイル形式を読み取ったり、書き出したりするためのクラスを提供します。

http://java.sun.com/j2se/1.4/ja/docs/ja/api/java/util/zip/package-summary.html

そこはおとずれました。サンプルプログラムを教えてください。

見つけた。
ttp://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=5688&forum=12

マルチメディアのファイルフォーマットを作成中なのですが
ストリーミングに向いた、圧縮方法を教えてください。

>>204
うぐっ！
書き損ねた。>>204は携帯電話によく搭載されてるSMAFみたいな
奴を考えてます。

ストリーミングと圧縮はあまり関係ないんじゃないのか？
あえて言うなら、ストリーミングにはデータ欠損が付き物なので
データが足りなくても質を下げて再生できるようなフォーマットが必要だろう。
最初の数パケットで数フレーム分を荒く再生できるとか。

>>206
すると、圧縮しないほうがいいってことでしょうか？

いや、そういう意味ではなくて、ストリーミングに適しているかどうかは
アルゴリズムよりも実装の問題だという事。
圧縮は当然する。
しないと送受信が間に合わないでしょ。

といっても具体的に知っている訳じゃないので一般論でしかないけどね。
とりあえずmpegとか調べてみては如何かな？

>>204
「携帯 ムービー フォーマット」でググればそれらしい形式が出てくるんだから
更にそれらのフォーマットを調べれば済むんじゃないかなぁ。

質問です。
backup[1]という名前のフォルダの中に次のようなファイルが入っているとします。
　regcopy.exe
　help.chm
　online.htm
　readme.txt
別のbackup[2]というフォルダの中にもbackup[1]と全く同じファイルが入っているとします。

このbackup[1]とbackup[2]のフォルダをそれぞれLZH形式に圧縮します。
圧縮したこれら２つのファイルのバイナリを比較したところバイナリが一致しません。
上記４つの各ファイルのバイナリは一致しているのに、なぜ圧縮すると圧縮ファイルのバイナリが一致しなくなるのでしょうか？

宜しくお願いします。m(ﾟдﾟ)m

釣りか?
フォルダごと圧縮してるなら、フォルダの名前が違うから。

>>211
いや、最初はそれが原因かと思ったので、フォルダ名を同じにして圧縮してみたんですが、
やはりバイナリが一致しないんですよ。
どうやら、フォルダ名はバイナリに反映されないようですね。

今度はZIP形式に圧縮し直して試してみたんですが、やはりバイナリが一致しません。
うーん、、何故？なぜなんだろう。。

フォルダのタイムスタンプが違うんだろ。たぶん。
タイムスタンプも統一(偽造)してやってみて。

>>213
レスありがとうございます。
タイムスタンプは一致させているんですが、やはりバイナリが一致しません。
どうやら、ファイルの圧縮順が違ってみたいです。

例えば、backup[1]では、
regcopy.exe→help.chm→online.htm→readme.txt
のような順で圧縮処理しているのに対し、backup[2]では、
help.chm→online.htm→readme.txt→regcopy.exe
のような順で圧縮処理しているようなのです。

つまり、圧縮書庫内に格納されているファイル順が異なるため、バイナリが一致しないようなのです。
そこで、フォルダ内のファイルを名前順で並べかえてから圧縮したのですが、圧縮順は変わらないままです。

何か良い方法はないものでしょうか？
OS：WinME
アーカイバ：Easy圧縮

ファイルの列挙順はファイルシステムに依存するから、
それを制御するのはWindowsでは難しいだろうな。

ところで個人的には「どうしてそうしたいのか」が不明なんだが。

>>215
なるほど、やはりファイルシステム依存でしたか。
アーカイバ側の設定で名前順でソートしたらバイナリ一致確認できました。

＞ところで個人的には「どうしてそうしたいのか」が不明なんだが。
書庫内の格納順が名前順になってないと、解凍後に名前順に並べ替えないといけないんですよ。
これって気になりませんか？

いや別に並び順なんてのは表示の問題であって
内部処理がどうなってようが気にならんがね。
実際FATだかNTFSだかがどんな順番で格納してるかなんか
気にしてないだろ？　もちろんファイラで一覧表示するときは
なんかの基準でソートされてないと見づらいけどね。

アーカイブも同じだと思う。実際にどの順で格納されてようが
別に気にならないな。中に何が入ってるか表示するときに
ソートすればいいだけの話だから。

>>216
勝手に並べ替えされると「あぁ、名前順に格納されてるのか」とか考えるバカが出るような気もするが。

ファイルを圧縮するんじゃなくてメモリ内のデータをファイル名を指定して直接
ＬＺＨ圧縮ファイルに出力したいんだけどやっぱハフマン法とか勉強しなきゃできないん？

>>219
zlibならそういう使い方もできるんだが、LHAでは聞いたことないな。
LHAという縛りがあるなら勉強してクローン作るしかないかもしらん。
LHAじゃなくても良くて単に圧縮したいだけならzlibが使えると思う。

>>220
レスサンクス
ＬＺＨ圧縮しる！っていわれてるんで参考書でも買ってきて勉強しマフ

>>219
unlha32.dll で UnlhaCompressMem とか使えばできなかったっけ？

>>222
情報サンクス
ちょっと試してみますた
メモリ圧縮は可能だけど解凍ソフトで解凍してもファイルが出来ないよ・・orz
やはり自作しるしかないのか・・はぁ・・

出来ないと思ってたのは自分のミスですた・・・
これでデータ長がDWORDの設定範囲を超えるデータを
１ファイルにまとめることが可能なら・・・これで十分いけそうでつ
>>220さん
>>222さん
ありがたう！

自動解凍のプログラムを作るのに参考になるページはありませんか？
解凍後にいろいろ処理をしたいのですが、既存のをそのまま使うのは
無理そうなんです。
解凍後に指定のEXEファイルを実行、というのでは解凍中のエラー時の
処理などがカスタマイズできないので使えないんです。

>>225
makeとかantとかを強制させるとか

>>225
installshield(?)を参考にしる

>>225
プログラムの参考にはならないだろうが、
DGCAが、自動解凍後に任意のプログラムを実行する機能を持っている。

>>228
そんなんlhaだって持ってるぞ。
っつーか普通は持ってるんじゃないか？

>>229
% lha --version
lha for unix version 1.14g
% lha
...
LHa for UNIX V 1.14i Modified 2000 Tsugio Okamoto

ごめん。よくわかんない。
DOS版にはそういう機能があるの???

>>230
そもそもunix版では自己解凍書庫つくれんだろーが。

>>230-231
sharの仕組みを導入して何でも自己解凍化してしまえばok

　

既存圧縮アルゴリズムを上回る圧縮率を開発できれば食いっパくれないんだろうなぁ

たかだか 1%程度改善できても誰もよろこばんと思われ。

開発しただけではどうだかな。その後のマーケティング次第でなんとでも。
それに圧縮率だけなら既存のでもシャノン限界に肉薄しているのがあるし、
圧縮速度やメモリ効率や使い勝手も優れてないとこれから普及するのは難しい。

いま，バッファにあるデータを
圧縮したり，展開したりする必要があるんだが，
統合アーカイバプロジェクトにあるような
圧縮展開ライブラリは「ことごとく」，
ファイルから入れて，ファイルに出すような，
API しか用意していない．

バッファで使えるようなライブラリ知らない？

>>238
少なくとも unlha32.dll と unzip32.dll はメモリから圧縮、解凍できるが。
っつか、>>222 で既出。

>>239

lnlha32.dll では圧縮したデータを直接バッファに
出すことはできない

unzip32.dll では圧縮そのものができない

だとすると素直にzlib使う感じかなぁ。

すいません。馬鹿な質問かも知れませんが圧縮ってどうやってやるんですか?
例えばバイナリは1バイトで必ず0〜255の値しか取らないじゃないですか。
それを圧縮したら戻らなくなっちゃう気がするんですけど…

>>242
まずはこの辺読めば？
ttp://homepage1.nifty.com/snap/room03/c02/comp/comp.html

>>240
それなら、バッファにあるデータをバッファに圧縮、展開と書かないと分からないよ。

展開はともかく、圧縮データをバッファに吐くのは
圧縮できなくてデータが増える事も考慮すると、ちと面倒くさいね。

要するに可逆圧縮は連続データがなければ圧縮というよりファイルサイズが増えるってことですかね…
なんとなくわかりました。ありがとうございます。

>>245
ほとんどわかってないぞお前。

>>243
そこはLZ78符号 ≒ LZ77符号 ＞＞ 算術符号 ＞ ハフマン符号 ＞＞ 連長符号
みたいな比較をしていて解説としてはちょっとおかしいぞ。
LZ符号と算術・ハフマン符号を比較するのは無理がある。

>>244
> 展開はともかく、圧縮データをバッファに吐くのは
> 圧縮できなくてデータが増える事も考慮すると、ちと面倒くさいね

ん？ 意味わからん
ちぢまない最悪のケースを考慮して，
バッファを用意させればいいだけの話じゃないか

>>248
最悪のケースを調べるのが面倒くさいって事。

deflate でやるなら deflate のフォーマットを調べないと最悪のケースはわからん。
適当にやると不具合が出たときに泣きを見ることになる。

GCAってのはどれだけ優秀なの？
解凍速度優先型らしいけど、ホントにゲームに使ってる方いらっしゃる？

たとえばランレングス法とかのように("aaabbc" => "a3b2")
日本語を含む文字列(char型の配列)を圧縮して、
出力がバイナリでない圧縮方法はないですか？
ランレングス法は通常のテキストだとあんまり意味がないもんで。

>>251
そんな特異な圧縮方法はありそうにない。
ってか、ほとんど仕様が決まってるじゃん。自前で用意しる！

>>251
君は>>242だな？

>出力がバイナリでない
意味が良く分からん。
もう少し圧縮について勉強しなさいな。

失礼いたします。
LHAやzlibでの、LZ系の高速化手法について詳しく述べられている
サイトってございませんでしょうか？

>>254
サイトは知らないが、論文はいくつかある。

>>254
ランペル・ジブ系一般に対する高速化の手法ではなくて、
LHAやzlibが採用してる手法について知りたいってこと？

後者なら、LHAについては1970〜80年台の古い雑誌に解説記事が載ってたな。
zlibはソース見るのが早いかも。いずれにしても、奥村先生のとこの記述がとっかかりになるはず。
ttp://oku.edu.mie-u.ac.jp/~okumura/map.html

前者だと、論文とか特許文書あたりの範疇になるのかな。これはさすがによくわかんね。

教えて頂いてどうもありがとうございます。

>>256
後者の方です。

gzip.dll用のCのヘッダーファイルが存在するのかどうか、
どなたかご存知でしたら教えてください。
当方VC6.0で圧縮モジュールを作成したいと考えています。

　

>>258
http://www.gzip.org/

人生に密着した、圧縮と解凍。
ttp://www.newforeskin.biz/CI/CIchart.htm

LZとかその他の理論を基本的な手法を解説した本ってあまりないよね
なので、見つけたら即買ってしまう・・・

「ＬＨＡとＺＩＰ」つー、マンマの本はどうなのかな。
オレは読んだこと無いけど(苦笑)。
Cが読めるなら、理解できるんじゃないかな。
オレはCを読めないので本当のトコは知らないけど(苦笑)。

アルゴリズムだけなら、上の本の作者の若い片割れの
ウェブサイトに、基本的にトコがカンタンに載ってるよ。
オレはそこ読んでLZSS+ハフマンのアーカイバを作った。

>>262
理論を解説した文書が欲しければ論文を読むか、情報理論の教科書を探せ
手法を解説した文書ともども、amazonで買える

そもそもの大問題として、LZそのものの理論解析が実はあまり進んでいないという
確率推定問題に置き換えての証明やらは腐るほどあるが、派生手法に適用が困難

gzipの解凍と圧縮の仕方を知りたい。

>>265
ソースプログラムを読もう
アルゴリズムを知りたければRFCを読めばおｋ

LZMAをマイナーOS環境にポーティングしようと思ったら、LZMA SDKの
コードそのままでメークできてしまった。色々いじって楽しもうと思ったのになあ・・・。

zip32.dllをダウンロードする場所を教えてください

>>268
googleで検索することをオススメします

いいから直アド教えれこのくずが

　　_, ._
（　ﾟ Дﾟ）

ごめん・・・
もうゲットしちゃった(*´д`*)

(ﾟдﾟ)

>>270
氏ね

lzw圧縮ってもう使ってもいいんだよね？
あとでまた特許云々…とかなったりしないよね？

> lzw圧縮ってもう使ってもいいんだよね？
Unisysが持ってた特許は失効した。

> あとでまた特許云々…とかなったりしないよね？
可能性はある。
実際に Unisys が関連特許で gif からライセンス料を徴収を続けるかも、って記事もあったし。

>実際に Unisys が関連特許で gif からライセンス料を徴収を続けるかも、って記事もあったし。
マジですか('A`)
携帯アプリのデータ圧縮に使おうと思ってたんだけど、やめといたほうがいいのかな…。

>>277
>>276 は脅しただけだと思うが。
まぁ、油断はしない方がいいやね。

lzwってsuffix treeが必要になるから携帯でやるとメモリきつくない？

各ノードの前後のインデックスを保持するだけだからそんなにメモリ使わないと思う。

前後のインデックスってわかんないや。
親ノードのインデックスだったらわかるけど。
最近勉強してなかったからなぁ。

ああ、親子のインデックスって言った方がよかったか。
lzwなら、親ノードのインデックスと１字のデータ(ある意味、子ノードのインデックス)ってことだよ。

>>277
>>276 が言ってるのと同じかはしらんけど、こんなん見つけた。

http://pcweb.mycom.co.jp/news/2004/06/21/001.html
> 現在、米UnisysはLZWの技術に関連する2件の特許を出願中であり、
> 近い将来において特許成立が見込まれると発表している。
> 画像フォーマットとの関係は不明だが、その内容次第では
> 今回解決に至ったGIF問題の再発も懸念される。

まあ特許切れてる間に発表すれば後で公開停止求められることはないと思うけど、
作ってる間に関連特許取られたら怖いなー。後々使いまわす予定のコードだし。
短いコードで圧縮率高いから使いたかったんだけど…lzw以外でそういう圧縮方法ってないよね？

lzss もハッシュテーブルと連結リストだけでできるっしょ。
こっちも特許ヤバそうだけど。

ごめん、今更だが子のインデックスって言い方はまずかった。
要は、辞書X番の情報は「辞書Ｙ番の子である」と「その後ろにつく１文字」ということなんで、
ノードの持つデータと親のインデックスだけでいいんだな。

cabinet SDK(cabinet.dll)のAPIが日本語で説明されてるサイトってありませんか？

大阪（西梅田）、新宿（JR駅前）のそれぞれ一等地に
拠点を構え、業績急上昇中！未経験者大募集中！の
ソフトウェア開発会社
グリーンシステムを応援するＨＰです。
http://www.geocities.jp/grs_hp/

応援するスレはこちら！
http://school4.2ch.net/test/read.cgi/job/1077432387/

最高の会社にするため、みんな頑張ってます！

高速ブラウザ「Opera」、SlipStreamの圧縮技術でさらに加速
http://pcweb.mycom.co.jp/news/2004/11/06/100.html

の記事で、
「SlipStreamが開発したWebやEメールのアクセラレーション技術である。同社独自のデータ圧縮アルゴリズム」
とあるけど、
またまた、何かのパクリなのか？　

こういう紛いもんみたいな新技術の話って、よくもまあホイホイ出てくるよなぁ。

教えてください。私目のバカ脳では、限界です。
JavaのZGIPOutputStreamクラスでgzip形式で圧縮が可能なのですが、

同じファイルでも、プログラムで圧縮プログラムを実行するたびに、
出力された圧縮ファイルが異なります。サイズも中身もです。
解凍すれば、同じデータであるので、別に良いのですが、
会社で資産管理作業を行う際に面倒です。
そもそも、gzipや他の名のある圧縮アルゴリズムの
仕様なのでしょうか？

>>289
適当な圧縮ソフトで実験してみれば？

拡張子ｆｃｄってどうやって復元するの?
サイズ400メガ

>>291
とりあえず吊っとく？

ＦＣＤ・・わからん
吊っとく・・わからん

割れだろ？放置推奨

圧縮ソフトを作りたくて圧縮技術に関する本をamazonで検索しています。

http://www.amazon.co.jp/exec/obidos/ASIN/4797325526/ref=pd_bxgy_img_2/249-1522108-5041925
圧縮アルゴリズム―符号化の原理とC言語による実装 C magazine
↑は購入を決めたのですが、他にお勧めの本はありますか？

できればプログラムのソースの解説については少なくて
アルゴリズムの解説に重みを置いている本を読みたいのです。

上記の本は知人から見せてもらって
自分のそばに置こうと考えたので購入することにしました。

ttp://www.amazon.co.jp/exec/obidos/ASIN/4798005606/ref=pd_sim_dp_2/249-1522108-5041925
図解入門 よくわかる最新データ圧縮技術の基本と仕組み
―情報圧縮技術とアルゴリズムの基礎講座
How‐nual Visual Guide Book

こちらも候補に入れております。

保守

あとはこれ。
「LHAとZIP―圧縮アルゴリズム×プログラミング入門」
http://www.amazon.co.jp/exec/obidos/ASIN/4797324287/

>>298
その本は 1/3 が LHA の作者の一人の奥村氏による昔話とアルゴリズム解説、
2/3 が DeepFreezer作者による LHA の独自実装のソースと解説。
ついでに ZIP も実装できちゃいましたって感じの本だよ。
アルゴリズムの解説が読みたいっていう >>295 にオススメできるような本じゃない。

仕様を網羅してるか、という点で見ても LHA も ZIP も中途半端だし。

そうだねぇ。私も買ったけど、仕様がどうこうって本ではないですね。
圧縮アルゴリズムのさわりと、プログラミングの入門って感じの本でした。
ていうか、サブタイトルがそのまんまなんで、タイトル通りの本ってことだけど。

図解入門 よくわかる最新データ圧縮技術の基本と仕組み
―情報圧縮技術とアルゴリズムの基礎講座
How‐nual Visual Guide Book

圧縮アルゴリズム―符号化の原理とC言語による実装 C magazine

上二つの本を購入することにしました。
みなさんありがとうございました。

>>296 >>301
よくわかる〜　はさわりしか書いてないので、物足りなくなったら原論文を当たるとよいでしょう
ただ、オリジナルの論文では正確なところがわからないこともあるので、
解説的な論文を読むのもいいでしょう

突っ込みたい。「さわり」を突っ込みたいー。

昔買った、文書データ圧縮アルゴリズム入門 というのは様々な圧縮方法が書いてあって
よかったけど、今は絶版らしい。

>>304
ttp://www.cqpub.co.jp/hanbai/books/36/36721.htm
漏れが圧縮にハマるきっかけになった名著。絶版でなければ、>>301で不足してる分はこれが補ってくれると思うんだが…
復刊.comでリクエストするか、それとも改訂版をリクエストするか？

改訂版のほうが良いんじゃないかな

掲示板を作りました
http://scs.dip.jp
情報通信に関する学術的および技術的な議論の場を
提供することを目的としています。
勉強するためのテキストの紹介、技術的な質問、
産業界の動向、議論などご自由にお使いください。

ランタイムライブラリ含まない大きさが2kバイトぐらいの
小さくて展開の速い圧縮ありませんか？
圧縮する対象は主にexeとかの実行イメージです。

今はひそかにスライド辞書(LZ77)を使ってますが
アルゴリズム同じだと特許に触れるんでしょうか。
せっかく苦労して作ったのにやだなあ。

>>308
子供は早く寝ろ

LZ77なら全く問題なし

>>310
富士通はLZ77+ハッシュ使うとダメって言ってるし、
LHA作者の奥村教授はLZ77+ツリー使うとダメって言ってるが。

LZ77+何か：×の可能性が高い
LZ77のみ　：
って事

文字化けしてたらｽﾏｿ
は○

LZ77 + 普通のハフマンは×ですか？(LHAではないです)
ハフマンって圧縮以上に見た目のランダム性上がるから
使いでがあるんですが。

というかLZ77のみは可ですか。
とりあえずLZ77だけでいきます。


こういう思いつきそうな事を特許で縛るのって卑怯ですよね。
そういえば、バイオハザードの視点固定は特許になったのかな。
あれも酷いですよね。

>>314
> というかLZ77のみは可ですか。
LZ77のみっつーか LZ77 + 単純検索だけでhashもツリーも使ってないなら、たぶん可。
LZ77 + 自分でゼロから考えた高速化をしてる場合は特許の調査をしてみんとわからん。

hashとかツリーとか言われて理解できないようなら、たぶん不可。
一般にwebや本に書かれてるLZ77のプログラムは、全てhashかツリーを使ってるから。

>>314
誰でも思いつきそうで、特定の誰かが思いつくものは多々ありますが、結局早い者勝ちです。
それに、もう20年近く前に「開発され尽くした」といわれた手法に、
いまさらどうこう言ってもしょうがないかと。
LZW同様、ぞくぞく特許が切れつつあるので、ちゃんと調べるなら、使うことができますよ。

あと、LZ77の大多数の特許は、圧縮時の手法（ハッシュも木も）なので、
LZ77オリジナルと同じ圧縮後データをもち、展開するだけなら、特許は全く関係ないわけです。

> ちゃんと調べるなら、使うことができますよ。
ちゃんと調べるならって、>>314 には使えないって遠まわしに言ってるだけのような。

>>317
特許専門の弁護士やら技術者やらを用意しても回避困難
一般人ならなおさら

・ソース非公開
・リバースエンジニアリング、解析を禁止
しておけば大丈夫。
特許の有効期限分経過してからソースは公開すればいい。
後で特許とられても、先に実装が存在する場合は特許が成立しないので、
この場合も安全となる。

> 特許の有効期限分経過してからソースは公開すればいい。
特許が無効になるまでの期間分の特許料払わなきゃいかんと思うが。

> 後で特許とられても、先に実装が存在する場合は特許が成立しないので、
実装が存在しただけで公知と言えるのかは疑問。

>>320
>> 特許の有効期限分経過してからソースは公開すればいい。
>特許が無効になるまでの期間分の特許料払わなきゃいかんと思うが。

特許の存在を知らなかったといえば回避できる。

>実装が存在しただけで公知と言えるのかは疑問。

公知でなくとも存在を証明できれば問題ない。
そのためにはネット上で配布などをあらかじめ利用する。

> 特許の存在を知らなかったといえば回避できる。
著作権じゃないんだから……
それが通るなら特許なんて法制度はあっというまに崩壊するな。

> 公知でなくとも存在を証明できれば問題ない。
改竄が比較的容易なネットでの配布が法的にどーゆー位置づけになるか、って問題と
実装だけで存在を証明できるかって問題が……

>>319 >>321
特許は、
知らなかったでは回避できないし、
その期間分を遡って賠償も請求されるし、
(著作権と異なり)偶然一致した場合でも侵害したことになる。

ネット上での公開は、現在は灰色。
ソースコードを登録機関に提出しておくべし。


・・・はず、有識者もとむ(特許出しているくせに、未熟ですまぬ)・・・

じゃあ組み込むのは展開部分のみなんで関係ないですね

>>323
回避できる。例えばGIF関連では、期限が切れた今現在、過去に上って請求されることは無い。
ポイントは、経過したことと、相手に請求されていないこと。
期限が切れてしまえば、知らなかったで済む。大抵は時効だ。

ソースコードの提出は、逆に自分を危険に晒す。
自分が権利を主張しないなら、バイナリが存在すれば、それで十分。
バイナリ自体が、アセンブリ言語のソースになる。

>>322
お前は馬鹿か。特許制度が、どういう理念で作られたかわかっていないな。
著作権などの法制度とは全く異なる。もともと技術が隠されるのを防ぐためだ。

>>325
無根拠で知らなかったで済むとか言われても……

それに Unisys が現実に特許料を請求するかは別にして、
今現在でも Unisys は2004年6月（だっけ？）までの特許料を請求する権利を持ち続けてるだろ。

あとバイナリ自体がアセンブリ言語のソースって考え方なら
バイナリもソースコードと同程度に危険なはずだが。

>>324
奥村教授を信じるなら、LZ77の展開部分だけなら大丈夫だと思われ？
ハフマンの展開部分も大丈夫か、ハフマンの展開部分とLZ77の展開部分くっつけて大丈夫かは知らんが。

>>326
特許の目的は人類の知的財産の共有が目的だよ
みんなで一歩一歩進みましょう。
って感じの。

特許対象となるようなすばらしいアイデアはみんなのものです。
でも、発明人にもなにかおいしいことがないといけないので
20年間は発明を特許で保護されるわけです。

あんまり恥ずかしいこといわないでね。

no patent!!
no patent!!

ん？LZWはもう使って大丈夫なんですか？

解禁です。
あの子のへあーも

>>331
>>275-276,>>281

× >>281
○ >>282

rarて何使ってるの？
最近の圧縮アルゴリズムはさっぱりわからん

自己解凍書庫ってのは『解凍Exe』＋『圧縮データ』って形になってると思うんですが
『解凍Exe』はどのようにして『圧縮データ』の位置を取得してるんでしょう？

自分のサイズがわかってればいいんじゃない？

ここに詳しい人がいる
http://pc5.2ch.net/test/read.cgi/tech/1039513920/

>>335
とりあえず

　r　a　r　は　最　近　で　き　た　圧　縮　形　式　で　は　な　い　ｗ

>自分のサイズがわかってればいいんじゃない？
ふむ．．．
『解凍Exe』内部にハードコードで書込んでおく。ってのも有りか．．．しかしなんかイヤな感じが

統合アーカイバとかの自己解凍書庫てどーゆー作りになってんだろ？

>>340
良くわからんけどID3みたいにファイル末尾に前のブロックの末尾位置だの
最終ブロックないのデータの先頭位置だののテーブル持ってるんじゃない？

>>341
おいおい憶測で物言うのもいい加減にしろよ。
ストリームでもなければ末尾にヘッダを置く意味がない。
自己解凍書庫の作成はあらかじめ用意した解凍ロジック付きexeの
PEヘッダに適当なデータセクションを追加修正すれば終わり。
解凍ロジックはデータセクションで定めた決めうちベースアドレスから
データを読み取るだけでOK。
PEの仕組みとローダの知識が多少あればできる。

ソースコードが移植可能なライセンス携帯で、3kbぐらいのオブジェクトサイズの
圧縮ライブラリ知りませんか？ちょっとSymbianに乗せるアプリに実装したい
と考えています。

>>343
Huffman自作しなされ。以上

344の意訳

知りません。でも知らないって言うの恥ずかしいから煽ります。

MPGかWAVからAFSファイルを作りたいんだけど、ツールないですか？

>>346
板違い

ソフトウェア
http://pc5.2ch.net/software/

Lhaplusの作者のWebページどこへいっちゃたんだろ？
Lhaplusってあれだね、ファイル数が多いといつまで待っても
圧縮が始まらんねｗ

> Lhaplusの作者のWebページどこへいっちゃたんだろ？
ttp://park14.wakwak.com/~schezo/

>>349
サンクス。
lhaplusをver1.50β11にしたらサクッとスタートしてくれました。

LZ77の圧縮にハッシュも木も使ったらまずいってどうすりゃいいんだ？
LZ77を少し改造してLZ77じゃありませんよ〜とかいったらOKなんだろうか。

>>351
2-3文字をインデクスするリストを使えばいい
木とほぼ同程度の速度で動く

・・・ぶっちゃけ、2-3文字のハッシュと同じなんだがなｗ

なんか圧縮のことよくわからなくてはじめてここに来たんだけど、
とりあえず３バイト連続する同じデータがあれば２バイトに圧縮したらＯＫなんですね。
あと連続するパターン見つけるんだろうけど、俺がプログラム書いたらそんなの
時間かかってぐっちゃぐちゃでめっちゃめちゃでアウトだ

>>353
専門書も扱っている本屋へ行って、圧縮とかアルゴリズムとか、の本を買うと良い。

パターン検索は >>351-352 のキーワードを参考に。

>>352
それだとハッシュ使う特許に引っかかる可能性が残ると思われ。

圧縮率上げる工夫よりも特許を回避する方に労力を費やしてる矛盾

>>353
unsigned char c = in[i];
int count = 0;
while (c == in[++i]) count++;
out[j++] = c;
out[j++] = count;

こんな感じのルーチンで出来る。

>>355
ハッシュとは別の論文で発表されていたから、大丈夫だとは思うがどうだろう。
Bell and Kurp, 1991. だったかな？

>>358
ハッシュの特許に触れるか、だけが問題で
ハッシュと同じ論文で発表されたかは問題にはならないと思われ。

ちなみに、その論文の方法が特許化されてないのは確認済み？

とりあえず何も考えずに zlib 使っとくのが一番現実的なのかね。
仮に問題があったとしても、みんな闘ってくれるはず。きっと。多分。

>>360
zlibに採用されているハッシュ法って、まんま>>352 >>358 だよね
3文字でインデックスしたチェインリストを順に読むわけだから…

installshield の　cab 形式への圧縮が出来るツールってないですか？
既存のcabを展開して、パッチを当てて、また再圧縮したいんですけど・・

>>340
UpdateResource()を使うのもありかもね。

>>361
zlibとかのは先頭3文字を加工して使ってるからなぁ。
ハッシュでないというのは通らんと思うぞ。

加工せず使うなら、なんとかなるかもしれんが
3文字だとテーブルだけで16M*sizeof(テーブルの要素)バイトかかる。

デコードするだけなら引っかからないんでしょ？
普通のアプリなら解凍できれば十分だし

100個くらいあるファイルを、それぞれ違うパスワード(予めエクセル等でファイル名とパスワードの対応は作成しておきます)でzip圧縮したいのですが、やり方がわかりません。
エクセルのVBAで、UNZIP32.DLLを使えば良い、というのは想像出来るのですが、記述方法がわかりません。

お知恵をお貸しください。よろしくお願いいたします。

普通にコマンドライン呼び出せばいいんちゃう・・・？

解決しました！！

どうやって解決したのか書けよ

誰か366を語って書き込みしたようです。まだ解決してません。
よろしくお願いいたします。

zipファイルにパスワード付けるのは安全ですか？

>>371
はい

>>371
危険です
なぜなら371はパスワード掛けてみたはいいもののそのパスワードを忘れてしまうでしょう

>>371
zipパスワード検出プログラムが出回ってるから気休めにしかならない
本気で保護を考えてるなら止めといた方がいい

そういうときのために、ファイル名をパスワードにしておくとよいよね。

zipそのものを暗号化してしまえ

zlibでzip圧縮されたデータ(ファイルにはなってない)を受け取って
解凍しようとしてるんですが、失敗するときがあります。
で、データが正しいかバイナリデータを出力してみてみたのですが
先頭からみると↓こんな感じになってます。
---------------------
78 9C EC 5A CB 6F 1C C9 79 AF 67 77 F5 6B 1E 1C
52 5A 91 94 28 52 94 B4 14 F7 41 AD 76 B5 F1 CA
2B 6E E0 83 45 1D 12 84 30 10 60 15 C0 87 24 F0
D9 B0 BD 57 55 F7 F4 3C 49 59 4B 2A 36 10 CA 46
80 2C 95 E4 60 3A 08 90 E5 DE BC 02 F2 4F 24 B9
E4 E0 3D AE 03 04 F0 4A 39 65 F2 7D 55 DD 3D ・・・
---------------------
http://www.futomi.com/lecture/japanese/rfc1950.html
http://www.futomi.com/lecture/japanese/rfc1951.html
をみるとzipの先頭データは8かFかってことっぽいので
このデータはzip圧縮されたデータとしてはおかしいと
思っていいのでしょうか？

>377
>をみるとzipの先頭データは8かFかってことっぽいので
どうしてそういう結論になる。
先頭バイトが 0x78 なんだから、CM=8, CINFO=7 でウィンドウサイズ 32k の deflate じゃないの？
あと、zlib も zip も deflate を使っているかもしれないが、zip圧縮という言い方は語弊が
あるのではないだろうか。

>>378
二桁目がCMなんですね
ドキュメントをよく理解できてませんでした。

>zip圧縮という言い方は語弊が
このへんはよくわかってないです。紛らわしくて申し訳ないです

>379
バイトの並びとビットの並びに注意しよう。
リンク先の zlib の資料でも「2.1. 全般的な規約」に書いてあるよね？

>>zip圧縮という言い方は語弊が
>このへんはよくわかってないです。紛らわしくて申し訳ないです
俺もよく分からんが、
・zlib はライブラリおよびフォーマットの名前
・zip はフォーマットの名前
・deflate は圧縮アルゴリズムおよびそのフォーマットの名前
ってことでいいの？教えてエロい人！

deflate　圧縮アルゴリズム
zlib　圧縮ファイルフォーマット
zip　圧縮形式の名称及び拡張子

こんな感じか？

zlibは圧縮ライブラリの名前でいいと思うけど

deflate アルゴリズム
zlib バイトストリームを圧縮するライブラリ。ファイルの概念は無い。
zip 複数のファイルを圧縮したアーカイブファイルのフォーマット。

じゃないの？

>>383
それが正解

>>383
意味なんて人それぞれ。
zipを圧縮フォーマット（たぶんdeflate）の意味で使う奴もいる。

俺は deflate はフォーマットだと思うけど、アルゴリズムだと言う奴もいるしね。
deflate がアルゴリズムなら、zlib の deflate と 7zip の deflate は
同じアルゴリズムを使用してる事になるけど、俺は別のアルゴリズムだと思ってるから。

↑こういう意識のやつはこの業界に必要ない

↑オレ用語が否定されてムキになってる人？

deflateはRFCで記述された通りでいいんじゃないか?

どっちでもいい。

今、圧縮解凍ツール作ってるんですけど、
unlha32で、既にある書庫にファイルを新規に圧縮して追加したいんですけど
コマンドがわかりません。どなたか教えていただけないでしょうか？

・既存の書庫ファイル(c:\work\abcd.lzh)
a/aaaa.txt
a/b/bbbb.txt
a/b/c/cccc.txt

a/b/c/d/dddd.txt　を追加したい

・圧縮前のファイル
c:\temp\dddd.txt

a

>>391
追加圧縮はできるんですけど、書庫内のディレクトリ指定がうまくいかなくて困っています。（；_；）

Unixで暗号化ZIPファイルをプロンプトを出さずにCプログラムから作成する方法を教えてください 

キーをテキストに書き出す
テキストを読む
以下略

30 30 30 30 30 30 30 30 30 30 を圧縮すると（16進表記）
30 30 30 30 30 30 30 30 30 30 のままで

30（ASCIIで'0'）を20個つなげたやつを圧縮すると
05 30 EE FF 30　となった圧縮形式があったんだが、これなんだっけ？

ヘッダとかついてないのかね。

あげ

UNZIP32.DLLやUnGCA32.dllでパスワードがかけられてるファイルかどうか見る方法をおしえて

書庫のヘッダに書いてあるよ

パスワード付きZIPをパスワードWindowを開かずに作成する方法を教えてください

コマンドラインで入れる

もう少し詳しく教えてください

ソフトウェア板かwindows板の話題だと思うんだそれは。

実装でもアルゴリズム概念を聞いている訳でもなし。

>>402
ま、巷じゃ「圧縮がわかる本」とかいって圧縮ツールの使い方だけ教えてるのが何百冊も出てるしな…

漏れもいっちょ書いてみるか！

>>399 無理

統合アーカイバのDLLを使ってプログラミングをしているのですが、静的インポートの場合、付属のインポートライブラリを使用しますよね？
これってVC++(MS-LINK)用COFFのようですが、BCC++(ILINK32)でうまく使えないみたいなんですが・・・？(UNZIP32.DLL)
BC++付属のCOFF2OMFで変換するも、デフォルトでは利用できず、-lib:stスイッチで変換しました。
しかし名前インポートができず、オーディナルになってしまいます。
BCC++で名前インポートするにはどうしたらよいでしょうか？

って、しまった！全然間違えた！

MASM + MS-LINKでそのままリンクすると序数インポートになってしまうんだった。

<<X.ASM>>
        .386
        .model  flat,stdcall
        .code
start:
        call    UnZipGetVersion
        ret
        end     start

<<ビルド法>>
ml /c /coff x.asm
link /subsytem:console x unzip32.lib

私はVC++を持ってないのではっきりとはわかりませんが、リンカが同じなのでVC++でも名前インポートにはならないですよね・・・？
名前インポートにするにはどうしたら・・・？

>407
各処理系のスレで聞いた方がいいと思う。

implib

名前でのインポートにこだわる訳は？

>>409
IMPLIBなら確かに付属のインポートライブラリはいらないですが・・・MS-LINKはOBJ型ライブラリが使えないようなんですが・・・？

>>410
オーディナルのインポートって信用できないんですよね・・・
DLLのバージョンが上がると変わらない保証ってないじゃないですか・・・？

>>411
BCCで使うのになんでMS-LINKが出てくるんだ? わけ分からん
MS-LINKなら付属のLIB使えば済む話だろ

>>412
ですから間違えました。BCCじゃなくてMASMです。

ヒント: /coffオプション

完全に特許に引っかからない技術を教えてクレイ

>>415
特許の期限が切れたもの

>>415
bzip2,gzip

完全と言い切れるものは多分ないんじゃないかな。
知られてないだけで、所謂サブマリン特許の類のパテントが存在するかも知れないし。
bzip2のBWTも発案者が特許を取らないといっているだけだし。

圧縮ソフト作るのって床から刃の出ている廊下を歩くような感じだよ。
時々踏むと刃のでる罠が仕掛けてあったりして。
最初にアルゴリズムに特許を与えたバカは誰なんだろう。

>418
アルゴリズム特許は暗号が初めてじゃないっけ
それならこれもそれならこれもとずるずる範囲が広がっていった。

暗号の場合は納得できるんだけどねー

フラクタル圧縮もダメなんでしたっけ

>418 >419
線形計画法のカーマーカー法じゃないの？
>カーマーカー特許とソフトウェア―数学は特許になるか 中公新書
>ttp://www.amazon.co.jp/exec/obidos/ASIN/412101278X/249-7663900-1232317
元々の圧縮アルゴリズムはともかく、○○＋ハッシュとかいうのになってくるとどんどん納得できなく
なっていくんだが。

>421
すまんこった、カーマーカー法が最初の特許アルゴリズムだった。
ほら吹いてしまいました。ごめんさない。

Info-ZIP社のZIP32.DLLって商用で使用するにはライセンスがいるのでしょうか？
UNZIP32はいるみたいなのですが。HP読んでもわからない･･･

zip32.dllは知らんが、zlibならいらないはず。

>>414
どの/coffですか?
mlなら/coffつけてますが?>>407

hosyu

質問です。
DEFLATE圧縮では元データはバイトごとに圧縮されるのですか？
それとも6ビットや5ビットなどビット単位ですか？
RFCと一緒にzlibやgzipのソースを読んでいるのですが
自分の読解力ではわかりません。

バイト単位

>>428
バイト単位ですか。ありがとうございます。
その線で読んでみます。

ソース読んで理解できないなら>>298

>>430
やっぱりその本を買った方がよさそうですね。
今から買ってきます。

書庫が１バイト足りずに破損している場合、末尾に00を付加するという話を聞いたんですがどうやって付加するんでしょうか？
調べようと思ったんですが検索ワードが思いつかない…

>432
君が何を聞きたいかが理解できない。
とりあえず付加するのは誰？
特定のソフトの話か、特定のファイル形式の話？

>>433
漏れの予想では、ファイルの末尾に00を付加させるのに、
どんな関数orAPIをコールすれば良いか判らない

そういうレベルの質問だと思う

板違いの予感。まさかnarがどうとかって話じゃないだろうな。

1 バイトのファイルを作っておいて copy /b とか cat とか、
そんなスキルもないならバイナリエディタ。

ってところだったりして。

narってなにさ？

もしかして null ?

ナルほど

>>438
誰がうま(ry

>>432, >>435
出てきて釈明しる！

済まん、あっさりスルーされると思ってた。
「伺か」が使うアーカイブ(実態はzip)の拡張子。
公開終了したアーカイブをWebArchiveから拾ってくるって話。
まあ、オタネタだ。

補足。
WevArchiveにはファイル末尾の0を切り捨ててしまうというバグ(?)がある。
そのためせっかく昔のアーカイブを見つけてもzipが解凍できないことがある。
末尾に0を付加してやると正常に解凍できるようになる。
というのがこちらで想定した問題のバックグラウンド。

自己解決したから書き込まなかったんだけど、WebArchiveのzipファイルで〜て事が聞きたかった。
narは良く分からなかったけど、435が書いてくれたからまぁ良いかと思ってた
オレのせいで微妙な話が続いて悪かったです

zlibの使い方を詳しく丁寧に説明してる日本語サイトを教えてください。
あと、gzip（と可能ならzipも）の中のファイル名を解凍せずに知りたいんですが、できませんか？

zlib.hの英語を読むのが一番確実だと思うけど。
別に読みにくくは無いし、そんなに長くもないし。
gzio.cも。

>>443
ヘッダにテキストで書いてあるけど。

>>445
日本語って言ってるだろうが、馬鹿

日本語なかったっけ？　どっかでzlib.hのコメント日本語訳みたことがあるんだけどどこだったか…

>>446
日本語読めないのに日本語要求してたんですね。
# 単に駄々をこねてみたかっただけかな? :-P

ありがとうございました。
日本語訳はこれですね。
ttp://www.sra.co.jp/people/m-kasahr/zlib/zlib-1.1.4-ja.h

zlib の deflate　を利用して
自前でzipファイルを作るプログラムを作ろうと思います。
とりあえず、ここの仕様書を見たのですが、
http://www.pkware.com/business_and_developers/developer/popups/appnote.txt

extra fieldの意味がよくわからないです。
私の場合は、この部分は出力しなくて良いのでしょうか？

あげます

遠慮なく頂きます

前スレ

圧縮アルゴリズム考えたんですが
http://pc8.2ch.net/test/read.cgi/tech/1041803200/


テンプレは >>1-3 あたりには無い。

乗っ取るの？

圧縮アルゴリズム2
http://pc8.2ch.net/test/read.cgi/tech/1140946646/

圧縮アルゴリズム考えたんですが

まずデータの中にフラグの立ったビットがいくつか数えます。
そしてデータは0と1を並べ変えたものと考えます。
あとはそれを使って先頭ビットから1なら
(そこから先のビット数)Ｃ(そこから先の立ちビット数)
を計算して足していきます。
つまり圧縮するデータを0と1の並べ替えとしたときに、
それらを辞書順に並べて上から何番目かを数えるということをします。

例)8ビット中3ビット立ってるとして
10001100
最初1なので
7Ｃ2
を計算。0は読み飛ばし次の1でも
3Ｃ1
を計算。これ以上は変わらないので終わり。
で、上の二つを足す
7*6/2*1+3/1=24
あとはこの数と圧縮前のファイルサイズと立ちビットの数だけ出力すれば復元可能。

こいつはすげぇやとｵﾓて作ったら799バイトのデータを50分かけて圧縮して何番目のデータかの数値だけで2972バイト悔いました。
Ｃ(コンビネーション)て恐ろしいな

俺を圧縮してみろ！！

>>456
Lynch-Davisson 符号とか数え上げ符号を調べてみて

圧縮にはならないって事か？調べたけどあまり無くて分からなかった

10年くらい前、bzip で使われている
ブロックソートが何故圧縮にいいのか証明されていない、
と聞いた気がするんだけど、今はもう証明されているの？

( >>460 http://www.google.com/search?q=BWT+MTF&lr= )

>>460
有村　とか　Effros の論文読んでみて

>>456 >>459
Schalkwijk の数え上げ符号

長さ n のバイナリ文字列中に 1 の個数が w 個あるものを考える
このとき、インデクス i

　　i = Σj=1,n x[j] n-j C w[j]

を用いて1対1に対応付けすることができる。ただし、w[j] = Σi=j, n x[i]

符号化は、まず、1 の個数 w を ceil(log n) ビットの2進数で出力する
次に、インデクス i を ceil(log k C w) ビットの2進数で出力する
なお、ceil() は切り上げ

この符号化は、1記号あたりエントロピーまで漸近的に圧縮可能

>>463ごめん後半からわかんなかった…

ところでJAVAでLZWとLZ77とHUFFMANとDEFLATEを説明サイト見ながら自分なりの解釈で作ったんだけど
76Kbのビットマップをデフレで圧縮したら44Kbになったのね。
で、7zのZIPで圧縮したら37Kbになったのよ。
これって何がいけないの？Lhacaも7zより圧縮率悪いけど
どういう工夫すれば縮むようになるん？

教えてエロい人！

AGE

ハフマン圧縮について教えてください。

よくあるのは、出現率の低いものを２個取り出して、その和をつくり、さらに残ったなかから一番出現率が小さいものをとりだし、
これと、先ほどの和の結果との和をとり・・・
という説明です。

でもなんか要するに出現数のおおい順にソートして（出現ゼロ回のものは無視する）
A,D,B,C,・・・みたいに配列に入れます。
そして順に、1,10,110,1110,11110・・・
と符号をふればいいだけのように思えてしまいます。
なぜ小さいものを取り出して和を作り、さらに小さいのと和をつくり・・みたいなことをする必要があるのでしょうか？

最初俺もそう思ったけど、ちょっと考えたらそれじゃ意味ないことに気づいたんだよ
なんでかって？忘れたなぁ…

>>466
それは unary 符号（単進符号、一進符号）というもの

符号が最適になるには条件というものがあって、
unary の場合、記号の出現確率が 1/2, 1/4, 1/8, ... となる場合にのみ最適な符号を構成できる
一方、Huffmanはどんな出現確率の記号群に対してでも最適な符号を構成できる

なるほど。よくわからないけど間違っていたことだけはわかりましたｗ
ありがとうございます！！！！！！！！！

JAVAでLZWとLZ77とHUFFMANとDEFLATEを説明サイト
教えてくれ俺もみたい

データ圧縮法概説
というところ。その名の通り原理や概念を解説しているだけでJAVAどころか
プログラミングにすらふれていない。
でも説明は分かりやすいからJAVAでも作れた。

データ圧縮法概説
ないよ
どうすればいいの？

Internet Archive

つーか、ちょっとリンクを追いかけていけば生きてるサイトにたどり着いたぞ

どうやっておいかけるの？

我楽多頓陳館で検索。
管理人は一人で何役もこなすアニメ好きの54歳
世露死苦!!

見つかった？

今zip圧縮のサンプル作ってる

それはzlibとか使って？それとも圧縮部も自作？
自作だったら性能を上げる工夫とか教えてほしいです。

圧縮部分も自作です。組み込みに乗せるから
パフォーマンスそこそこでだいたい2kから10ｋいないの
zlibを作成しようとしてます。なので性能よりもマシン語
の吐かせた内容をコンパクトにすることに命をかけています。
私も工夫とかよく解らない部分が多いため、IEEEの論文などをいくつか入手し
勉強をしているところです。アルゴリズム的に速度を上げる方法と
コーディングレベルで最適化する方法2つの視点で最適化について
考えていますがまだ道のりは厳しいです

特許まわりはどうなのかしら?

現在猿でも分かるC言語講座をみながらJAVAでブロックソートとMTFとレンジコード制作二日目。
Cはよく分からんがブロックソートの符号化とMTFの符号化･復号化が完成
ブロックソートの復号がうまく行かない…

Huffman圧縮で質問です。
記号が一回しか登場せず、２分木が１つも作成できないような場合、
その記号にはどんな符号を割り当てるのですか？

多分最初に出現する記号の種類の数もカウントしてるんだろ？
俺はその値が1になる場合は2にしてもう一文字あると仮定して
やってる。その文字は何でもいいが大抵は0x0だな

>>483
「記号が1種類しかない」フラグを作って、記号を記録しとく。
「記号がいくつ現れたか」も記録しとけば、記号は全部空ビット列に変換で良い。

ありがとうございます。
>>484
なるほど。それならアルゴリズムに大幅な変更はいらないですね。
>>485
そうですね。Huffmanにこだわらずにってことですね。

今からどっちにするか迷います。ありがとうございました。

動的ハフマンって実装自体は特許事項に
抵触技術内容含まれてないですよね？

大丈夫でしょ。やり方にもよるかもしれないけど、まあ普通に作れば無問題

動画配信のMPEG４とかH264ってのは適合型ハフマンで送るのですか？
もしそうならパケロスしても大丈夫な理由を教えてください。

やっとJAVAでブロックソートとMTFとRLE7とレンジ圧縮(圧縮だけ)
ができた。でもサイトにあるほどの圧縮率が出ないwwwww
なんで…orz

>>490
どこのサイトかしらないけど、結果だけ載せている場合は、かなり細かいチューニングや、
アルゴリズム改良が加えられていることが多い。

ソース・実行プログラムもあるなら、圧縮結果をバイナリ比較するとか、
サイトのプログラムによる出力を自作プログラムで展開させてみるとか（あるいはその逆）、
圧縮結果のバイナリそのものの解析をしてみたらどうだろう。

猿でも分かるプログラミング講座とかいうとこだったはず
Cのソースがあったから移植してみたブロックソートは間違いないからなぁ…
まあいろいろ結果を調べてみる

>>492
Cのソースプログラムが公開されているので、
1ステップずつ動作を追っていけばいいのではないか

途中の変数の状態を確認したり、演算結果に差異がないかを調べたり

いい忘れてたけどCのコンパイラとか持ってないんだ。
落とさなきゃだめかな？

今や、GCCコンパイラだけでなくMSコンパイラも無料。
「資金がない」で逃げる行為はもはや言い訳にならなくなった。

重いの入れたくない。はあり？

なし、軽いの入れればいい

sumという38000byte位のファイルを圧縮した結果250byte位劣って13Kb程になった。
実はヘッダなどの付加のしかたが微妙に違うのだがそれだけで
こんなに差が出るもんかな？ちなみに
BlockSort->MTF->ZLE+RLE7->RCA
って感じで4段階で圧縮してます。ヘッダ情報はどれもこっちの方が少ないのに…

>>498
アルゴリズムや定数も同じで、各段階でのヘッダも小さいのに
出来上がりファイルが大きいのなら何かバグってるんでしょうね。

>>499え!?マジで？℃チクショウーーーーーーーーー!!!!!

困憊羅が雨後かねぇwwwwwwwww!!!!!!

2chの圧縮ダットを解凍するにあたって資料が欲しいのですが、どこか頼みます。

TextSS　の64bit化おながいします

もしくは64bitにネイティブ対応した置換ソフトないですか？

新しい圧縮アルゴリズム考えようぜ!!

>>504は>>1も読めないのか

だってアルゴリズムスレ無いしここの再利用で十分だろ？
2chの無駄も減って一石二鳥だね

昨日、カミさんに怒られてrar圧縮されたさ
めっちゃ苦しかった

KWSK!!!!

へいっ!!!ついにやったぜ
JAVAにブロックソートとMTFとZLE7と適応型RANGEを移植完了!!ながかった〜
圧縮率は7z>BZIP2≒俺の>ZIPという感じ
これからは圧縮されたデータをさらに圧縮できるようにする変換でも考えるﾉｼ

ZIP圧縮について質問です。

zip32.dllに圧縮したいフォルダパスを-rオプションで渡した場合
zip内に格納されたファイルがドライブTOPからのフルパスで格納されてしまいます。

指定したフォルダ以下のみを格納するにはどうすれば、よいのでしょうか？

SetCurrentDirectoryしてから、相対パスで指定すればいいんじゃね？

511>

無事にできました(^-^;
ありがとう

正確には圧縮アーカイブではないですが、ISOイメージファイルのフォーマットが書いてある場所を探しているのですが、いいのはないですか？ とりあえず日本語のは見つかりませんでした。イメージファイルでないISO-9660自体の解説はあるのですが・・・

商用フリーな圧縮解凍ライブラリってありません？
利用はWindowsです。

http://cise.edu.mie-u.ac.jp/~okumura/compression/zlib.html
ここのサンプルcomptest.cで解凍しようとしても、エラー起こして解凍できないんだが、できます？

これで圧縮したのはこれで解凍できるな。
しかし、他で圧縮したのはこれで解凍できないし、これで圧縮したのは他で解凍できない。
ヘッダー？　ヘッダーの処理はzlibはしてくれないんですか？　初期化時にヘッダー付きを渡すとポインターとカウンターが変わるかもしれないと説明には書いてあるが、実際変わらない。　

zlibはdeflate処理をしてくれるだけでZIPファイルフォーマットの解釈はやりませんよ。
その辺は自作汁。

この辺の本を読んでみるとよし…と思う
http://www.amazon.co.jp/exec/obidos/ASIN/4797324287/

zlibを使ってデータの伸張をやろうとしてて

byte *src // 圧縮されたデータ
int len // src の長さ
byte *dst // 解凍されたデータの格納先

dst = malloc(5 * len * sizeof(src));
decompress(dst, src, len); // src を展開して dst に格納
// 適当な処理
free(dst);

みたいなことをやろうかなと考えているんですが、dstで確保したメモリが足りなかったときのことを
考えるとこれじゃあマズいでしょうし、あらかじめ必要なメモリの計算は解凍処理をしないと
分からないようだしでちょっと困っています。
皆さんならどうしますか？

圧縮も自前なら圧縮データとは別に（先頭につけるとかして）、
圧縮前のデータのサイズも持っておく。

ちなみにsizeof(src)は4バイトだろ。

CABについてお願いします。

CABファイル内のデータが欠けている場合にファイルを取り出せる可能性についてですが・・・

<CFFOLDER数=1>
CFFOLDER[0]
CFFILE[0]
CFFILE[1]
CFDATA[0]
CFDATA[1]

このような構造になっていて、CFFILE[1]が指すデータオフセットがCFDATA[1]内を指しているものとします。

この時にCFDATA[0]がまるまる欠けている場合、CFDATA[0]に適当なダミーデータを押し込むことによってCFILE[1]のファイルを取り出すことはできるでしょうか？

MSのツールEXTRACT.EXE等で調べたところ、どうもCFDATA[0]が完全でないとCFFILE[1]のファイルは取り出せないみたいなのですが・・・

圧縮法はLZXです。

後ろの方(例えばCFDATA[2])が欠けている場合はそれがファイル内容にかかっていても途中までですがデコードできるようです。

>513
普通の ISO イメージファイルだったら ISO-9660 に書かれている内容がそのまま直列で入っているだけだと思うが。

圧縮する前に圧縮後のファイルサイズのおおよその見当をつけるプログラムを
書こうと思ったんだけど、(ファイルサイズ) x (情報エントロピー) で計算すると
全然いけてないですか？

>>523
圧縮につかうモデルでのエントロピーでないとまともな数字が出ない。
ある程度でも結局圧縮するのと同じになってしまうのであまりいけてない。
まあ、とりあえずモデルを特定しないでHuffman,算術符号,RangeEncoderなどの
エントロピーを出しておけば最低保証値だけは出せるかな。

> 最低保証値
=元のファイルサイズ

ただ、圧縮アルゴリズムと対象データによってはサイズが増えることもありうる希ガス
もちろんその場合は圧縮しなければ元のサイズなんで圧縮しなければいいんだけど
「元のサイズ分あれば十分だろー」ってメモリ確保してやってみらたオーバーフローとか
かっこわるいことになることがあるかもしれない…？

>>526
そういうときは、1回の処理で増えうる容量分だけ余分に確保しておけばよい

その見積もりができないとか、1回で無限増殖しうるとか、そういうのはしらね
アルゴリズムを見直すか、出力方法を考え直すべきだがな

UDPのパケット（1K〜3K)を圧縮して転送、
受信して展開して、通信をやりたいと思ってます。
流すデータは未圧縮の画像データを分断して送受信します。
LZOのような、圧縮・展開の速いプログラムってないでしょうか？

>>528
LZOではだめなのかい？
Huffmanあたりをまず試してみて、圧縮率・速度の検討をしてみてはどうか

>>529
GPLなので困ってます・・・
＞Huffman
なるほど、試してみます。

LZMA SDKを落としてJavaのソースを動かしてみたところ、
コンパイルは何とか通ったのですが実行できません。

ファイルの初期配置も何だか変な気がするのですが…。

これ、何か不具合でしょうか？
それとも私が何かの設定間違ったのでしょうか？

誰かわかる人いたら教えてください。

てか、やっぱりこういう用途でJavaって邪道なんですかね。
扱ってるサイトも見ません。

>>531
こういう用途ってどんな用途だよ

>>532
その辺からサンプルソースを落として
とりあえずコンパイルすれば何もせずに
目的のものが手に入ると思ってる用途

だろ？

スルーされたと諦めて見てなかったり。
気まぐれで覗いてみたら回答というか煽り文句がついてて
嬉しいんだか悲しいんだか。
亀ﾚｽになるけど、せっかく返事もらったし。

>>532
ツールを作る用途のつもりで書きました。
ゲーム制作だとかは（使えねぇと言いつつ）結構あるんだけど…
ツールの例がちょっと見つからなかったので。

調査不足ですか。ごめんなさい…。

>>533
適切な分析をどうもありがとう。
とりあえず、パッケージの設定と配置されてる階層が明らかに違うものがあったのですよ。
ちゃんと動かしたら治ったけどね。
サイトのミスかこっちのミスか気になったんだけど
自己解決と言うか自己完結。どうでもよくなっちまった。

>>534
それを作者にフィードバックしてこそ、ネットの意義じゃないか・・・

商用配布フリーな圧縮解凍ライブラリを探しています。
おすすめなどありますか？

>>536
zlib

>>535
それはそうなんだけどね。私チキンだから…。
それに、いまだに誰もフィードバックしていないという点が
用途に関する疑問につながってるわけで…
まあ、そんな御託というか言い訳はどうでもいいか。

それより改めて聞きたいことができてしまいました。
7z形式のデータ書式がどんな構造してるかわかる人いませんか？
バイナリで開いてみたりしたところ

7z〜（たぶんヘッダ）圧縮したファイルのデータ…　ファイル名らしきもの（たぶんフッタ）

って構造になってたのですが、これの細かい仕様がわからないのですよ。

使ってる間は保存形式なんて気にもしてなかったんですけどね…
使う側から弄る側に来て、自分の無能っぷりを痛感しております。ﾊｲ。

統合アーカイバプロジェクトのいろんなヤツを落とせば
開発用のヘッダとかに書いてあるんじゃねーの、そんなもん。

>>539
統合アーカイバプロジェクトとは何ぞや…っと。

googleで検索→（ﾟ∀ﾟ；）ｱﾊﾊハ…orz

情報提供ありがとうございます。
理解できるか怪しげですが…やるだけやってみます。

＞7-zip32.dll は基本的に本家 7-Zip の 7za.exe のソースの
＞main() を呼び出しているだけに過ぎません。
＞理由は 7-Zip は現在進行形で日々進歩しているのでフォーマットを解析して
＞独自に作成すると新しい形式にすぐに対応する事が出来ないためです。

ｳﾎﾞｧｰ(ﾟДﾟ)

>>531
本家は最初に見たんだよね？

>>541
統合アーカイバは、
基本的にこの手のものはライブラリで済ますか、
引数の統一を行うインタフェースであることが多い。

>>542
7-zipの日本語サイトは見ました。
…もしかして、ここで言う本家って、英語ページのことだったりします？
やっぱり見なきゃダメかな…。

byteで取り出してあとはループで解読していけばいいかなーとか考えてたら
解読部分のソースjavaで置いてないし。
7z書庫のフォーマットもわからないし。

フォーマットの解析からするしかないのかな…。

>>543
7zFormat.txtというそのまんまな文書がLZMA SDKに入っているように思うのですが、気のせいでしょうか。

英語のドキュメント読む練習しておくと絶対に役立つよ。

>>544
…。
('A`)ｳﾎﾞｧｰ
しかもなんか、このﾃｸｽﾄ見覚えがある気がするぞ('A`)ｳﾎﾞｧｰ。
ご指摘ありがとうございます。明日にでも中身見てみます。

やっぱり英語は大事ですね…。
でもノバとか行く気無いしなー。

>>546
日本語の読み書き・会話がフツーにできても日本語の難しい技術資料を読むのは大変。
それと同じで、どんなに英語ができるようになっても技術系の情報はどうしても読み辛さがつきまとう。
だからもう英語の技術情報の読み辛さは開き直って受け入れるしかないよ。
ちなみに逆にある程度、英語になれちゃうと日本語と違ってあいまいさが少なく直接的な表現が
多いから下手な日本語の技術資料よりもよっぽど読み易いこともある。

>>547
それって逆だろ

英会話はからっきしできなくて英語の小説もさっぱりワカンネ
英語は専門書ぐらいしか読めないやって理系は多いと思うぞ

>>548
>英会話はからっきしできなくて英語の小説もさっぱりワカンネ
>英語は専門書ぐらいしか読めないやって理系は多いと思うぞ

俺の経験からすると全く逆だ。俺も英語は技術資料を読むためだけにしか使ってなくて
自分の英語力の低さを嘆いたんだけど、こんなことじゃいかんと英語圏のメーリングリスト
に参加してみたらそこでやりとりされてる会話が思いの外スラスラ読めてビックリした。
それで俺は、あー、やっぱり英会話って中学生の英語レベルで十分意思疎通は可能
なんだなぁと思ったもんだけど。

ぶっちゃけ、外国語は才能。
才能の無い奴はいくら勉強しても無駄。

一方で、できる奴がやたら必死に「努力すれば誰でもできる」
ことにしたがるのも外国語という分野。

>一方で、できる奴がやたら必死に「努力すれば誰でもできる」
>ことにしたがるのも外国語という分野。

それはその他の多くの分野でもそうだろ。
俺も、中学生の頃ぐらいまではプログラミングを「努力すれば誰でもできる」ものだと吹いていた。
いまじゃ、ほとんど逆のこと言ってるけどねｗ

仕事になればかなりのアフォでもアフォなりにプログラムは書けるようになるよ。
仕事じゃないなら、プログラミング自体が趣味だとか、
興味の対象とすることに応用できるとか（音楽家が演奏PG作るとか）何か理由がないと
向いてる人以外はそもそも学習意欲がわかないだろうね。

俺みたいに、才能ないけど、好きで趣味でやってるやつもいますよ。お忘れなく。

野暮な突込みで恐縮ですが
>>552にも「プログラミング自体が趣味だとか」と書かれておりますし
忘れたわけではないと思いますよ。

仕事で、多少リアルタイム性が必要な不定長バイナリの通信データを圧縮
しろって言われてしまいました。データ自体のパターンは限定せず、場合に
よっては1バイトから即時送信できないといけないようです。もちろん、最初の
方のデータが増えるのは構わないのですが、「データ送信を継続しているうち
にだんだん圧縮が効いてくる」ようにしたいのです。
一応売り物に組み込むものなので、自分で作るのは信頼性&手間&特許絡み
でめんどいので、できればzlibあたりを使いたいのですが、こういう場合にも
使えるものなのでしょうか ? おそらく、任意のタイミングで出力バッファを
flushしてデータを送信してしまっても、蓄積した圧縮に必要な情報がそのまま
残って以降のデータに適用できれば使えるとは思うのですが。

仕事
しろ



まで読んだ

俺は

仕事
しろ
よ

まで読んだ

> 　　　　 バイト
> 　　　　　　　が増えるのは
>
>
> 　めんどいので、
> 　　　　　　　　　　　　　　　　　　おそらく
> 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　そのまま
> 残って　　　　　　　　　　　　　　　　　　　　　ると　思う

Info-ZipのUnzip32.dllのAPIを用いて解凍を行うプログラムを作って
いるのですが、サンプルを参考にして下記のようにしてみても、解凍
後のファイルが作成されません。

　　m_hUnzipDll = LoadLibrary( "unzip32.dll" );
　　if( m_hUnzipDll != NULL ){
　　m_pWiz_SingleEntryUnzip = (_DLL_UNZIP)GetProcAddress( m_hUnzipDll, "Wiz_SingleEntryUnzip" );}
　　else{　MessageBox( 0, _TEXT("ERROR on LoadLibrary"), 0 );　return;
　　}
　　m_lpUnzipUserFunctions.password = Password;
　　m_lpUnzipUserFunctions.print = DisplayBuf;
　　m_lpUnzipUserFunctions.sound = NULL;
　　m_lpUnzipUserFunctions.replace = GetReplaceDlgRetVal;
　　m_lpUnzipUserFunctions.SendApplicationMessage = ReceiveDllMessage;
　　m_lpUnzipUserFunctions.ServCallBk = ServerCallback;
　　LPSTR acArchiveName = "C:\\testdir.zip";
　　m_lpDcl.ncflag = 1;
　　m_lpDcl.fQuiet = 2;
　　m_lpDcl.ntflag = 0;
　　m_lpDcl.nvflag = 0;
　　m_lpDcl.nzflag = 0;
　　m_lpDcl.ndflag = 1;
　　m_lpDcl.naflag = 0;
　　m_lpDcl.nfflag = 0;
　　m_lpDcl.noflag = 1;
　　m_lpDcl.ExtractOnlyNewer = 0;
　　m_lpDcl.PromptToOverwrite = 0;
　　m_lpDcl.lpszZipFN = acArchiveName;
　　m_lpDcl.lpszExtractDir = NULL;
　　(*m_pWiz_SingleEntryUnzip)( 0, NULL, 0, NULL, &m_lpDcl, &m_lpUnzipUserFunctions );
　　FreeLibrary( m_hUnzipDll );

上のプログラムではあらかじめ作成してある　C:\testdir.zip という
zipファイルを指定して、unzip32.dllのAPIであるWiz_SingleEntryUnzip
を上記のように呼び出して解凍を試みています。
マニュアルによると、圧縮ファイル内のすべてのファイルを解凍する場合、
第1引数と第2引数は上のように出来るはずなのですが、どこが間違ってい
るのかわからなくなってしまいました。
どなたかよいサンプルプログラム（動くもの）等をご存知の方がいらっし
ゃいましたら教えてはいただけないでしょうか？

zlibとかってストリーム形式でデータ扱えるけど、あれ内部的には小さなブロックサイズになって処理されてるの？

もしそうなら、前後の依存関係が問題になって、なかなかいい圧縮率を出せないような・・・

zlibはdeflate、deflateはlz77。
lz77は出力したビットへのポインタを符号化する。
なので、後方の依存関係はなくて、常に前方依存。
だからストリームに出来る。
といっても32KBのバッファは必要。
圧縮率の問題は依存とかじゃなくてアルゴリズムの問題。
PPMも前方依存でストリーム可能だけど多くの場合で圧縮率はlzよりもずっと高い。
こっちはメモリ沢山使うし遅いから少し使いにくい。

ちなみにこの前方依存は有限文脈とかマルコフモデルとか呼ばれる。
BWT(ブロックソート)は少し違う。

すみません。どこで質問していいのか、わからないのでここで質問させてください。

ウィルス検索について質問です。
ウィスル検索ソフトで圧縮ファイルを検査した場合、ウィルスを検索するのはファイルを一度解凍してから検索しているのでしょうか？
それとも、圧縮されたまま検索されているのでしょうか？
また、どのようにして、検索ソフトはウィルスを発見しているのでしょうか？
回答、お願いいたします。

本当にスレ違いなのだが一応。

ソフトによるとしか言いようがない。
圧縮されたものは解凍しなきゃならんわけだから
ファイルが圧縮されているのかどうか調べなきゃならん。
数ある圧縮形式全てを調べるのは不可能だから
普通に考えれば解凍はしないだろう。
ただしOSが扱える形式(WinXPならzip, cab等)は解凍して調べてるかもしれん。

ウィルスは大概怪しげなコードが入っているから、
既知のウィルスに共通している部分をハッシュ化して比較するんじゃないかと予想。
自己参照して実行可能アドレスにロードするとか。

あとは他で聞いとくれ。

>>564
大抵は解凍するんじゃない？
以前にどっかのウィルス保護ソフトが日本中の大量のPCを麻痺させた原因が、
圧縮ファイルの展開のバグでCPU100%使い続けてしまうって奴だった。

初歩的過ぎる質問でわるいのですけど、
Zlib.dll を使った場合のファイル解凍を行うとき、
使うソフトはなにを使えばよいのでしょうか？
Explzh　等のDLLを組み込んで使うタイプのソフトを探しています。

板違いだろ

ネットワーク等のストリームを介してアーカイビング、圧縮／解凍、暗号化
にまで対応した商用ライブラリってありますか？

あるよ。

商用可能な圧縮・解凍ライブラリを探してるんだけど
zlibだと、ちょっとソースが大きすぎ
このliblzf位の規模で、もう少し圧縮効率が良いのは無いかな？
http://www.goof.com/pcg/marc/liblzf.html

保守

>>570
奥村先生のアルゴリズム本なんかどうよ
http://oku.edu.mie-u.ac.jp/~okumura/algo/

あと、英語が読めるならここも参考になるかも
http://oku.edu.mie-u.ac.jp/~okumura/compression.html

鯖からzipのストリームを貰ってきて
オンザフライでデコードして手に入ったプレインデータから順次描画とかしたいのですが
近道を教示して下さい。

http://www.google.com/search?hl=ja&q=%E8%BF%91%E9%81%93+zip+%E3%82%AA%E3%83%B3%E3%82%B6%E3%83%95%E3%83%A9%E3%82%A4+%E3%83%87%E3%82%B3%E3%83%BC%E3%83%89

>>570
普通のlz77(lzss)のがコード量同規模で数割程度圧縮率高いけど圧縮速度が

>>573
zlib のソース・アーカイブの examples/ ディレクトリをまず見たら。
zpipe.c ってのもあるし。

そうそう、ソース とか 英文ドキュメントなら
http://zlib.net/ から辿れるよん。

ﾖﾝｻﾏを呼び捨てにするな

>>492
今更だけどもう公開してないのね

どうしちゃったのかねえ。
消す事ないだろうに。

lha書庫のCRCって、
poly: 0x8005, width: 16, init: 0x0000, revin: yes, revout: yes, xorout: no
なんだな。
ファイルのチェックによく使われるCRC16が、
poly: 0x1021, width: 16, init: 0xFFFF, revin: yes, revout: yes, xorout: no
だから、 poly と init が違う。
unlha32.dll で展開したファイルが正常かどうか FastHash.dll を使って確認しようと思ったら、
ことごとく値が違うからハマってしまった。

>580
CRC16 って言っても色々あるわけだし。
ttp://en.wikipedia.org/wiki/Cyclic_redundancy_check#CRCs_in_common_use_.28in_ITU-IEEE_syntax.29
0x8005 の方が ANSI(↑だと IBM になってる)、0x1021 の方が CCITT っすね。

http://www.fileup.org/fup112424.zip.html
BIPという圧縮データが展開できなくて困っています。
同じ名前のbinファイルに出来れば良いのですが……

ググってみると、頭４バイトが展開後のサイズ〜
などの解説ページも見つかりますが、よく分かりません
どんな圧縮になっているのか、知っている方いませんか？（展開方法）

>>582
「bip 頭４バイト」でググって、多分同じページにたどり着いた・・・
正直、胡散臭い用途にしか思えんのでマジレスしたくないんだがｗ

軽く読んだ感じ、ちょっと変わったLZ77ってだけのよーな
そこに書いてる情報で充分だろ。何が足りない？

胡散臭い用途ですみません……

LZ77っぽいのは分かったのですが
自分の知識不足で、そこに書いてあることが完全に理解できていません

・展開位置からの12bit負のオフセットにして、その位置から長さ+3バイトのデータをコピー
とか

はいはいDTM板の犯罪スレに帰ろうな

>>584
LZSSを勉強してきて・・・イヤマジで

「lzss」は一般的な方式だし、説明ページも豊富だから

>>584
12ビットの単純なスライディング辞書方式の簡易な説明に読めるが・・・
何がわからんのか解らない。
引用部以外に意味不明な部分があるのか？

LZSSをよく勉強してきます、レスありがとうございました
スレ汚し失礼しました

>>579
どうやらインターフェース誌で連載してる模様。
ちら見だけどWebとほぼ同じ内容ぽい。

>>589
本当だw
教えてくれてありがとー
番外編もやってくれれば最高！

質問です
拾って来たZIPなんですが
中国語文字コードでファイル名・パス指定されているらしく
解凍レンジとかだと
win9x上で解凍できませんｗ

いいソフトありますか？

ありゃ、ここム板だったじゃんｗ
VB6使いだったがｗ

特別に
とりあえず、こういう場合に簡単に取り出せるソフト教えてｗ

それはソフトウェア板ネタだろ

Cのソースコード発見
ｈttp://nog0709.hp.infoseek.co.jp/reports.html

>>594
これは参考になるな

すみません。質問させてください。

bz2形式の圧縮ファイルの元のファイルサイズを
実際に展開せずに知る方法はないでしょうか？

>>596
ないっちゃね

>>597
やっぱりそうですか。地道にカウントします・・・。

パスワード付きrarを解凍できる、rarアーカイバを作りたいんですが、オープンソースなのはどれがあるのでしょうか？
UnRAR Sourcecode 3.4.3とうのしかなさそうなんですが、これでいいんでしょうか？

clamav のソースに libalamav/unrar/ に rar 展開ソースは入っているが
パスワード展開には対応していないな。。。

>>600
どうも。
人いないんですかねこのスレ。
winrarのサイトでもうちょっ新しいunrarsrc-3.6.8.tar.gzがありました。
MacOSXのソフトでもunrarを使っているようなので、これで良いのかもしれません。

ttp://www.uploda.org/uporg596558.bin.html

何の画像形式が、ご存知の方いらっしゃいませんか？

>>602
fileさんによると
> uporg596558.bin: Hitachi SH big-endian COFF object, not stripped
だってよ？　画像じゃなくて実行ファイルじゃ

と思ったが中身見てみると確かに32bitの色情報くさい感じはするな。
適当に作画させてみたらどうか？

なんやよくわからんが顔色の悪いおなごが出てきたぞ
ttp://www.uploda.org/uporg596801.png.html

640x480の32bit生データなんだがどうも縦16でblock化（？）されているらしく、
そのままbmpのヘッダ付けただけだとだめっぽい。
とりあえず↑のは512x608にして、mspaint使って手動で再構成してみたが、
横512なあたり考えると3D作画エンジン用のテクスチャかなんかかの。
こんなバカなことせんでもなんかのツールにぶちこんだら普通に表示されるような気がするようなしないような。
詳しい人フォロー頼む。3D関係は全然ワカラン。

っか、圧縮なんかされてねーからぶっちゃけスレ違いな気ガス




ところで画像の詳細を教えてもらおうか

>>603
ありがとうございます
参考にします

遅レス気味だけと >>599
http://p7zip.sf.net のソース読んでいたら、
7zip/Crypto/ 以下に rar やら zip でパスワード付けた時の処理があった。
各圧縮ファイル形式のファイルヘッダや通常の解凍などは
7zip/Archive/ 以下だったりするけど。

Deflateの展開ルーチンを自前で実装しようとしてるんだけど、
これってひょっとして全部リトルエンディアンなの？
しかもハフマンは右(LSB)から1bitずつ読むわけ？
なんか統一感が無くて判り辛いよ。
なんでこれが普及したんだろ。

てすと

unzip32.dll はAES暗号化されたファイルに対応しているんでしょうか。
詰まってしまいました。
未対応なら他の方法を考えるんですが。

age

動画圧縮に関してはここでいいのかな？

H.264の詳細は、一般人でも入手出来ますか？
何をやってるかは大体は情報が手に入るんだけど、実装できるレベルの資料がない・・・。

>>611
http://www.itu.int/rec/T-REC-H.264/en
http://www.itu.int/rec/T-REC-H.264.2/en
http://www.compression-links.info/MPEG-4_AVC_H264
http://www.mpegla.com/avc
etc.

>>606
ありがとうございます。
ソースを読むにはまずc++を勉強しないといけないのかな。cしかやった事ない√|○

>>613
クラスとSTLの勉強だけだ、おれなんてC++からはじめたし

英単語辞書を圧縮された状態で検索に使いたいのですけど、
辞書順にソートされた文字列のリストを、検索可能なままで
高圧縮できるアルゴリズムってありますか？

BPEしてcommon prefixを削除すれば、1/3までは小さくは
できたのですが、もっと効率いいのがあれば

ランダムアクセス可能な圧縮方式は局所性を利用できないから
必然的に圧縮率が落ちるよ。
ブロックソートなんかはソート済みデータには弱いから多分ダメ。
PPMは遅い。
今のままで十分かと。
もうやってるかもしれんがprefix毎にブロックにすると圧縮率が良くなる。
prefixでソートされてるんだから辞書全体に対してsuffixを登録して
prefix単位でブロックを作るのがいいかも。

>>616
＞ブロックソートなんかはソート済みデータには弱いから多分ダメ。

別に弱くは無いよ。
原理的にはPPMと同じ。

>>615
FM-index とかどうよ？

>原理的にはPPMと同じ。
んなこたーない。

>>619
その辺のことはDO++が説明してたよ。
アルゴリズムとしては違うけど、結局圧縮しているものが同じってこと。

abcdeという文字に対して
abcdからeを符号化するのがPPM
bcdeからaを符号化するのがBWT
という意味では同じかもしれんけど
BWTは決められたブロック内の情報のみ
PPMはそれまでに出現した情報のみである点が違う。
つまり任意のシンボルが参照できる情報の範囲と質が大分違う。

>>621
＞BWTは決められたブロック内の情報のみ
＞PPMはそれまでに出現した情報のみである点が違う。
＞つまり任意のシンボルが参照できる情報の範囲と質が大分違う。

範囲なんて調整次第。
PPMだって現実に実装するときはブロックに分けることになるから。

違いは、
BWTはPPMでは未来の出現に相当する部分の情報も使う。
PPMは、それまでに出現した過去のみの情報を使う。
ってぐらい。
ただ、未来の出現といっても、時系列情報を失うので、BWTが特に優位というわけでもない。

結局何が言いたいのかよく分からん。
やっぱりPPMとブロックソートは違うものだって結論に変わりはなさそう。

>>623
616の指摘はおかしいということ

ソート済みデータのベンチマーク
ttp://www.maximumcompression.com/data/dict.php

BZIP2がPKZIPに負けてる。

大量の単語がソートされているならLZ77が強いんじゃね？

可逆圧縮で、圧縮率より高速性を重視したアルゴリズムでいいのありませんか？
特許に抵触しないフリーなやつでお願いします。

>>628
最近のCPUはめっちゃ速いから、ファイルアクセスやってる間に
だいたい圧縮処理が終わっちまうんじゃね？

lzo とか?

zlibって特許まみれ？

探せばなんかに引っ掛かったりするかもな。

圧縮
　　　　　　　　＿＿＿＿＿_
　　　　　　／ ／／　 　 ／|
　　　　　　|￣／　￣￣,:|//!
　　　　　　|／_,,..,,,,_ .／ .!/｜
　　　　　　| ./ ,' 3／`ヽ::|っ.!
　　　　　　| l　／⊃　⌒.|つ|
　　　　　　|／ｰ---‐'''''"|／
　　　　　　 ￣￣￣￣￣
解凍
　　　　　　　　､ゞヾ'""''ｿ;μ,
　　　　　　　ヾ　 ,'3　　　 　彡
　　　　　　 ﾐ　　　　　　　　 ミ
　　　　　　 彡　　　　　　　 ﾐ
　　　　　　　/ｿ,,　,　,; ,;;:､ヾ`

エラー
　　 　　　_,,..,,,,,,..,,,,,..,,,,,,..,,..,,,,,,..,,,,,,,,..,,,,_
　　　　　/ ,' 3,' 3,' 3,' 3,' 3,' 3' 3,' 3,　 `ヽｰっ
　　　　　l　　 ⊃⊃⊃⊃⊃⊃⊃⊃⊃.　⌒_つ
　　 　　 `'ｰ---‐---‐---‐---‐---‐'''''"

深刻なエラー
　　　　_,,..,,,,_
　　　./ 。　 `ヽｰっ
　　　l　o　3　　⌒_つ
　　　 `'ｰ---‐'''''"

圧縮アルゴリズムの性能の評価ってどうやるの？

c_i が元の符号(符号長 n で固定)で d_i をその圧縮後の符号として
Σ len(d_i)/Σ len(c_i)
とか計算したら大体どんな圧縮法でも大体1より
ちょっと大きくなるくらいになるよね？

現行ツールだと大抵、自己展開CAB(exe)を実行せずに強制展開出来る、
あるいは拡張子を.CABに変えると出来たりするんだが…

それでも展開しにくいファイル、というのはあって、
ツールによって展開出来たり出来なかったりする。

で、そういうファイルを調べてみたら、ヘッダ("MSCF〜")らしきものが複数あって、
最初のヘッダは不正で、3番目のヘッダが正解だった。
単にファイルの先頭からヘッダらしきものまで読み飛ばすだけだと、
こういうのに対応出来ないわけだ。

これ、確実な調べ方あるんだろうか？
それともヘッダらしきものを総当りで調べるんだろか？

ここでの質問でいいのかわからないのですが、

フォルダ（ディレクトリ）をアーカイブファイルで保存・管理することを考えています。
そのとき、アーカイブのデータを使って元のフォルダの差異が知りたいのですが、
なにかうまい方法（「展開して差分」以外で）はあるでしょうか。

例えばフォルダAとフォルダBの内容が等しいかどうか（具体的には再帰的にファイル
内容の差分（Unix なら diff -r）をとって差があるかどうか）を、対応するアーカイブAと
アーカイブBの差から知りたいのです。
フォルダAとフォルダBの内容が等しい <=> アーカイブデータが等しい
となるようなアーカイブができるとうれしいのですが。

一般的なアーカイブフォーマットにはメタデータ（タイムスタンプ等）が含まれたりして、
アーカイブの単純な差分では駄目なようです。上記の目的のためにはタイムスタンプ等
はいりません。

よろしくお願いします。

アーカイブファイル内のディレクトリ情報から、サイズとCRCを
比較するだけでいいと思うが。

で、ここがプログラム板だということは分かっているんだろうか？

11
12
1121
122111
112213

昨日の平成教育委員会にやってた google入社試験からの問題か

連長圧縮？

連長っちゃ連長だけど、ぜんぜん圧縮できてない

>>639
いつのまにそんなの取り上げるようになったんだｗｗ

俺時間内に解けなかった
どうしようorz

12221131
1123123111
12213111213113
11221131132111311231
なんか3が出てきた時点で急速に発散

だれかgzipを解凍する簡単なコードを見せてくれませんか？

DLLつかえ

どるるるるるるるるるるうるるるうう

自前でやりたい。

zlib を見よ！

ラプラスで画像ファイル（ビデオ）を圧縮しても容量が小さくならないのは、
どうしてですか？

むしろ大きくなってるだろ

はたして、容量が小さくなってないものを「圧縮した」と言うのだろうか。

可逆で圧縮率と解凍速度に優れたフォーマットって何になりますか？

>>650
ラプラスって、ラプラス変換? あれは圧縮とは別次元だぞ。
例えば、CR(コンデンサー+抵抗)の回路などで作った
フィルターの特性を一次式に変換するとかそういう奴でしょう。

確かに、フィルターかましたり、
わざと見えないくらいのノイズを載せたりして
圧縮効率を上げる技はあるけど、
常に圧縮率が良くなるという話でもなかったりします。

GB単位で圧縮かまさなければ速度なんて今は殆ど問題にならんような
BWTとかPPM系でもそこそこの速度で動くでしょ

それよりマルチコアが一般的になったからマルチスレッド動作可能なのを考えたい
まあデータを分割して既存のアルゴリズム適用すればいいだけの話だけど

C#でzip32j.dllを使用して以下のような構成の圧縮を行いたい場合は
どうすれば良いでしょうか？
c:\aaa\bbb\ccc\ddd\file.txt
とある場合に、cccフォルダ以下を圧縮したいのですができません。

オプションで-rを指定するとaaaフォルダから圧縮され、
-rjを指定するとccc以下のテキストが指定した作成したzipﾌｧｲﾙ
直下に格納されます。
ちなみに、コマンドラインの圧縮対象には「c:\aaa\bbb\ccc」を
指定しています。

10万ファイル格納されているZIPファイルのファイル一覧を、待ち時間無しで取得する方法ありますか。
定番のUNZIP32.DLLでは書庫をOPENするのにとても時間掛かります。
最近出たINFO-ZIP最新版だと軽いですか?

ZIPフォーマット調べて、自分で読んでみりゃいいじゃん

ファイルの一覧取るくらいなら、圧縮とか気にしなくていいし

>>685
すみません。ひとつひとつファイル名を取得して、あと個々に(メモリ上へ)　解凍もしたいんです。
速度が出ていいやつありませんか?　UNZIP32.DLLはオープンに時間掛かるのでは除外します。

Zipフォーマットは複数合ってすべてに対応するのは、自作では厳しいです。

自己解決しました
UNZIP32では、1分待っても反応無しのが
7-zipにしたところ30秒で済み
XacRettではなんと0.3秒でopenﾃﾞｷﾏｼﾀ。

XacRettはopen速いですが、個々のファイルの取得が超掛かります。使い物になりませんでした。

だから世にあるフォーマットの仕様を確認すれば違いが判るじゃん。
得手不得手ってのがあるんだしさ。

使えねえやつらだな。

使う側だからね。

UN○○32.DLLってOSが64bitでも動くの？

x64のOSをまず使ってみてから、その愚かな質問についてあらためて考えるんだな

(…ふー、うまくごまかせた)

>>666
OSが64ビットLinuxだったら動かない。
……と言うボケは置いておいて。

XPは知らんがVistaではとりあえず動く。
動くけどそのDLLを使うソフトも32ビットじゃなくちゃダメ。
もっともそのDLL使うと明言していて64ビットで作ってる馬鹿はいないはずだが。

結局のところ、lzwは使っても特許的に問題ないですか？

パテントの有効期限切れて、更新ははしなかったらすいが > うにしす
ただ前も言うことをコロコロと変えているので、安心とは言えない気がする

サブマリン特許ですね！

>>634普通は1よりべらぼうに大きくなるだろエントロピー的に考えて・・・
1よりちょっと大きいだけって、ほとんど圧縮出来てないんじゃね？

ttp://www.highcelight.com/extraction/
上のように、復元したものの文字列を直すフリーソフトってありませんか？
メモ帳のものを復元できたと思ったら、文字化けしていました。

それは復元できてないだけです

スレチかも知れませんが
.ewaという拡張子で暗号化・圧縮・分割・結合する
海外のソフトウェアを知りませんか？
1990年代後半に使われた物らしいですが
ソフト名がわからず困っています

イタチなのでソフトウェア板に行って下さい

Windows上で動作するゲームを作っているのですが
そのゲームで使う画像・音声ファイルを、どうやって1つのファイルに格納しようか迷っています

最初は自分でフォーマット決めて、各ファイルを順々に詰めていけばいいかと思ってたんですが
よく考えたらtarや無圧縮zipなどを使った方が
既存のライブラリを使える分、もっと楽だということに気づきました

こうした用途に向いているのは、どの圧縮形式でしょうか？

自分が一番扱いやすいフォーマットでいいんじゃね？

圧縮せずに、ただまとめるだけなら、自分でやったほうがいいと思う。

tar一択だろフォーマット的に考えて・・・まさにその為のフォーマットなんだし。
ただ、自分でやった方が高速軽量になると思う。
単にまとめるだけにしては高機能杉るんだよtarは。

ゲームでところどころ取り出すのにはtar向かないフォーマットだった気がするが？
tarはソリッド圧縮的な扱いでそういうの苦手だった気がするが
最近はその辺を改良したtarがあるのか？

そういう意味では個別抜き出しできそうなフォーマットで無圧縮使えばいい。
ライセンス的にLGPLで問題ないなら7-zipが明確。Zipはライセンス料発生するかもしれない。

ここの>>570にのってるliblzfが個人的にお勧め。
BSDライセンスでコードも短い。圧縮は64k毎のデータの圧縮を連結している感じ。
ライセンスがある程度自由だと、自作のファイルフォーマットに組み込みやすい。

ご意見ありがとうございます！
まとめると

1. 自分で詰め込む
2. 7-zipやliblzfを用いる

の2種類が適切なようですね。調べつつ考えてみます

>>684
osaskのsar

>>685
仕様やライブラリが公開されていないようなのですが
どこかに置いてあるのでしょうか？

どうでもいいメモ。NTFSの圧縮形式はLZNT1であり、既にリバエンされている。
http://cs.fit.edu/~mmahoney/compression/text.html#6368
…ロシア語読めなさ杉ワロタ

ははは

独自でサバクラを作成ししています。
サーバからクライアントにZip圧縮したバイナリデータを送信して、クライアントのメモリ上で解凍する必要があります。
(ファイルにはしないで、ストリームデータです。)
このときに使用できるｄｌｌやライブラリを探しているのですがご存知の方はいないでしょうか？
unzip32.dllでは無理ですよね。

環境はWindwsXpです。

unzip32でもできると思う

rarにzlibみたいなライブラリ無いの？
rar3形式かどうか判定出来るだけでも機能が欲しい。
hexdumpしてみたけど、RAR3みたいなバージョン文字列は無い様なので、同じバイトコード列かどうか判定するしかない？
眺めた感じだと、１バイト目から１６バイト目までのバイト列と、４５バイト目から４８バイト目までのバイト列で判定すればいいの仮名？

>>691
unrar.dllでReadHeader(Ex)を使い、RARHeaderData::UnpVerの値を読んでやると分かるかもしれません。

可変長の符号をファイルに出力したいのですが
どのようにすればいいでしょうか？

例．値(10進)「3 3 6 3 6 2」

3・・・00
6・・・01
2・・・100

出力後のファイル(2進)「0000010001100」

最低１バイト単位でファイルに出力したいのですがググっても分かりません・・・
因みにVS C++　です。
スレチを承知ですが、宜しくお願いします。

ｃ++スレへどうそ

http://pc12.2ch.net/test/read.cgi/tech/1258158172/
C/C++の宿題片付けます 132代目

一般的なソフトで
250kb程度のJPG画像の可逆圧縮で圧縮したら一般的にどの程度なんだろ？
原本JPG->204704byte
rar->204697byte
zip->203342byte
作ったやつ->152822byte

俺最高ｗｗｗｗ

どんなjpgかによる。
単色なら数バイトに出来るんじゃね。

>>1
zlibのソースを見るといいですよ。

>>697
お前は単色の白や黒が一般的なのか(笑)

>>699
うるさーい。

２５６色減色アプリでも作ったほうがいいだろ。モノクロ２５６階調アプリでもいいけど。

実際に画像ファイルの統計を取ったら単色の白や黒の比率はかなり高そうだな。
某人気漫画家の作品のような状態で放置されたファイルもたくさんあるだろうし。

個人のストレージ節約には使えても
配布のためには用を為さないな

配布なら尚更サイズ小さく出来たほうがメリット大きい。

圧縮解凍プログラム作った時の疑問点なんですが、最初unzip32.dllを使用していて解凍したのですが、
必ず解凍確認ダイアログが表示されてしまうので、7zip.dllに乗り換えました。
解凍確認ダイアログ消す方法ってあるんですかね？

>>704
や、単なるモノクロ絵を配布はあまりしないだろうという話

>>705
「解凍確認ダイアログ」というのがよく分からないので、間違っていたらすみません。
展開時の上書き確認ダイアログのことであれば、(統合アーカイバの)unzip32.dllでは-oスイッチで自動上書きにできるかと思います。
展開時の進捗状況を表示するダイアログのことであれば、(統合アーカイバの)unzip32.dllでは--iスイッチで消せるかと思います。

7zip.dllが7-zip32.dllなのか7z.dllなのか、あるいは他のdllなのかも分かりませんが、
7-zip32.dllであれば、それぞれ-aoスイッチと-hideスイッチが該当するかと思います。
info-zipのunzip32.dllや7z.dllについてもおそらくその類のダイアログを表示しない方法はあると思います。
的外れな回答をしていたらすみません。

>>707
的外れではなく、合っていますｗ
「解凍確認ダイアログ」というのは、解凍終了しました等、解凍した（何か動作した）と分かるようなPOPUP画面の事です。
自動上書き、進行状況非表示を引数で指定したのですが、進行状況を表示するための空のPOPUP画面がどうしても消えませんでした。（進行状況自体は消えましたが）
readmeを見たのですが、
それらしきオプションもなく断念しました。

>>708
すみません。開発者用sdkのUNZIP32S.txtに次のように書かれていました。
> また、標準で結果窓が表示されるようになってます。これを禁止するには以下のレジストリに ShowResult と言う DWORD 値を作成し、0に設定してください。0 のかわりに 0xFFFFFFFF とすると、エラーがあったときだけ結果窓が表示されます。
> HKEY_CURRENT_USER\Software\ArchiverDll\UNZIP32\Settings\
UNZIP32.APIに記されている内容によれば、この設定は初期値でoffになっているようですが、何かの拍子に設定が変えられてしまっていませんでしょうか。

データ復活/完全削除 【無料版】

これもうダウンロードできないけど

持っている人いないかな？

ソフトウェア板で聞けよ
ここは作る方の板だ

資料にするんだろ

それならそれでスレ違いだな

わざわざスレチ教えるなんてやさしい奴ら

でも「データ復活/完全削除」超えるフリー無いな

新しい圧縮方法考えてみた。0と1が何個続くかをデータにする。
1bit目は開始するbit
1000→113
0110→0121　となる
7以上は0をはさむ(7かどうかは未定)
0101 1000 0000 0010
なら
0111270211
3桁ずつに分け、3の倍数にならなければ0を付与する
011 127 021 100
3桁(999)は10bit(1023)あれば足りるから
0101 1000 0000 0010
は
0000001011 0001111111 0000010101 0001100100
となる

　あ…ありのまま 今　起こった事を話すぜ！
　『自作の新圧縮方式を試していたら
いつのまにか容量が増えていた』

　な…　何を言ってるのか　わからねーと思うが
俺にもわからねえ

>>715
それ、どう見てもランレングスだと思うけど。
新しいどころか、何十年前の話だ。

1000→113
この時点でおかしいｗ

自然対数の底とかなんとか

>>716
全く同じでﾜﾛﾀ・・結構いいと思ったんだけどなぁ・・
>>717
113は
一文字目が'1'で始まる、二文字目は一文字目の数字が'1'つ続く、
三文字目は前と反転しているビットが'3'文字続く、の意味
そんなことしなくてもwikipediaみたいに・・

そもそもとっくにあるものの劣化版なのでどうでもいいな・・

0 と 1 なら、数え上げ符号にしておけとあれほど・・・

>自然対数の底とかなんとか

これって良く見るけど
そこ？
てい？
どっちですか

高校で習うよ

てい

ありがとうございました
でもなんで 2.71828182845904523536028・・・ みたいな変な数字なんだろ

e = 1/0! + 1/1! + 1/2! + 1/3! + 1/4! + ・・・・
だからさ

それは自然対数の底だな。

分野によって10（工学関係とか）2（情報関係とか）が底のこともある。
2とかそれ以外が底だったら普通は明示される。
たいてい10かeが底で、底がeの対数は特にlogではなくlnと書かれたりする
（その場合logで示されるのは底が10）。

ネイピア数（ないしオイラー数）eは (1 + (1 / n)) ** n （ ** は冪乗）の n を∞にした
時の極限（ほかにもいろいろな定義はあるが）。いろいろな性質がある。

たとえば、y = e ** x というグラフの傾きは e ** x であるとか。

logって何が便利なの？

高校で習うよ

eとかlogとかって圧縮復元に役に立つの？

729の役には立たないよ

>>727
例えば10進数で81桁の数値は64進数だと何桁必要か計算するときにlogを使う。

６４進数とか要らないなw

Base64なんかはある意味64進数といえなくもない

位取りの概念がないじゃない

は？馬鹿ですか？

ぼくではない

"Move To Front" の改良 良になっていると思います
　過去２Byte値から今の１Byte値を"Move To Front"するテーブルを選ぶ
　　詳しい処理はソースを見てください
http://gmdev.xrea.jp/
　　　[標準10MB] [148.zip]　　実験用実行アプリ　Delphi4 ソース付き　

注意
　実行アプリのウイルスチェックはしてません　
　感染は無いと思いますが自己責任ということで

学生さんかな？
ここで晒してもしょうがないと思うのだけど…
MTFの改良とか一度は考えるよね
実際にやってみると大したこと無くてがっかりっていう
この手のやつをRecency Rankingというのだけど
頻度が考慮されないから算術符号やハフマン符号と比べるとだめなんだな
もっともっと勉強してちょうだい

再帰順位符号化法は、理論的にはエントロピーを達成できるよ！できるよ！

なんだ、ただのゴミか

「容量無限のHDD」実現の可能性も、新たな物理現象が発見される - GIGAZINE
http://gigazine.net/news/20110704_limitless_hdd/

LHCでブラックホール圧縮したほうが簡単。

>>741
昔に流行ったπ（円周率）圧縮と原理は同じ

それとは違うだろ

>>741
圧縮と関係ないから。

アキレスと亀みたいな無限圧縮理論があったろ。
あれと似てるねって話だろう。

基本的なことを教えてください。

�@１Mバイトのランダムなデータ列と２Mバイトのランダムなデータ列をファイルにしてzipにしました。
　　圧縮率はどっちが高いですか？

�A１Mバイトのランダムなデータ列と１Mバイトの数列（０，１，２・・・ｆｆH・・・）をファイルにしてzipにしました。
　　圧縮率はどっちが高いですか？

�B１Mバイトの数列（０，１，２・・・ｆｆH・・・）と２Mバイトの同じ数列（０，１，２・・・ｆｆH・・・）をファイルにしてzipにしました。
　　圧縮率はどっちが高いですか？

できれば、経験的な結果ではなくて、数学的？技術的結果を知りたいです。（経験的結果ももしあれば知りたいです）
よろしくお願いします。
当方ハード屋です。簡単なプログラミングはできるぐらいのキャリアです。

>>747
zipなら自分でやってみればいい。
zipじゃないなら、圧縮率がどうなるかは圧縮アルゴリズムによる。

>>748
レスどうも。

やっぱりやってみないとわからんものですか・・・
理論的にはどう考えたらいいのかを、聞きたかったんですが。

>>747
ランダムデータは多分全く圧縮出来ない
数列が00hからffhの方はもの凄く縮む
123は全て後者の圧縮率が高いよ
>>748の通り実験あるのみ

>>750
レス、どうも。

『データ量が多いほうが圧縮率が高くなる傾向がある』

と考えていいのでしょうか？
また質問ですみません。

>>751
いや、zipはLZ法といって
同じパターンを検出して別の符号で置き換えるという仕組みになってる
ランダムデータは繰り返しがないから圧縮出来ないし
数列の方は00h-ffhが繰り返されるからそこで縮むのよ

>>752
レス、どうも。

よくわかりました。
この場合ランダムデータと言えるか疑問ですが、
もし、ランダムデータでもちょっとでも繰り返しパターンが現れたとして、その大きさも出現率もランダムだとして、この場合少しは圧縮できると思います。
その場合は、

『データ量が多いほうが圧縮率が高くなる傾向がある』

とは理論的に言えないのでしょうか？
実験をして臨床的に？測定はできるでしょうが、まずは頭の中で整理したいので、よろしくお願いします。

>>753
データ(情報源)次第としか言いようがないんだけど
データ量が増えるほど参照可能なデータが増えるので圧縮率は上がる
と言える
ので理屈としてはそれであってる
言うまでもなく計算量は増えるけども

>>754
ありがとうございます。

ですよね。ランダムデータの共通概念を確認してから話すべきでした。
失礼しました。

圧縮について理論的な裏付けを探しているなら、
次のキーワードについて調べてみるとよいでしょう。
初等的な情報理論の参考書に出ているものです。

情報源（符号化）
エントロピー
ユニバーサル
エルゴード性
エントロピーレート

>>756
どうも。

わからないところが出てきたら、また教えてください。

>>749
やってみないとわからないというより、何を目的に聞いているのかわからないから、答えにくい。
圧縮もzip(LZ法+ハフマン)に限る話なのか、あらゆるアルゴリズムを検討するかによっていろいろ変わってくる。

情報理論的にランダムデータは統計的には圧縮できない。
(圧縮できるケースも０ではないが、できないケースがそれをはるかに上回る)

解凍速度重視でデコーダー書いてアセンブリ出力見て無駄が減り
実測でも速くなってるとお茶が美味い、でへへ

>>510-512関連での質問なのですが、
もし対象のファイルが複数あり、それぞれ違うドライブの場合、
どのように対応すればよいのでしょうか?

7zなら、パスを列挙したリストファイルを渡して圧縮させるコマンドが無かったか？

zip32j.dllで同じファイルを圧縮しても、
出来るzipのCRCが毎回違うってのは正常？

WinRAR使うと毎回CRCは同じなんだが

圧縮ルーチンの中で乱数使ってるんじゃないかな
解凍後のCRCが一致してれば問題なし

>>762
できたzipファイルのCRC、圧縮されたエントリのCRC
どっち？

前者なら最終アクセス時間も記録してるとかって可能性もあるよ。
後者だと理由がサッパリわからんけど。

>>763
なるほど。
確かに解凍後のファイルのCRCは一致してるんで、
実用上問題は無いんですが、ちと気になったもので。
これ常識なのかな、と。

>>764
前者です。

> 最終アクセス時間も記録
これですかね？

スレ違い

ふと気になってzipの仕様を見ていて疑問に思ったのだけれど、
「中央ディレクトリ」の存在意義ってなんですか？
わざわざローカルファイルヘッダと分離して、しかも書庫末端に配置
させている意味がわからないです。
書庫冒頭ならここを基点にランダムアクセスがしやすい、というのは
想像できるんですが、可変長コメントを終端に許容している時点で
後ろから計算するのも非常にめんどくさいことになってますし。
どうせだし作者にメールでも投げるか、と思ったら作者亡くなってるし。

LZH書庫のゼロ終端と同レベルには必要。

1passで書庫作る場合、中央ディレクトリみたいのをつけようとすると
どうしてもケツにしかつけられないってだけでしょ。
1passで書庫作れるようになってるのはzipの強みの一つだと思うんだが。

例えばlhaはチェックサム書き出すために一旦ヘッダまで戻らなきゃいかんから2passになる。
圧縮データをどっかに保存しておければ1passっぽくできるけど。そのために記憶領域が必要になる。

解凍することだけ考えてて圧縮のこと何も考えてなかった。
なるほど。確かに1passで作れるっていうその点は強みですね。
すごいスッキリしました。ありがとう。

ケツにもコメントの長さつけてくれれば
後ろから読むのが楽だったと思わずにはいられない

ファイル先頭に置くと、ファイルを追加するたびに書庫ファイル全体を
書き直さないといけなくなるよ。
末尾にあれば追加された分と中央ディレクトリ分だけで済む。

インデックスは末尾が当然だな。もしくはシーケンシャルアクセスで良いならTARのようにする。

圧縮と暗号化を両方行いたい場合
先に暗号化してから圧縮すると
圧縮してから暗号化したときに比べて
サイズがかなり大きくなってしまいます
圧縮と暗号化を同時に行うアルゴリズムだと
効率は良くなるのでしょうか？

符号化と暗号化を勉強しろｗ

>>1

まあアルゴリズムの話はともかく
どうして暗号化ツールには圧縮機能がなくて
圧縮ツールには暗号化機能がないのはなぜ？

君が馬鹿だからそういう疑問が出る。
>>775

一番の問題点は仕様がアホみたいに巨大かつ肥大化を続けてることだろう

モチはモチ屋的な思考する人が多いからじゃねーかと思ったが、
圧縮ソフトは暗号化機能つけてるのも結構あるよね。

圧縮するときの符号化した辞書を暗号化すれば医院で内科医

馬鹿には無理

ちょっとした思いつき
ABCCABBCA
というような並びのデータがあるとして、このままではあまり圧縮に適してないが
これを
ABC
CAB
BCA
と並べて右上から右下斜めに読むと
CBBAAACCB
となって圧縮しやすくなる
これを斜め読みアルゴリズムと名付けた

データを二次元に展開すると読み方は横読み、右下斜め読み、縦読み、左下斜め読みの4種類定義できるが
この4種類を順番に適用して圧縮を繰り返すと、可逆を維持したままファイルサイズをものすごく小さくできるかもしれない
これを回転圧縮法と名付けた

暇な人は論文でも書いてみたらお金になるかも

http://ja.wikipedia.org/wiki/%E3%83%96%E3%83%AD%E3%83%83%E3%82%AF%E3%82%BD%E3%83%BC%E3%83%88

馬鹿には無理

俺も考えたぜ！

１　はなっから元のデータを線形合同法で作る
２　シード値のみ保存

やばい　1/10000000000ぐらいいく
誰か論文作れ

それは似たようなことをIBMが専用チップを作ってやろうとしてたね

馬鹿には無理

データを最適化する手法は昔からあるわけで、恥ずかしいから馬鹿は黙っておけｗ

静止画・動画とかアプリケーションが既知の場合なら、データの統計的性質分かってるわけだから、予め超巨大な辞書を作ってみんなで共有しておけば、めっちゃ圧縮できそうな気がするんだけど。
なんで未だに離散コサイン変換＋ベクトル量子化で頑張ってるの？

詳しい人おしえて！

それってさ、「ここのURLにデータがあるよ」ってアドレス渡す事と同義なんだよ
データ自体が小さくなるわけじゃないんだ

量子テレポーテーションをうまく応用すれば圧縮に使えるのではないか。

>>791
データ自体が小さくなるってことじゃね？
画像の元サイズＸ、圧縮後のサイズＹ、枚数Ｎ、辞書のサイズＺとすると

N*X > N*Y + Z

になってれば圧縮できてるよね。
Ｎがでかけりゃでかいほど、辞書でかくしてもいいじゃん。
１Ｇ

研究発明にはこういう馬鹿も必要だ

しかも、辞書分のＺを全員が共有できてるという前提であれば、

N*X > N*Y

って、すごい圧縮できそうやん！
コサイン基底なんか使わずに、１0ＧByte分くらいの過剰な基底を用意しとけば、画像なんか超小さくなるべ！

>>790
別に頑張ってないよ。
もっと先の技術はちゃんとあるが、馬鹿は知らなくていいよ。

ハッシュ値(またはそれに類するもの)で元のデータを引っ張って来れる仕組みを圧縮と見なすなら、
ファイル共有ソフトは一種の圧縮であり、winnyなりshareなり、既にある。

>>795
ならないよ。
JPEGエンコーダなんて一日もあれば作れるから、本当にそう思うなら作って実験してみようよ。
そうすることで自分の愚かな間違いにちゃんと気が付けるよ。

昔、「ハノイ圧縮」ってネタがあったけど、これって辞典型の究極と言える。
ところが、このハノイ圧縮で、世界中のデータを圧縮していくと、
たちまち圧縮できなくなっていき、かえってサイズが増えることになる。

ちょっと試算してみるとわかるけど、
データ圧縮が圧縮となる世界って、非常に狭いんだよね。
ハノイ圧縮で圧縮できている範囲だけ利用するとしても、
結局それは、現在の他のデータ圧縮法よりは多少マシかなぁ程度。

ハノイ圧縮とLZ78を比べると面白いかもしれない、程度。

>>796


圧縮アルゴリズム構築時に既知のデータと、圧縮時に未知のデータと分けて考える必要があるね。
ちなみに非可逆ね。

アルゴリズム構築時にハッシュテーブル作っておいて、様々な未知データに対してハッシュ値計算してハッシュテーブルを引く。
ハッシュテーブルにハッシュ値がなかったら、圧縮画像＝真っ黒画⇒像残差デカイってこと。
残差小さくしつつ圧縮率上げるんだから、非可逆の圧縮アルゴリズム考えてる人たちは、この間を責めてるわけだよな。

COS関数という既知の基底以外でも、ウェーブレットみたいに基底も学習しておけば、圧縮率上がるケースも当然あるだろうね。

ちなみに、8x8の画像だったら64次元の基底があれば、任意の画像を線形和で表せるけど、
基底を10000万個用意しておいても良いわけだ。
圧縮したい画像の枚数が多ければ、10000万個基底用意しておいたとしても、勝てる場合がありそう。

>>800
ちなみに、10000次元の係数の大半がゼロになるように、L1正則化でもかけて、基底学習できればよさげだな。馬鹿馬鹿いってるやついるけど、血の巡り悪そうだな。

>>797
隣り合うピクセルの色が近いからCOSで基底変換すると、高周波数成分が0になっるって気付いた奴がいるわけだよね。
そいつは、何枚かの画像（学習データ）を観察して、それに気付いたわけだ。
そして、未知の画像に対しても、同様の統計的性質があるに違いないと思った。これが暗にあるわけだな。


>>796
ちゃんと辞書のサイズZって書いてあるだろ。
ハッシュの先に格納されてるデータがあって、そこのサイズも考慮すれば、それって圧縮できてないよね。

このデータがこのシステムでこれだけのサイズになりましたっていう実測値だしてくれよ

WikipediaデータすべてがLinuxで1MBになった。

話にならんな

>>805
bzip2を知らんのか。

話にならんって言ってんだ
流れを読めよ

>>807
お前Linuxのインストールで躓いたくちだろ。

流れが読めない…

今のLinuxのインストールにどうやって躓く要素があるんだ？

Linuxができないのに圧縮を語るとは世も末。

LHA、ZIP、GZIPをはじめとする圧縮ユーティリティーの大部分はLinuxで開発された。
まずLinuxの勉強からやり直せ。

Linuxは俺が教えた

これからはLinuxの時代

>>812
えっ

>>786の要望に応えられる圧縮をLinuxで作ってくれよ。

>>815
お前は圧縮ユーティリティーがCUIとして作られたことも知らないのか。

bzip2を知らんのか。

馬鹿には無理

CUI=Linuxだ(ｷﾘｯ)

>>816
それは車輪の再発明と言って優秀なリソースを分散させる結果となる。

できないんならひっこんでろ。

>>822
bzip2を知らんのか。

できてないじゃん。

最近ム板に変なのが住み着いて、ほとんどのスレが機能しなくなってるのは
なにか対策を考えて欲しい。
もう2chでは無理かね。

>>817
＞LHAは、奥村晴彦が開発したアルゴリズムをもとに、吉崎栄泰がMS-DOS向けに開発したもので、1988年にパソコン通信で初公開された。
ttp://ja.wikipedia.org/wiki/LHA

フォントですか？

>>800
だから、やってみろよ。自分が馬鹿だったってわかるから。

>>802
全然違うよ。
JPEGのエンコーダを書いたこともなく、ろくに理解もしないで何言っているの？
統計的性質なんて関係ないから。

＞ちゃんと辞書のサイズZって書いてあるだろ。

共有しているなら、辞書がネットワーク上にあったっていいだろ。
ローカルストレージに限定する理由はない。

＞ハッシュの先に格納されてるデータがあって、そこのサイズも考慮すれば、それって圧縮できてないよね。

本当に馬鹿だな。
ネットワーク全体で冗長度が下がっていれば、それは圧縮と同じなんだよ。
ハッシュは、辞書の符号化に相当する。

>>829

>統計的性質なんて関係ないから。
JPEGエンコーダってDCTしてハフマン符号化じゃねーのかよ。
統計的性質使って圧縮してんだろ、馬鹿か？
全然違うって、何が違うか指摘しろよ。議論の基本を知らないのか？

>共有しているなら、辞書がネットワーク上にあったっていいだろ。
>ネットワーク全体で冗長度が下がっていれば、それは圧縮と同じなんだよ。
ならハッシュ値計算してデータをひっぱってくるシステムも、圧縮できているわけだな。
今現在ある全ての画像を一箇所に溜めて、未来に撮影される画像もそこに含まれていれば、圧縮できていると言えるだろうな。
とりあえず、学習データで圧縮アルゴリズム作って、検証用のデータで精度を測るって、基本は理解してるか？

↑
こいつ最高にアホ(AAry

とりあえず、ハッシュマップの話は飽きたよ。
100枚画像があって、20枚重複してて、実質80枚分のデータだったら、サイズ0.8倍になるのね。

DCTとハッシュマップの間を責めれば圧縮率あがるだろってことでしょ？

>>830
初心者はWindowsでも使ってろ。

>>830
＞JPEGエンコーダってDCTしてハフマン符号化じゃねーのかよ。

そうだよ。で、君はJPEGエンコーダぐらい書いたことあるんだよね？
俺はちゃんと0から自作したことあるよ。

＞統計的性質使って圧縮してんだろ、馬鹿か？

どこが？
DCTは統計とは関係がないし、ハフマン符号は対象データの中での出現頻度であって、
先の様々な画像の統計的性質とは無関係だよ。
量子化テーブルをどういうものにするかは、ある統計的な性質と関係あるが、
それは画像の統計的性質じゃなくて、人間が見たときに許容できる誤差としての統計的性質。

＞全然違うって、何が違うか指摘しろよ。議論の基本を知らないのか？

こんな枯れた技術は議論する価値もないだろ。
調べればわかるし、わからないような馬鹿や、調べることもできないような馬鹿はここに来るな。

最低限、自分のアイデアを自作してみてからここに来い。
その上で、わからないことがあれば、俺様が教えてやる。

webp っていいの？
持ってる jpeg ファイル全部 webp 化して
元の画像捨てても平気？

>>835
お前が今後使うブラウザやビュアが対応しているならいいんじゃね
可逆モードもあるしな。

>>834
＞DCTは統計とは関係がないし、ハフマン符号は対象データの中での出現頻度であって、
＞先の様々な画像の統計的性質とは無関係だよ。
ん？関係あるよね？
なんでDCTで直行変換かますと、多くの軸の係数が0になるの？
近くのピクセルの色が似てるからだよね。
こーいうのを、人は統計的性質と呼ぶのでは？

＞それは画像の統計的性質じゃなくて、人間が見たときに許容できる誤差としての統計的性質。
人の見が感じる違いと2乗誤差は違うから、そこを責めてる話もあるけど。
そこに拘らなければ、まぁ2乗誤差だろうな。
DCT後の軸の係数が小さいところを0に打ち切るだけ。

上の議論は、COS以外の基底を使って、より少ない非ゼロの軸で、2乗誤差を小さくすることが出来ないかって話じゃね？
後ろのハフマン符号化には触れてない。

>>837
まず、答えろよ。
君はJPEGエンコーダぐらい書いたことあるの？ないの？どっち？
お前のレベルに合わせて教えてあげるから。

>>837
＞なんでDCTで直行変換かますと、多くの軸の係数が0になるの？

ならないよ。

＞DCT後の軸の係数が小さいところを0に打ち切るだけ。

違うよ。

量子化テーブルをなんで使うのかわかってる？

>>839

0になるというか、係数が小さくなるってことな。
それで量子化テーブルの数値がきまってんだろ。馬鹿か？

>>840
小さくならないよ。小さくするために量子化テーブルを使うの。
馬鹿なことを書いて恥をかく前に、JPEGエンコーダぐらい自作しろよ。
基本部分は一日あればできるし、理解も深まるから、こんなスレに書き込んでいるよりずっといいぞ。

それができないような馬鹿なら、この世界に首を突っ込まない方がいい。

>>841
http://ja.wikipedia.org/wiki/%E9%9B%A2%E6%95%A3%E3%82%B3%E3%82%B5%E3%82%A4%E3%83%B3%E5%A4%89%E6%8F%9B
ほら、Wikipediaにのってるよ。
右の画像のDCTみてね！

さらにいうと、どんな画像食わせても、高周波数成分は小さくなる。
この大きさに合わせて量子化テーブルの値が決まってるわけだな。

おまえ、作ったことあんじゃねーの？理解せずにコード書き写しただけ？

>>842
だから何？実際の数値見たことないの？
量子化テーブルが周波数によって数値が違う意味わかってる？

>>843
＞この大きさに合わせて量子化テーブルの値が決まってるわけだな。

違うよ。
実際には、高周波成分に大きな値が来ることが多々ある。
低周波の値より、高周波の値の方が無視できるから、量子化テーブルの係数が大きくなるの。
低周波は数値が小さくても無視しない方がいいから、テーブルの係数が小さい。

>>844
大体、低周波数が大きくならないなら、DCTする意味ねーだろ。
ひとつおりこうさんになったな。

>>845
そう。
多々ある。その頻度と、各基底が人の目に影響を与える比率で、係数が決まっている。

>>843
作ったことあるも何も、仕事でやってて、それで飯食っている。

>>846
＞大体、低周波数が大きくならないなら、DCTする意味ねーだろ。

JPEGにおいてDCTは高周波成分と低周波成分を分ける意味しかない。
つまり、どの情報を捨てるかというフィルタ(後段の量子化テーブル)を使って、圧縮率を上げている。
(他にも色情報を落とすとかもあるが)
変換誤差があるものの、DCT自体はnear可逆変換なので、それだけでは圧縮にならない。

>>849
そんなはずはない。
色んなソフトで使われてる係数は、「頻度の逆数ｘ視覚への影響」で決まってるはずだぞ。
つまり、基底組み替えた結果、スペクトルに偏りがあるってのは重要なんだよ。

どっかに、量子化係数の決め方の解説があったが、見つからんな。

この話って、そもそも基本なはずだが。

つーか仕事でやってんのに、こーいうの理解してないの？
流石に周波数分離するだけってのはないだろ。
音の圧縮だって同じじゃん。

>>850
＞色んなソフトで使われてる係数は、「頻度の逆数ｘ視覚への影響」で決まってるはずだぞ。

頻度じゃなくて、重要度で決まっている。
高周波成分は頻度があっても、基本的には重要ではない。

それこそ量子化テーブルは、画像単位で変えれるが、
ある画像ので低周波成分の頻度やDCT後の数値が低いからと言って、
量子化テーブルの値を大きくできるわけじゃないぞ。
そんなことをしたら悲惨な画像になる。

＞つまり、基底組み替えた結果、スペクトルに偏りがあるってのは重要なんだよ。

高周波成分を捨てるために、分けることが重要なだけ。

>>851
JPEGは周波数分離のためにDCTを使っているの。

で、元の問題である、
>>795
＞コサイン基底なんか使わずに、１0ＧByte分くらいの過剰な基底を用意しとけば、画像なんか超小さくなるべ！

だが、なんでそうなるんだ？

数値として存在しうる全パターンの基底を用意しても圧縮なんてできんぞ。
どうやるの？

DCTも変換しただけでは圧縮なんてできないのに。

>>852
重要度ってどうやって決めてんの？

>>854
存在しうる全パターンの基底を用意する意味がよく分からんが。

8x8の各ブロックを、常に3個の基底のみの線形和で十分表現できれば、それだけで3/64になる。

>>855
だから、頻度でその重要度が決まってんだろ。
人間の目は、たまにしか出現しないものには鈍感になってんだよ。

>>855
ぶっちゃけ好みの問題。
文字、アニメ絵、写真、CGで、それぞれ変えた方が良い感じになるが、
ほとんどの実装系があんまり気にしないで一般的数値を利用している。
真剣に設定しているのはフォトショップぐらい。

そもそも今時JPEGなんて糞フォーマット、議論する価値もないぞ。

>>856
＞8x8の各ブロックを、常に3個の基底のみの線形和で十分表現できれば、それだけで3/64になる。

馬鹿か。できるわけないだろ。

>>859
だから、何故できるわけないのか、理由を答えろよ。

>>860
何故できないのか、わからないから教えて欲しいのか？
それなら口のきき方を改めろよ。

>>861
いいから説明してみ？

>>858
あと、これも回答になってない。
量子化係数の逆数と、スペクトル比較してみろよ。

>>862
＞いいから説明してみ？

尊大な馬鹿に説明してやる義理はないな。

＞量子化係数の逆数と、スペクトル比較してみろよ。

そんなものは画像による。
「DCT後の数値が高い＝重要」ではないの。
平坦な画像では、低周波成分に集中するのと、低周波成分が重要だから
DCT後の数値が高いところと、量子化係数が低いところが、たまたま一致する傾向があるだけ。

DCT後の数値は、大きくても、小さくても、低周波なら重要なんだよ。
数値の大きさで、重要度(量子化テーブルの値)が決まるわけじゃない。
大きいなら大きいなり、小さいなら小さいなりに、「解像度」が必要。

ここまでおれのじえん

なんかスレのびてんな。

両者同じこと言ってねーか？

ま、頭でっかちな子は一度手を動かしてみるといいよ。
そしたら、案外、この2人も仲良くなったりしてな。

基底を3つ用意して線形和とか言ってるのを除けば、
既存の概念以上の何かを語っているに過ぎないような。

基底の話は、なんだかなぁ
DCTでやるかwaveletでやるかの違いよりもどうでもいい。

ドザはDCTすら理解できていないことが分かった。
やっぱりLinuxerの方が優秀。

　　　　　　　　　　　　／ 　＼_＿＿＿
　　　　　　　　　　　　 ⌒ﾞｉ＼　＼ 　　　＼
　　　　　　　　　　　　　　. ﾞｉ ＼　ﾞｉ(ﾟ)　　 ﾞｉ 　　　　____＼ 　　ー‐┐ 　一十一
　　　　　　　　　　　　 。., ' ⌒｡ﾞｉ　)　　　ﾞｉ 　　　　　＼　 　　　　ﾉ´　 　ノ |
　　　　　　　　　　　　ｏ｡∴｡ﾟ／／ 　┬-､_　　　　　　＼ 　　 ー‐┐
　　　　　　　　　　　(∴Ｕ／／　　}ﾉ ﾉ　　 ＼　　　　　　,>　　　ﾉ´　　　─┬─
　　　　　　　 　　　　|Ｕﾞ/　　　　　／ i | 　 　 l、 　 　 く.　　　ー‐┐　　　 |
ー‐┐　一十一　/　　u'　＼ヽ‐'´　　!|　 　　 ﾄ､　 　　 ＼ 　　,ﾉ´　 　 ─┴─
　ﾉ´　 　ノ |　　/_____, 　}j 　ハ､ 　ヽ ヽ,＿＿_/　　　　／ 　ー‐┐　　─┬─
ー‐┐　 　　. 　 　 ／　___ノ　／＼_,≧/ u 人.　　　／ 　　　 ,ﾉ´　　　─┴─
　ﾉ´　　─┬─　　く　　{上rﾝ´　 ,厶..／ ／　ヽヽ 　 ＼　　　　|｜
ー‐┐　　　|　 　　／　　 ￣ 　 ノ{こ,　／,〃　 　!|　　　 ＼ 　　･・　　 ─┬─
　ﾉ´　　─┴─　 ＼　 　　　,.ｲ　!l｀T´ | / 　 　 |:|　 　　　/　　　　　..─┴─
ー‐┐　─┬─　　　＼ 　　// 　 　l　 |　　　 　|_|　　　∠.、
　ﾉ´　　─┴─　　 　 ／ 　　ﾋ_ー--､＿|ｰ､____,ノj┘　　　 /　　　 　 　 ─┬─
ー‐┐ 　 　　　 　 ／　　　　 ＼￣＼ー`トｰ-＜　　　　／ 　 　 　 　　　.─┴─
　ﾉ´　　─┬─　 ＼　　　　　　＼　 ヽ　 ＼　　ヽ　　　￣￣|
　| |　　.─┴─　　　>　　　　　　 ＼. ヽ.　　ヽ 　 ｌ　　　　 　|／l 　 ／|　　∧　 /＼
　･・　　 　　　　　　／ 　　 　　　 　　 ）　lヽ　　 ',　 l、　　　　　　|／ 　 |　/ 　 Ｖ
　　 　 ─┬─　　＼　　　　　　 , イ､_,上ﾊ　　 } 　小　　　　　　　　　 |/
　　　　─┴─　 　 ＼ 　　 　(乙≧='''"´　,∠,__ノ/
　　　 　　　　　　　　 ／ 　　　　　　　　　　厶乙iﾌ/
　　　 　 ─┬─　　く 　　 　　　 　　　 　　 ｀¨¨¨´
　 　 　　─┴─　 　 ＼

プログラム板だろ
コード書けよ

〜〜〜〜
　↑
コード

DLLを使ってZIP圧縮をするとき
-t mmddyyyy形式で指定日付以降のファイルの圧縮を指定できますが
時間の指定はできないのでしょうか？
-t mmddyyhhmmss とか
-t yyyy-mm-dd-hh-mm-ss とか
やってみましたが、ダメでした。

DLLに聞けよ

7zip64.dllって32ビット版と何がちがうん？

>>874
64bit板として作られている。

こうなったら体に聞くしかないな

ハフマンに興味を持って、セジウィック先生の1-3巻購入したんだけど
いまひとつ分らんのです。
奥村先生の本はどんなかんじでしょうか？
まあ、購入するつもりになってるのですが、
圧縮とかハフマンとかの開設は詳しいのでしょうか？

セジウィック本も、奥村本も、原理は簡単にしか書いてない
同じ実装向けでも、「データ圧縮ハンドブック」あたりだと詳しく載っていたはず。

完全に理論からだと、情報理論の参考書がよい。
「情報源符号化」とか。

rarを作れるプログラムわどこにあるの?

>>878
ありがとー
アマで中古が10,000か・・・

　　∧＿∧
　 （　・∀・）　　　　　　　　　　　　人　ｶﾞｯ
　 （　　　　つ―-‐-‐-‐-‐-‐○ < 　>__Λ∩
　 人　Y ノ.　　　　　　　　　　　 　Ｖ｀Д´）/
　 し（＿）　　　　　　　　　　　　　　　 　　/ 　←>>127

ファイルのタイムスタンプをUTCで保存している圧縮フォーマットってないの？

Z01とかって拡張子のファイルを結合、解凍できるソフトってどんなのがありますか?

>>883
ソフトウェア板行け

>>812>>817が恥ずかしすぎるな

昨今音声認識や画像認識でニューラルネットがもてはやされてるけれど
オートエンコーダーの技術でできた優秀なコーディックってないの？

>>883
とりあえず、青木ヶ原かどこかへ行った方が良い
ここでは君のような池沼は扱っていない

おまえも東尋坊にでも行けば？

deflateの終端ってどうやって判断するの？

ブロックの先頭1ビットが、最終ブロックかどうかを指してる

そのブロックのヘッダはどう見分ければいいの？
RFC1951見てみたけど全くわからん

最初のブロックは最初の1ビット目
残りのブロックは順次復号していくしかない。

>>892
なるほど ありがとう
コード書かなきゃだめか

1000分の1くらいにまで圧縮できるソフトがあれば便利なのにな。
無謀な意見そのものなのだが。

情報量について勉強してこい、というのがマジレスかな。
THcompでググれ、というのがお約束。

出来たら出来たで、それを前提にしたクソシステムがどっと出てくるから無意味
ＣＰＵ速度や記憶媒体で何度も通った道

ディレクトリ名やファイル名にデータ埋め込んでみましたとかな

理論的に不可能なことを「出来たら出来たで」とか言うほうが無限倍無意味w

>>897
里芋とかそんな名前のソフト無かったっけ

質問です

何年か前に話題になったと思うのですが
「圧縮したらサイズが0になった」
みたいな題名で(タイトルはうろ覚え)
NTFSなどのファイルシステムで
ディレクトリ名やファイル名にデータを格納し
ファイルサイズは0にしておくと
ディスク使用容量は0のまま
とかなんとかいうアルゴリズムを
OneDriveやGoogleDriveに適用すると
やはり7GBとか15GBとかの無料枠を
超えずに使い続けることが可能でしょうか？

だれか実験したひととかサイトとかご存知ですか？

実験したこともないしサイトも知らんけど
ランダムな名前でサイズ0の大量のファイルの転送とかは
新手のサイバーテロと捉えられる可能性が高いので自分でやるのは止めとけよ

わざとやってるだろw 「里芋」と、他に適当なフレーズを加えて検索したら
当該ソフトが見つかったけど、実用的な意味は全く無い。

Unixとかでは、ディレクトリのサイズとしてファイル名とかの情報が入ったブロックが
カウントされるけど、Windowsでは0と表示されるから、というだけのお遊び。
ディスクの空き容量は同じように減っていく。

MS-DOS時代に、ディスクの空き容量が倍に見える（だけど、ファイルを作ると、
本来必要な量の倍の量が減っていく）というジョークソフトがあったけど、
そういうのの同類で、実験ないしジョーク以上の意味は無い。

>>902
＞MS-DOS時代に、ディスクの空き容量が倍に見える（だけど、ファイルを作ると、本来必要な量の倍の量が減っていく）というジョークソフト
ほしい！原理は？

原理は、セクタサイズとクラスタサイズを不整合にする....んだと思う。多分。
『近代プログラマの夕』 （単行本）p.99〜100に書いてある。ネット検索では見つからない。
一応THcompのジョークの話の次に書いてあるけど、ジョークではないはず。

★2ch勢いランキングサイトリスト★

☆ +ニュース
・ 2NN
・ 2chTimes
☆ +ニュース新着
・ 2NN新着
・ Headline BBY
・ Unker
☆ +ニュース他
・ Desktop2ch
・ 記者別一覧
☆ 全板
・ 全板縦断勢いランキング
・ スレッドランキング総合ランキング
☆ 実況込み
・ 2勢
・ READ2CH
・ i-ikioi

※ 要サイト名検索