05/06/25 22:50:29 .net
>>411
BCCで使うのになんでMS-LINKが出てくるんだ? わけ分からん
MS-LINKなら付属のLIB使えば済む話だろ
413:411
05/06/25 23:01:26 .net
>>412
ですから間違えました。BCCじゃなくてMASMです。
414:デフォルトの名無しさん
05/06/25 23:07:26 .net
ヒント: /coffオプション
415:デフォルトの名無しさん
05/06/26 01:30:55 .net
完全に特許に引っかからない技術を教えてクレイ
416:デフォルトの名無しさん
05/06/26 03:21:54 .net
>>415
特許の期限が切れたもの
417:デフォルトの名無しさん
05/06/26 07:12:59 .net
>>415
bzip2,gzip
418:デフォルトの名無しさん
05/06/26 07:29:29 .net
完全と言い切れるものは多分ないんじゃないかな。
知られてないだけで、所謂サブマリン特許の類のパテントが存在するかも知れないし。
bzip2のBWTも発案者が特許を取らないといっているだけだし。
圧縮ソフト作るのって床から刃の出ている廊下を歩くような感じだよ。
時々踏むと刃のでる罠が仕掛けてあったりして。
最初にアルゴリズムに特許を与えたバカは誰なんだろう。
419:デフォルトの名無しさん
05/06/26 10:33:39 .net
>418
アルゴリズム特許は暗号が初めてじゃないっけ
それならこれもそれならこれもとずるずる範囲が広がっていった。
暗号の場合は納得できるんだけどねー
420:デフォルトの名無しさん
05/06/26 15:19:36 .net
フラクタル圧縮もダメなんでしたっけ
421:デフォルトの名無しさん
05/06/26 17:41:04 .net
>418 >419
線形計画法のカーマーカー法じゃないの？
>カーマーカー特許とソフトウェア―数学は特許になるか 中公新書
>URLﾘﾝｸ(www.amazon.co.jp)
元々の圧縮アルゴリズムはともかく、○○＋ハッシュとかいうのになってくるとどんどん納得できなく
なっていくんだが。
422:419
05/06/26 20:43:13 .net
>421
すまんこった、カーマーカー法が最初の特許アルゴリズムだった。
ほら吹いてしまいました。ごめんさない。
423:デフォルトの名無しさん
05/07/01 09:17:37 .net
Info-ZIP社のZIP32.DLLって商用で使用するにはライセンスがいるのでしょうか？
UNZIP32はいるみたいなのですが。HP読んでもわからない･･･
424:デフォルトの名無しさん
05/07/02 03:14:07 .net
zip32.dllは知らんが、zlibならいらないはず。
425:413
05/07/02 07:57:25 .net
>>414
どの/coffですか?
mlなら/coffつけてますが?>>407
426:デフォルトの名無しさん
05/10/12 02:59:27 .net
hosyu
427:デフォルトの名無しさん
05/10/25 10:46:17 .net
質問です。
DEFLATE圧縮では元データはバイトごとに圧縮されるのですか？
それとも6ビットや5ビットなどビット単位ですか？
RFCと一緒にzlibやgzipのソースを読んでいるのですが
自分の読解力ではわかりません。
428:デフォルトの名無しさん
05/10/25 11:33:32 .net
バイト単位
429:427
05/10/25 11:37:52 .net
>>428
バイト単位ですか。ありがとうございます。
その線で読んでみます。
430:デフォルトの名無しさん
05/10/25 11:44:07 .net
ソース読んで理解できないなら>>298
431:427
05/10/25 12:56:37 .net
>>430
やっぱりその本を買った方がよさそうですね。
今から買ってきます。
432:デフォルトの名無しさん
05/10/30 11:38:36 .net
書庫が１バイト足りずに破損している場合、末尾に00を付加するという話を聞いたんですがどうやって付加するんでしょうか？
調べようと思ったんですが検索ワードが思いつかない…
433:デフォルトの名無しさん
05/10/30 14:54:09 .net
>432
君が何を聞きたいかが理解できない。
とりあえず付加するのは誰？
特定のソフトの話か、特定のファイル形式の話？
434:デフォルトの名無しさん
05/10/30 18:22:37 .net
>>433
漏れの予想では、ファイルの末尾に00を付加させるのに、
どんな関数orAPIをコールすれば良いか判らない
そういうレベルの質問だと思う
435:デフォルトの名無しさん
05/11/01 00:17:17 .net
板違いの予感。まさかnarがどうとかって話じゃないだろうな。
1 バイトのファイルを作っておいて copy /b とか cat とか、
そんなスキルもないならバイナリエディタ。
ってところだったりして。
436:デフォルトの名無しさん
05/11/01 02:01:51 .net
narってなにさ？
437:デフォルトの名無しさん
05/11/04 11:05:22 .net
もしかして null ?
438:デフォルトの名無しさん
05/11/04 11:16:46 .net
ナルほど
439:デフォルトの名無しさん
05/11/04 20:13:26 .net
>>438
誰がうま(ry
>>432, >>435
出てきて釈明しる！
440:435
05/11/04 22:15:29 .net
済まん、あっさりスルーされると思ってた。
「伺か」が使うアーカイブ(実態はzip)の拡張子。
公開終了したアーカイブをWebArchiveから拾ってくるって話。
まあ、オタネタだ。
441:435
05/11/04 22:26:30 .net
補足。
WevArchiveにはファイル末尾の0を切り捨ててしまうというバグ(?)がある。
そのためせっかく昔のアーカイブを見つけてもzipが解凍できないことがある。
末尾に0を付加してやると正常に解凍できるようになる。
というのがこちらで想定した問題のバックグラウンド。
442:432
05/11/04 22:31:07 .net
自己解決したから書き込まなかったんだけど、WebArchiveのzipファイルで～て事が聞きたかった。
narは良く分からなかったけど、435が書いてくれたからまぁ良いかと思ってた
オレのせいで微妙な話が続いて悪かったです
443:デフォルトの名無しさん
05/11/12 12:52:07 .net
zlibの使い方を詳しく丁寧に説明してる日本語サイトを教えてください。
あと、gzip（と可能ならzipも）の中のファイル名を解凍せずに知りたいんですが、できませんか？
444:デフォルトの名無しさん
05/11/12 18:30:27 .net
zlib.hの英語を読むのが一番確実だと思うけど。
別に読みにくくは無いし、そんなに長くもないし。
gzio.cも。
445:デフォルトの名無しさん
05/11/17 22:59:07 .net
>>443
ヘッダにテキストで書いてあるけど。
446:デフォルトの名無しさん
05/11/17 23:36:52 .net
>>445
日本語って言ってるだろうが、馬鹿
447:デフォルトの名無しさん
05/11/18 00:43:37 .net
日本語なかったっけ？ どっかでzlib.hのコメント日本語訳みたことがあるんだけどどこだったか…
448:デフォルトの名無しさん
05/11/18 15:11:28 .net
>>446
日本語読めないのに日本語要求してたんですね。
# 単に駄々をこねてみたかっただけかな? :-P
449:443
05/11/18 23:21:09 .net
ありがとうございました。
日本語訳はこれですね。
URLﾘﾝｸ(www.sra.co.jp)
450:デフォルトの名無しさん
05/12/25 22:34:49 .net
zlib の deflate を利用して
自前でzipファイルを作るプログラムを作ろうと思います。
とりあえず、ここの仕様書を見たのですが、
URLﾘﾝｸ(www.pkware.com)
extra fieldの意味がよくわからないです。
私の場合は、この部分は出力しなくて良いのでしょうか？
451:デフォルトの名無しさん
05/12/26 16:51:16 .net
あげます
452:デフォルトの名無しさん
05/12/26 23:35:03 .net
遠慮なく頂きます
453:デフォルトの名無しさん
06/02/09 06:24:45 .net
前スレ
圧縮アルゴリズム考えたんですが
ｽﾚﾘﾝｸ(tech板)
テンプレは >>1-3 あたりには無い。
454:デフォルトの名無しさん
06/02/10 23:16:40 .net
乗っ取るの？
455:デフォルトの名無しさん
06/02/26 18:38:09 .net
圧縮アルゴリズム2
ｽﾚﾘﾝｸ(tech板)
456:デフォルトの名無しさん
06/02/27 10:56:10 .net
圧縮アルゴリズム考えたんですが
まずデータの中にフラグの立ったビットがいくつか数えます。
そしてデータは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バイト悔いました。
Ｃ(コンビネーション)て恐ろしいな
457:デフォルトの名無しさん
06/02/28 00:49:54 .net
俺を圧縮してみろ！！
458:デフォルトの名無しさん
06/02/28 09:12:37 .net
>>456
Lynch-Davisson 符号とか数え上げ符号を調べてみて
459:デフォルトの名無しさん
06/02/28 10:27:28 .net
圧縮にはならないって事か？調べたけどあまり無くて分からなかった
460:デフォルトの名無しさん
06/02/28 16:19:05 .net
10年くらい前、bzip で使われている
ブロックソートが何故圧縮にいいのか証明されていない、
と聞いた気がするんだけど、今はもう証明されているの？
461:蕪木ら某 ◆Googl8RmwA
06/03/01 03:29:22 .net
( >>460 URLﾘﾝｸ(www.google.com) )
462:デフォルトの名無しさん
06/03/01 03:52:31 .net
>>460
有村 とか Effros の論文読んでみて
463:デフォルトの名無しさん
06/03/01 04:02:46 .net
>>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記号あたりエントロピーまで漸近的に圧縮可能
464:デフォルトの名無しさん
06/03/01 14:26:02 .net
>>463ごめん後半からわかんなかった…
ところでJAVAでLZWとLZ77とHUFFMANとDEFLATEを説明サイト見ながら自分なりの解釈で作ったんだけど
76Kbのビットマップをデフレで圧縮したら44Kbになったのね。
で、7zのZIPで圧縮したら37Kbになったのよ。
これって何がいけないの？Lhacaも7zより圧縮率悪いけど
どういう工夫すれば縮むようになるん？
教えてエロい人！
465:デフォルトの名無しさん
06/03/02 18:09:48 .net
AGE
466:デフォルトの名無しさん
06/03/02 23:20:46 .net
ハフマン圧縮について教えてください。
よくあるのは、出現率の低いものを２個取り出して、その和をつくり、さらに残ったなかから一番出現率が小さいものをとりだし、
これと、先ほどの和の結果との和をとり・・・
という説明です。
でもなんか要するに出現数のおおい順にソートして（出現ゼロ回のものは無視する）
A,D,B,C,・・・みたいに配列に入れます。
そして順に、1,10,110,1110,11110・・・
と符号をふればいいだけのように思えてしまいます。
なぜ小さいものを取り出して和を作り、さらに小さいのと和をつくり・・みたいなことをする必要があるのでしょうか？
467:デフォルトの名無しさん
06/03/02 23:35:09 .net
最初俺もそう思ったけど、ちょっと考えたらそれじゃ意味ないことに気づいたんだよ
なんでかって？忘れたなぁ…
468:デフォルトの名無しさん
06/03/03 00:01:40 .net
>>466
それは unary 符号（単進符号、一進符号）というもの
符号が最適になるには条件というものがあって、
unary の場合、記号の出現確率が 1/2, 1/4, 1/8, ... となる場合にのみ最適な符号を構成できる
一方、Huffmanはどんな出現確率の記号群に対してでも最適な符号を構成できる
469:466
06/03/03 00:41:32 .net
なるほど。よくわからないけど間違っていたことだけはわかりましたｗ
ありがとうございます！！！！！！！！！
470:デフォルトの名無しさん
06/03/04 00:41:35 .net
JAVAでLZWとLZ77とHUFFMANとDEFLATEを説明サイト
教えてくれ俺もみたい
471:デフォルトの名無しさん
06/03/04 10:02:12 .net
データ圧縮法概説
というところ。その名の通り原理や概念を解説しているだけでJAVAどころか
プログラミングにすらふれていない。
でも説明は分かりやすいからJAVAでも作れた。
472:デフォルトの名無しさん
06/03/04 21:26:39 .net
データ圧縮法概説
ないよ
どうすればいいの？
473:デフォルトの名無しさん
06/03/04 21:37:29 .net
Internet Archive
474:デフォルトの名無しさん
06/03/04 21:39:06 .net
つーか、ちょっとリンクを追いかけていけば生きてるサイトにたどり着いたぞ
475:デフォルトの名無しさん
06/03/04 21:54:37 .net
どうやっておいかけるの？
476:デフォルトの名無しさん
06/03/04 23:53:49 .net
我楽多頓陳館で検索。
管理人は一人で何役もこなすアニメ好きの54歳
世露死苦!!
477:デフォルトの名無しさん
06/03/05 14:04:16 .net
見つかった？
478:デフォルトの名無しさん
06/03/05 19:46:29 .net
今zip圧縮のサンプル作ってる
479:デフォルトの名無しさん
06/03/05 20:51:59 .net
それはzlibとか使って？それとも圧縮部も自作？
自作だったら性能を上げる工夫とか教えてほしいです。
480:デフォルトの名無しさん
06/03/06 00:58:20 .net
圧縮部分も自作です。組み込みに乗せるから
パフォーマンスそこそこでだいたい2kから10ｋいないの
zlibを作成しようとしてます。なので性能よりもマシン語
の吐かせた内容をコンパクトにすることに命をかけています。
私も工夫とかよく解らない部分が多いため、IEEEの論文などをいくつか入手し
勉強をしているところです。アルゴリズム的に速度を上げる方法と
コーディングレベルで最適化する方法2つの視点で最適化について
考えていますがまだ道のりは厳しいです
481:デフォルトの名無しさん
06/03/06 01:23:44 .net
特許まわりはどうなのかしら?
482:デフォルトの名無しさん
06/03/06 13:05:55 .net
現在猿でも分かるC言語講座をみながらJAVAでブロックソートとMTFとレンジコード制作二日目。
Cはよく分からんがブロックソートの符号化とMTFの符号化･復号化が完成
ブロックソートの復号がうまく行かない…
483:デフォルトの名無しさん
06/03/07 01:43:41 .net
Huffman圧縮で質問です。
記号が一回しか登場せず、２分木が１つも作成できないような場合、
その記号にはどんな符号を割り当てるのですか？
484:デフォルトの名無しさん
06/03/07 06:59:12 .net
多分最初に出現する記号の種類の数もカウントしてるんだろ？
俺はその値が1になる場合は2にしてもう一文字あると仮定して
やってる。その文字は何でもいいが大抵は0x0だな
485:デフォルトの名無しさん
06/03/07 08:28:48 .net
>>483
「記号が1種類しかない」フラグを作って、記号を記録しとく。
「記号がいくつ現れたか」も記録しとけば、記号は全部空ビット列に変換で良い。
486:デフォルトの名無しさん
06/03/07 21:31:22 .net
ありがとうございます。
>>484
なるほど。それならアルゴリズムに大幅な変更はいらないですね。
>>485
そうですね。Huffmanにこだわらずにってことですね。
今からどっちにするか迷います。ありがとうございました。
487:デフォルトの名無しさん
06/03/08 00:50:18 .net
動的ハフマンって実装自体は特許事項に
抵触技術内容含まれてないですよね？
488:デフォルトの名無しさん
06/03/08 07:25:58 .net
大丈夫でしょ。やり方にもよるかもしれないけど、まあ普通に作れば無問題
489:デフォルトの名無しさん
06/03/08 22:54:08 .net
動画配信のMPEG４とかH264ってのは適合型ハフマンで送るのですか？
もしそうならパケロスしても大丈夫な理由を教えてください。
490:デフォルトの名無しさん
06/03/14 19:13:07 .net
やっとJAVAでブロックソートとMTFとRLE7とレンジ圧縮(圧縮だけ)
ができた。でもサイトにあるほどの圧縮率が出ないwwwww
なんで…orz
491:デフォルトの名無しさん
06/03/14 19:38:26 .net
>>490
どこのサイトかしらないけど、結果だけ載せている場合は、かなり細かいチューニングや、
アルゴリズム改良が加えられていることが多い。
ソース・実行プログラムもあるなら、圧縮結果をバイナリ比較するとか、
サイトのプログラムによる出力を自作プログラムで展開させてみるとか（あるいはその逆）、
圧縮結果のバイナリそのものの解析をしてみたらどうだろう。
492:デフォルトの名無しさん
06/03/14 21:50:38 .net
猿でも分かるプログラミング講座とかいうとこだったはず
Cのソースがあったから移植してみたブロックソートは間違いないからなぁ…
まあいろいろ結果を調べてみる
493:デフォルトの名無しさん
06/03/15 12:29:54 .net
>>492
Cのソースプログラムが公開されているので、
1ステップずつ動作を追っていけばいいのではないか
途中の変数の状態を確認したり、演算結果に差異がないかを調べたり
494:デフォルトの名無しさん
06/03/15 19:31:53 .net
いい忘れてたけどCのコンパイラとか持ってないんだ。
落とさなきゃだめかな？
495:デフォルトの名無しさん
06/03/15 22:51:59 .net
今や、GCCコンパイラだけでなくMSコンパイラも無料。
「資金がない」で逃げる行為はもはや言い訳にならなくなった。
496:デフォルトの名無しさん
06/03/16 07:09:38 .net
重いの入れたくない。はあり？
497:デフォルトの名無しさん
06/03/16 15:00:59 .net
なし、軽いの入れればいい
498:デフォルトの名無しさん
06/03/16 16:44:24 .net
sumという38000byte位のファイルを圧縮した結果250byte位劣って13Kb程になった。
実はヘッダなどの付加のしかたが微妙に違うのだがそれだけで
こんなに差が出るもんかな？ちなみに
BlockSort->MTF->ZLE+RLE7->RCA
って感じで4段階で圧縮してます。ヘッダ情報はどれもこっちの方が少ないのに…
499:デフォルトの名無しさん
06/03/16 19:09:09 .net
>>498
アルゴリズムや定数も同じで、各段階でのヘッダも小さいのに
出来上がりファイルが大きいのなら何かバグってるんでしょうね。
500:デフォルトの名無しさん
06/03/16 21:24:35 .net
>>499え!?マジで？℃チクショウーーーーーーーーー!!!!!
501:デフォルトの名無しさん
06/03/18 08:49:04 .net
困憊羅が雨後かねぇwwwwwwwww!!!!!!
502:デフォルトの名無しさん
06/03/18 11:09:59 .net
2chの圧縮ダットを解凍するにあたって資料が欲しいのですが、どこか頼みます。
503:http://www.vector.co.jp/soft/win95/util/se072729.html
06/03/18 18:35:48 .net
TextSS の64bit化おながいします
もしくは64bitにネイティブ対応した置換ソフトないですか？
504:デフォルトの名無しさん
06/03/19 19:48:35 .net
新しい圧縮アルゴリズム考えようぜ!!
505:デフォルトの名無しさん
06/03/19 20:22:48 .net
>>504は>>1も読めないのか
506:デフォルトの名無しさん
06/03/19 20:51:34 .net
だってアルゴリズムスレ無いしここの再利用で十分だろ？
2chの無駄も減って一石二鳥だね
507:デフォルトの名無しさん
06/03/19 23:20:14 .net
昨日、カミさんに怒られてrar圧縮されたさ
めっちゃ苦しかった
508:デフォルトの名無しさん
06/03/20 08:55:07 .net
KWSK!!!!
509:デフォルトの名無しさん
06/03/20 22:28:21 .net
へいっ!!!ついにやったぜ
JAVAにブロックソートとMTFとZLE7と適応型RANGEを移植完了!!ながかった～
圧縮率は7z>BZIP2≒俺の>ZIPという感じ
これからは圧縮されたデータをさらに圧縮できるようにする変換でも考えるﾉｼ
510:デフォルトの名無しさん
06/03/28 22:15:14 .net
ZIP圧縮について質問です。
zip32.dllに圧縮したいフォルダパスを-rオプションで渡した場合
zip内に格納されたファイルがドライブTOPからのフルパスで格納されてしまいます。
指定したフォルダ以下のみを格納するにはどうすれば、よいのでしょうか？
511:デフォルトの名無しさん
06/03/29 01:03:46 .net
SetCurrentDirectoryしてから、相対パスで指定すればいいんじゃね？
512:510
06/03/29 02:44:16 .net
511>
無事にできました(^-^;
ありがとう
513:デフォルトの名無しさん
06/04/22 06:43:41 .net
正確には圧縮アーカイブではないですが、ISOイメージファイルのフォーマットが書いてある場所を探しているのですが、いいのはないですか？ とりあえず日本語のは見つかりませんでした。イメージファイルでないISO-9660自体の解説はあるのですが・・・
514:デフォルトの名無しさん
06/04/23 19:25:43 .net
商用フリーな圧縮解凍ライブラリってありません？
利用はWindowsです。
515:デフォルトの名無しさん
06/04/23 21:59:31 .net
URLﾘﾝｸ(cise.edu.mie-u.ac.jp)
ここのサンプルcomptest.cで解凍しようとしても、エラー起こして解凍できないんだが、できます？
516:515
06/04/24 11:44:22 .net
これで圧縮したのはこれで解凍できるな。
しかし、他で圧縮したのはこれで解凍できないし、これで圧縮したのは他で解凍できない。
ヘッダー？ ヘッダーの処理はzlibはしてくれないんですか？ 初期化時にヘッダー付きを渡すとポインターとカウンターが変わるかもしれないと説明には書いてあるが、実際変わらない。
517:デフォルトの名無しさん
06/04/25 00:08:09 .net
zlibはdeflate処理をしてくれるだけでZIPファイルフォーマットの解釈はやりませんよ。
その辺は自作汁。
この辺の本を読んでみるとよし…と思う
URLﾘﾝｸ(www.amazon.co.jp)
518:デフォルトの名無しさん
06/04/27 18:33:29 .net
zlibを使ってデータの伸張をやろうとしてて
byte *src // 圧縮されたデータ
int len // src の長さ
byte *dst // 解凍されたデータの格納先
dst = malloc(5 * len * sizeof(src));
decompress(dst, src, len); // src を展開して dst に格納
// 適当な処理
free(dst);
みたいなことをやろうかなと考えているんですが、dstで確保したメモリが足りなかったときのことを
考えるとこれじゃあマズいでしょうし、あらかじめ必要なメモリの計算は解凍処理をしないと
分からないようだしでちょっと困っています。
皆さんならどうしますか？
519:デフォルトの名無しさん
06/04/27 21:25:40 .net
圧縮も自前なら圧縮データとは別に（先頭につけるとかして）、
圧縮前のデータのサイズも持っておく。
520:デフォルトの名無しさん
06/04/27 22:28:48 .net
ちなみにsizeof(src)は4バイトだろ。
521:デフォルトの名無しさん
06/04/29 06:05:34 .net
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])が欠けている場合はそれがファイル内容にかかっていても途中までですがデコードできるようです。
522:デフォルトの名無しさん
06/05/04 15:17:36 .net
>513
普通の ISO イメージファイルだったら ISO-9660 に書かれている内容がそのまま直列で入っているだけだと思うが。
523:デフォルトの名無しさん
06/05/04 22:41:50 .net
圧縮する前に圧縮後のファイルサイズのおおよその見当をつけるプログラムを
書こうと思ったんだけど、(ファイルサイズ) x (情報エントロピー) で計算すると
全然いけてないですか？
524:デフォルトの名無しさん
06/05/05 00:07:25 .net
>>523
圧縮につかうモデルでのエントロピーでないとまともな数字が出ない。
ある程度でも結局圧縮するのと同じになってしまうのであまりいけてない。
まあ、とりあえずモデルを特定しないでHuffman,算術符号,RangeEncoderなどの
エントロピーを出しておけば最低保証値だけは出せるかな。
525:デフォルトの名無しさん
06/05/05 00:21:23 .net
> 最低保証値
=元のファイルサイズ
526:デフォルトの名無しさん
06/05/05 14:18:48 .net
ただ、圧縮アルゴリズムと対象データによってはサイズが増えることもありうる希ガス
もちろんその場合は圧縮しなければ元のサイズなんで圧縮しなければいいんだけど
「元のサイズ分あれば十分だろー」ってメモリ確保してやってみらたオーバーフローとか
かっこわるいことになることがあるかもしれない…？
527:デフォルトの名無しさん
06/05/05 15:17:36 .net
>>526
そういうときは、1回の処理で増えうる容量分だけ余分に確保しておけばよい
その見積もりができないとか、1回で無限増殖しうるとか、そういうのはしらね
アルゴリズムを見直すか、出力方法を考え直すべきだがな
528:デフォルトの名無しさん
06/05/05 21:42:11 .net
UDPのパケット（1K～3K)を圧縮して転送、
受信して展開して、通信をやりたいと思ってます。
流すデータは未圧縮の画像データを分断して送受信します。
LZOのような、圧縮・展開の速いプログラムってないでしょうか？
529:デフォルトの名無しさん
06/05/06 00:10:44 .net
>>528
LZOではだめなのかい？
Huffmanあたりをまず試してみて、圧縮率・速度の検討をしてみてはどうか
530:デフォルトの名無しさん
06/05/06 09:04:06 .net
>>529
GPLなので困ってます・・・
＞Huffman
なるほど、試してみます。
531:デフォルトの名無しさん
06/05/10 20:46:46 .net
LZMA SDKを落としてJavaのソースを動かしてみたところ、
コンパイルは何とか通ったのですが実行できません。
ファイルの初期配置も何だか変な気がするのですが…。
これ、何か不具合でしょうか？
それとも私が何かの設定間違ったのでしょうか？
誰かわかる人いたら教えてください。
てか、やっぱりこういう用途でJavaって邪道なんですかね。
扱ってるサイトも見ません。
532:デフォルトの名無しさん
06/05/13 00:35:47 .net
>>531
こういう用途ってどんな用途だよ
533:デフォルトの名無しさん
06/05/13 09:31:01 .net
>>532
その辺からサンプルソースを落として
とりあえずコンパイルすれば何もせずに
目的のものが手に入ると思ってる用途
だろ？
534:531
06/05/16 19:41:24 .net
スルーされたと諦めて見てなかったり。
気まぐれで覗いてみたら回答というか煽り文句がついてて
嬉しいんだか悲しいんだか。
亀ﾚｽになるけど、せっかく返事もらったし。
>>532
ツールを作る用途のつもりで書きました。
ゲーム制作だとかは（使えねぇと言いつつ）結構あるんだけど…
ツールの例がちょっと見つからなかったので。
調査不足ですか。ごめんなさい…。
>>533
適切な分析をどうもありがとう。
とりあえず、パッケージの設定と配置されてる階層が明らかに違うものがあったのですよ。
ちゃんと動かしたら治ったけどね。
サイトのミスかこっちのミスか気になったんだけど
自己解決と言うか自己完結。どうでもよくなっちまった。
535:デフォルトの名無しさん
06/05/16 23:40:15 .net
>>534
それを作者にフィードバックしてこそ、ネットの意義じゃないか・・・
536:デフォルトの名無しさん
06/05/17 03:08:09 .net
商用配布フリーな圧縮解凍ライブラリを探しています。
おすすめなどありますか？
537:デフォルトの名無しさん
06/05/17 05:35:14 .net
>>536
zlib
538:531
06/05/17 08:10:47 .net
>>535
それはそうなんだけどね。私チキンだから…。
それに、いまだに誰もフィードバックしていないという点が
用途に関する疑問につながってるわけで…
まあ、そんな御託というか言い訳はどうでもいいか。
それより改めて聞きたいことができてしまいました。
7z形式のデータ書式がどんな構造してるかわかる人いませんか？
バイナリで開いてみたりしたところ
7z～（たぶんヘッダ）圧縮したファイルのデータ… ファイル名らしきもの（たぶんフッタ）
って構造になってたのですが、これの細かい仕様がわからないのですよ。
使ってる間は保存形式なんて気にもしてなかったんですけどね…
使う側から弄る側に来て、自分の無能っぷりを痛感しております。ﾊｲ。
539:デフォルトの名無しさん
06/05/17 16:35:50 .net
統合アーカイバプロジェクトのいろんなヤツを落とせば
開発用のヘッダとかに書いてあるんじゃねーの、そんなもん。
540:531
06/05/17 18:31:07 .net
>>539
統合アーカイバプロジェクトとは何ぞや…っと。
googleで検索→（ﾟ∀ﾟ；）ｱﾊﾊハ…orz
情報提供ありがとうございます。
理解できるか怪しげですが…やるだけやってみます。
541:531
06/05/18 10:28:18 .net
＞7-zip32.dll は基本的に本家 7-Zip の 7za.exe のソースの
＞main() を呼び出しているだけに過ぎません。
＞理由は 7-Zip は現在進行形で日々進歩しているのでフォーマットを解析して
＞独自に作成すると新しい形式にすぐに対応する事が出来ないためです。
ｳﾎﾞｧｰ(ﾟДﾟ)
542:デフォルトの名無しさん
06/05/18 15:01:52 .net
>>531
本家は最初に見たんだよね？
>>541
統合アーカイバは、
基本的にこの手のものはライブラリで済ますか、
引数の統一を行うインタフェースであることが多い。
543:531
06/05/18 15:50:56 .net
>>542
7-zipの日本語サイトは見ました。
…もしかして、ここで言う本家って、英語ページのことだったりします？
やっぱり見なきゃダメかな…。
byteで取り出してあとはループで解読していけばいいかなーとか考えてたら
解読部分のソースjavaで置いてないし。
7z書庫のフォーマットもわからないし。
フォーマットの解析からするしかないのかな…。
544: ◆rK6fgwCWsM
06/05/18 17:44:01 .net
>>543
7zFormat.txtというそのまんまな文書がLZMA SDKに入っているように思うのですが、気のせいでしょうか。
545:デフォルトの名無しさん
06/05/18 21:09:23 .net
英語のドキュメント読む練習しておくと絶対に役立つよ。
546:531
06/05/18 22:59:37 .net
>>544
…。
('A`)ｳﾎﾞｧｰ
しかもなんか、このﾃｸｽﾄ見覚えがある気がするぞ('A`)ｳﾎﾞｧｰ。
ご指摘ありがとうございます。明日にでも中身見てみます。
やっぱり英語は大事ですね…。
でもノバとか行く気無いしなー。
547:デフォルトの名無しさん
06/05/18 23:50:12 .net
>>546
日本語の読み書き・会話がフツーにできても日本語の難しい技術資料を読むのは大変。
それと同じで、どんなに英語ができるようになっても技術系の情報はどうしても読み辛さがつきまとう。
だからもう英語の技術情報の読み辛さは開き直って受け入れるしかないよ。
ちなみに逆にある程度、英語になれちゃうと日本語と違ってあいまいさが少なく直接的な表現が
多いから下手な日本語の技術資料よりもよっぽど読み易いこともある。
548:デフォルトの名無しさん
06/05/19 01:57:46 .net
>>547
それって逆だろ
英会話はからっきしできなくて英語の小説もさっぱりワカンネ
英語は専門書ぐらいしか読めないやって理系は多いと思うぞ
549:デフォルトの名無しさん
06/05/19 08:13:35 .net
>>548
>英会話はからっきしできなくて英語の小説もさっぱりワカンネ
>英語は専門書ぐらいしか読めないやって理系は多いと思うぞ
俺の経験からすると全く逆だ。俺も英語は技術資料を読むためだけにしか使ってなくて
自分の英語力の低さを嘆いたんだけど、こんなことじゃいかんと英語圏のメーリングリスト
に参加してみたらそこでやりとりされてる会話が思いの外スラスラ読めてビックリした。
それで俺は、あー、やっぱり英会話って中学生の英語レベルで十分意思疎通は可能
なんだなぁと思ったもんだけど。
550:デフォルトの名無しさん
06/05/19 08:39:30 .net
ぶっちゃけ、外国語は才能。
才能の無い奴はいくら勉強しても無駄。
一方で、できる奴がやたら必死に「努力すれば誰でもできる」
ことにしたがるのも外国語という分野。
551:デフォルトの名無しさん
06/05/19 08:57:03 .net
>一方で、できる奴がやたら必死に「努力すれば誰でもできる」
>ことにしたがるのも外国語という分野。
それはその他の多くの分野でもそうだろ。
俺も、中学生の頃ぐらいまではプログラミングを「努力すれば誰でもできる」ものだと吹いていた。
いまじゃ、ほとんど逆のこと言ってるけどねｗ
552:デフォルトの名無しさん
06/05/19 14:16:14 .net
仕事になればかなりのアフォでもアフォなりにプログラムは書けるようになるよ。
仕事じゃないなら、プログラミング自体が趣味だとか、
興味の対象とすることに応用できるとか（音楽家が演奏PG作るとか）何か理由がないと
向いてる人以外はそもそも学習意欲がわかないだろうね。
553:デフォルトの名無しさん
06/05/20 01:10:51 .net
俺みたいに、才能ないけど、好きで趣味でやってるやつもいますよ。お忘れなく。
554:デフォルトの名無しさん
06/05/20 04:33:37 .net
野暮な突込みで恐縮ですが
>>552にも「プログラミング自体が趣味だとか」と書かれておりますし
忘れたわけではないと思いますよ。
555:デフォルトの名無しさん
06/05/21 17:34:54 .net
仕事で、多少リアルタイム性が必要な不定長バイナリの通信データを圧縮
しろって言われてしまいました。データ自体のパターンは限定せず、場合に
よっては1バイトから即時送信できないといけないようです。もちろん、最初の
方のデータが増えるのは構わないのですが、「データ送信を継続しているうち
にだんだん圧縮が効いてくる」ようにしたいのです。
一応売り物に組み込むものなので、自分で作るのは信頼性&手間&特許絡み
でめんどいので、できればzlibあたりを使いたいのですが、こういう場合にも
使えるものなのでしょうか ? おそらく、任意のタイミングで出力バッファを
flushしてデータを送信してしまっても、蓄積した圧縮に必要な情報がそのまま
残って以降のデータに適用できれば使えるとは思うのですが。
556:デフォルトの名無しさん
06/05/21 19:23:27 .net
仕事
しろ
まで読んだ
557:デフォルトの名無しさん
06/05/22 22:32:53 .net
俺は
仕事
しろ
よ
まで読んだ
558:デフォルトの名無しさん
06/05/23 04:51:04 .net
> バイト
> が増えるのは
>
>
> めんどいので、
> おそらく
> そのまま
> 残って ると 思う
559:解凍されたい
06/07/03 18:08:33 .net
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 );
560:解凍されたい
06/07/03 18:09:51 .net
上のプログラムではあらかじめ作成してある C:\testdir.zip という
zipファイルを指定して、unzip32.dllのAPIであるWiz_SingleEntryUnzip
を上記のように呼び出して解凍を試みています。
マニュアルによると、圧縮ファイル内のすべてのファイルを解凍する場合、
第1引数と第2引数は上のように出来るはずなのですが、どこが間違ってい
るのかわからなくなってしまいました。
どなたかよいサンプルプログラム（動くもの）等をご存知の方がいらっし
ゃいましたら教えてはいただけないでしょうか？
561:デフォルトの名無しさん
06/07/04 00:58:13 .net
zlibとかってストリーム形式でデータ扱えるけど、あれ内部的には小さなブロックサイズになって処理されてるの？
もしそうなら、前後の依存関係が問題になって、なかなかいい圧縮率を出せないような・・・
562:デフォルトの名無しさん
06/07/04 03:19:56 .net
zlibはdeflate、deflateはlz77。
lz77は出力したビットへのポインタを符号化する。
なので、後方の依存関係はなくて、常に前方依存。
だからストリームに出来る。
といっても32KBのバッファは必要。
圧縮率の問題は依存とかじゃなくてアルゴリズムの問題。
PPMも前方依存でストリーム可能だけど多くの場合で圧縮率はlzよりもずっと高い。
こっちはメモリ沢山使うし遅いから少し使いにくい。
ちなみにこの前方依存は有限文脈とかマルコフモデルとか呼ばれる。
BWT(ブロックソート)は少し違う。
563:デフォルトの名無しさん
06/07/04 03:46:50 .net
すみません。どこで質問していいのか、わからないのでここで質問させてください。
ウィルス検索について質問です。
ウィスル検索ソフトで圧縮ファイルを検査した場合、ウィルスを検索するのはファイルを一度解凍してから検索しているのでしょうか？
それとも、圧縮されたまま検索されているのでしょうか？
また、どのようにして、検索ソフトはウィルスを発見しているのでしょうか？
回答、お願いいたします。
564:デフォルトの名無しさん
06/07/04 04:19:43 .net
本当にスレ違いなのだが一応。
ソフトによるとしか言いようがない。
圧縮されたものは解凍しなきゃならんわけだから
ファイルが圧縮されているのかどうか調べなきゃならん。
数ある圧縮形式全てを調べるのは不可能だから
普通に考えれば解凍はしないだろう。
ただしOSが扱える形式(WinXPならzip, cab等)は解凍して調べてるかもしれん。
ウィルスは大概怪しげなコードが入っているから、
既知のウィルスに共通している部分をハッシュ化して比較するんじゃないかと予想。
自己参照して実行可能アドレスにロードするとか。
あとは他で聞いとくれ。
565:デフォルトの名無しさん
06/07/04 16:25:05 .net
>>564
大抵は解凍するんじゃない？
以前にどっかのウィルス保護ソフトが日本中の大量のPCを麻痺させた原因が、
圧縮ファイルの展開のバグでCPU100%使い続けてしまうって奴だった。
566:デフォルトの名無しさん
06/07/05 20:37:14 .net
初歩的過ぎる質問でわるいのですけど、
Zlib.dll を使った場合のファイル解凍を行うとき、
使うソフトはなにを使えばよいのでしょうか？
Explzh 等のDLLを組み込んで使うタイプのソフトを探しています。
567:デフォルトの名無しさん
06/07/06 08:33:30 .net
板違いだろ
568:解凍されたい
06/07/07 17:16:51 .net
ネットワーク等のストリームを介してアーカイビング、圧縮／解凍、暗号化
にまで対応した商用ライブラリってありますか？
569:デフォルトの名無しさん
06/07/07 21:39:16 .net
あるよ。
570:デフォルトの名無しさん
06/07/19 16:31:39 .net
商用可能な圧縮・解凍ライブラリを探してるんだけど
zlibだと、ちょっとソースが大きすぎ
このliblzf位の規模で、もう少し圧縮効率が良いのは無いかな？
URLﾘﾝｸ(www.goof.com)
571:デフォルトの名無しさん
06/09/04 22:07:30 .net
保守
572:デフォルトの名無しさん
06/09/07 18:48:02 .net
>>570
奥村先生のアルゴリズム本なんかどうよ
URLﾘﾝｸ(oku.edu.mie-u.ac.jp)
あと、英語が読めるならここも参考になるかも
URLﾘﾝｸ(oku.edu.mie-u.ac.jp)
573:デフォルトの名無しさん
06/09/07 20:20:01 .net
鯖からzipのストリームを貰ってきて
オンザフライでデコードして手に入ったプレインデータから順次描画とかしたいのですが
近道を教示して下さい。
574:デフォルトの名無しさん
06/09/07 20:51:32 .net
URLﾘﾝｸ(www.google.com)
575:デフォルトの名無しさん
06/09/08 12:17:10 .net
>>570
普通のlz77(lzss)のがコード量同規模で数割程度圧縮率高いけど圧縮速度が
576:デフォルトの名無しさん
06/09/08 13:43:27 .net
>>573
zlib のソース・アーカイブの examples/ ディレクトリをまず見たら。
zpipe.c ってのもあるし。
そうそう、ソース とか 英文ドキュメントなら
URLﾘﾝｸ(zlib.net) から辿れるよん。
577:デフォルトの名無しさん
06/09/08 16:23:59 .net
ﾖﾝｻﾏを呼び捨てにするな
578:デフォルトの名無しさん
06/09/11 08:24:10 .net
>>492
今更だけどもう公開してないのね
579:デフォルトの名無しさん
06/09/15 13:48:07 .net
どうしちゃったのかねえ。
消す事ないだろうに。
580:デフォルトの名無しさん
06/09/25 20:29:29 .net
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 を使って確認しようと思ったら、
ことごとく値が違うからハマってしまった。
581:デフォルトの名無しさん
06/09/27 22:54:40 .net
>580
CRC16 って言っても色々あるわけだし。
URLﾘﾝｸ(en.wikipedia.org)
0x8005 の方が ANSI(↑だと IBM になってる)、0x1021 の方が CCITT っすね。
582:デフォルトの名無しさん
06/10/10 10:43:26 .net
URLﾘﾝｸ(www.fileup.org)
BIPという圧縮データが展開できなくて困っています。
同じ名前のbinファイルに出来れば良いのですが……
ググってみると、頭４バイトが展開後のサイズ～
などの解説ページも見つかりますが、よく分かりません
どんな圧縮になっているのか、知っている方いませんか？（展開方法）
583:デフォルトの名無しさん
06/10/10 11:17:38 .net
>>582
「bip 頭４バイト」でググって、多分同じページにたどり着いた・・・
正直、胡散臭い用途にしか思えんのでマジレスしたくないんだがｗ
軽く読んだ感じ、ちょっと変わったLZ77ってだけのよーな
そこに書いてる情報で充分だろ。何が足りない？
584:デフォルトの名無しさん
06/10/10 11:53:25 .net
胡散臭い用途ですみません……
LZ77っぽいのは分かったのですが
自分の知識不足で、そこに書いてあることが完全に理解できていません
・展開位置からの12bit負のオフセットにして、その位置から長さ+3バイトのデータをコピー
とか
585:デフォルトの名無しさん
06/10/10 12:21:40 .net
はいはいDTM板の犯罪スレに帰ろうな
586:デフォルトの名無しさん
06/10/10 12:24:43 .net
>>584
LZSSを勉強してきて・・・イヤマジで
「lzss」は一般的な方式だし、説明ページも豊富だから
587:デフォルトの名無しさん
06/10/10 12:49:17 .net
>>584
12ビットの単純なスライディング辞書方式の簡易な説明に読めるが・・・
何がわからんのか解らない。
引用部以外に意味不明な部分があるのか？
588:デフォルトの名無しさん
06/10/11 00:13:02 .net
LZSSをよく勉強してきます、レスありがとうございました
スレ汚し失礼しました
589:デフォルトの名無しさん
06/10/11 07:15:22 .net
>>579
どうやらインターフェース誌で連載してる模様。
ちら見だけどWebとほぼ同じ内容ぽい。
590:デフォルトの名無しさん
06/10/12 08:41:03 .net
>>589
本当だw
教えてくれてありがとー
番外編もやってくれれば最高！
591:デフォルトの名無しさん
06/11/03 05:22:58 .net
質問です
拾って来たZIPなんですが
中国語文字コードでファイル名・パス指定されているらしく
解凍レンジとかだと
win9x上で解凍できませんｗ
いいソフトありますか？
592:591
06/11/03 05:57:50 .net
ありゃ、ここム板だったじゃんｗ
VB6使いだったがｗ
特別に
とりあえず、こういう場合に簡単に取り出せるソフト教えてｗ
593:デフォルトの名無しさん
06/11/03 08:01:13 .net
それはソフトウェア板ネタだろ
594:デフォルトの名無しさん
06/11/06 18:01:41 .net
Cのソースコード発見
ｈURLﾘﾝｸ(nog0709.hp.infoseek.co.jp)
595:デフォルトの名無しさん
06/11/10 16:16:05 .net
>>594
これは参考になるな
596:デフォルトの名無しさん
06/11/19 08:50:56 .net
すみません。質問させてください。
bz2形式の圧縮ファイルの元のファイルサイズを
実際に展開せずに知る方法はないでしょうか？
597:デフォルトの名無しさん
06/11/19 11:16:30 .net
>>596
ないっちゃね
598:596
06/11/19 11:31:59 .net
>>597
やっぱりそうですか。地道にカウントします・・・。
599:デフォルトの名無しさん
06/11/21 00:23:19 .net
パスワード付きrarを解凍できる、rarアーカイバを作りたいんですが、オープンソースなのはどれがあるのでしょうか？
UnRAR Sourcecode 3.4.3とうのしかなさそうなんですが、これでいいんでしょうか？
600:デフォルトの名無しさん
06/11/21 15:24:40 .net
clamav のソースに libalamav/unrar/ に rar 展開ソースは入っているが
パスワード展開には対応していないな。。。
601:599
06/11/24 00:17:06 .net
>>600
どうも。
人いないんですかねこのスレ。
winrarのサイトでもうちょっ新しいunrarsrc-3.6.8.tar.gzがありました。
MacOSXのソフトでもunrarを使っているようなので、これで良いのかもしれません。
602:デフォルトの名無しさん
06/11/28 00:16:52 .net
URLﾘﾝｸ(www.uploda.org)
何の画像形式が、ご存知の方いらっしゃいませんか？
603:デフォルトの名無しさん
06/11/28 01:51:24 .net
>>602
fileさんによると
> uporg596558.bin: Hitachi SH big-endian COFF object, not stripped
だってよ？ 画像じゃなくて実行ファイルじゃ
と思ったが中身見てみると確かに32bitの色情報くさい感じはするな。
適当に作画させてみたらどうか？
604:603
06/11/28 03:00:22 .net
なんやよくわからんが顔色の悪いおなごが出てきたぞ
URLﾘﾝｸ(www.uploda.org)
640x480の32bit生データなんだがどうも縦16でblock化（？）されているらしく、
そのままbmpのヘッダ付けただけだとだめっぽい。
とりあえず↑のは512x608にして、mspaint使って手動で再構成してみたが、
横512なあたり考えると3D作画エンジン用のテクスチャかなんかかの。
こんなバカなことせんでもなんかのツールにぶちこんだら普通に表示されるような気がするようなしないような。
詳しい人フォロー頼む。3D関係は全然ワカラン。
っか、圧縮なんかされてねーからぶっちゃけスレ違いな気ガス
ところで画像の詳細を教えてもらおうか
605:デフォルトの名無しさん
06/11/28 23:38:27 .net
>>603
ありがとうございます
参考にします
606:デフォルトの名無しさん
06/12/15 18:02:11 .net
遅レス気味だけと >>599
URLﾘﾝｸ(p7zip.sf.net) のソース読んでいたら、
7zip/Crypto/ 以下に rar やら zip でパスワード付けた時の処理があった。
各圧縮ファイル形式のファイルヘッダや通常の解凍などは
7zip/Archive/ 以下だったりするけど。
607:デフォルトの名無しさん
07/01/06 23:01:26 .net
Deflateの展開ルーチンを自前で実装しようとしてるんだけど、
これってひょっとして全部リトルエンディアンなの？
しかもハフマンは右(LSB)から1bitずつ読むわけ？
なんか統一感が無くて判り辛いよ。
なんでこれが普及したんだろ。
608:デフォルトの名無しさん
07/01/11 19:32:55 .net
てすと
609:デフォルトの名無しさん
07/04/06 10:41:33 .net
unzip32.dll はAES暗号化されたファイルに対応しているんでしょうか。
詰まってしまいました。
未対応なら他の方法を考えるんですが。
610:デフォルトの名無しさん
07/04/09 15:13:03 .net
age
611:デフォルトの名無しさん
07/04/20 01:57:42 .net
動画圧縮に関してはここでいいのかな？
H.264の詳細は、一般人でも入手出来ますか？
何をやってるかは大体は情報が手に入るんだけど、実装できるレベルの資料がない・・・。
612:蕪木ら某 ◆Googl8RmwA
07/04/21 00:52:25 .net
>>611
URLﾘﾝｸ(www.itu.int)
URLﾘﾝｸ(www.itu.int)
URLﾘﾝｸ(www.compression-links.info)
URLﾘﾝｸ(www.mpegla.com)
etc.
613:599
07/04/28 23:41:12 .net
>>606
ありがとうございます。
ソースを読むにはまずc++を勉強しないといけないのかな。cしかやった事ない√|○
614:デフォルトの名無しさん
07/04/29 07:49:00 .net
>>613
クラスとSTLの勉強だけだ、おれなんてC++からはじめたし
615:デフォルトの名無しさん
07/05/19 14:37:33 .net
英単語辞書を圧縮された状態で検索に使いたいのですけど、
辞書順にソートされた文字列のリストを、検索可能なままで
高圧縮できるアルゴリズムってありますか？
BPEしてcommon prefixを削除すれば、1/3までは小さくは
できたのですが、もっと効率いいのがあれば
616:デフォルトの名無しさん
07/05/20 00:10:18 .net
ランダムアクセス可能な圧縮方式は局所性を利用できないから
必然的に圧縮率が落ちるよ。
ブロックソートなんかはソート済みデータには弱いから多分ダメ。
PPMは遅い。
今のままで十分かと。
もうやってるかもしれんがprefix毎にブロックにすると圧縮率が良くなる。
prefixでソートされてるんだから辞書全体に対してsuffixを登録して
prefix単位でブロックを作るのがいいかも。
617:デフォルトの名無しさん
07/05/20 00:19:10 .net
>>616
＞ブロックソートなんかはソート済みデータには弱いから多分ダメ。
別に弱くは無いよ。
原理的にはPPMと同じ。
618:デフォルトの名無しさん
07/05/20 02:58:38 .net
>>615
FM-index とかどうよ？
619:デフォルトの名無しさん
07/05/20 10:49:08 .net
>原理的にはPPMと同じ。
んなこたーない。
620:617
07/05/21 10:17:01 .net
>>619
その辺のことはDO++が説明してたよ。
アルゴリズムとしては違うけど、結局圧縮しているものが同じってこと。
621:デフォルトの名無しさん
07/05/21 19:58:43 .net
abcdeという文字に対して
abcdからeを符号化するのがPPM
bcdeからaを符号化するのがBWT
という意味では同じかもしれんけど
BWTは決められたブロック内の情報のみ
PPMはそれまでに出現した情報のみである点が違う。
つまり任意のシンボルが参照できる情報の範囲と質が大分違う。
622:617
07/05/22 10:03:19 .net
>>621
＞BWTは決められたブロック内の情報のみ
＞PPMはそれまでに出現した情報のみである点が違う。
＞つまり任意のシンボルが参照できる情報の範囲と質が大分違う。
範囲なんて調整次第。
PPMだって現実に実装するときはブロックに分けることになるから。
違いは、
BWTはPPMでは未来の出現に相当する部分の情報も使う。
PPMは、それまでに出現した過去のみの情報を使う。
ってぐらい。
ただ、未来の出現といっても、時系列情報を失うので、BWTが特に優位というわけでもない。
623:デフォルトの名無しさん
07/05/22 13:09:12 .net
結局何が言いたいのかよく分からん。
やっぱりPPMとブロックソートは違うものだって結論に変わりはなさそう。
624:617
07/05/22 13:14:26 .net
>>623
616の指摘はおかしいということ
625:デフォルトの名無しさん
07/05/22 15:13:05 .net
ソート済みデータのベンチマーク
URLﾘﾝｸ(www.maximumcompression.com)
626:デフォルトの名無しさん
07/05/22 15:15:13 .net
BZIP2がPKZIPに負けてる。
627:デフォルトの名無しさん
07/05/25 18:23:12 .net
大量の単語がソートされているならLZ77が強いんじゃね？
628:デフォルトの名無しさん
07/05/28 20:23:27 .net
可逆圧縮で、圧縮率より高速性を重視したアルゴリズムでいいのありませんか？
特許に抵触しないフリーなやつでお願いします。
629:デフォルトの名無しさん
07/05/28 20:41:10 .net
>>628
最近のCPUはめっちゃ速いから、ファイルアクセスやってる間に
だいたい圧縮処理が終わっちまうんじゃね？
630:デフォルトの名無しさん
07/05/28 22:26:53 .net
lzo とか?
631:デフォルトの名無しさん
07/05/28 22:44:08 .net
zlibって特許まみれ？
632:デフォルトの名無しさん
07/05/28 23:58:41 .net
探せばなんかに引っ掛かったりするかもな。
633:デフォルトの名無しさん
07/07/08 12:59:07 .net
圧縮
＿＿＿＿＿_
／ ／／ ／|
|￣／ ￣￣,:|//!
|／_,,..,,,,_ .／ .!/｜
| ./ ,' 3／`ヽ::|っ.!
| l ／⊃ ⌒.|つ|
|／ｰ---‐'''''"|／
￣￣￣￣￣
解凍
､ゞヾ'""''ｿ;μ,
ヾ ,'3 彡
ﾐ ミ
彡 ﾐ
/ｿ,, , ,; ,;;:､ヾ`
エラー
_,,..,,,,,,..,,,,,..,,,,,,..,,..,,,,,,..,,,,,,,,..,,,,_
/ ,' 3,' 3,' 3,' 3,' 3,' 3' 3,' 3, `ヽｰっ
l ⊃⊃⊃⊃⊃⊃⊃⊃⊃. ⌒_つ
`'ｰ---‐---‐---‐---‐---‐'''''"
深刻なエラー
_,,..,,,,_
./ 。 `ヽｰっ
l o 3 ⌒_つ
`'ｰ---‐'''''"
634:デフォルトの名無しさん
07/07/25 08:05:28 .net
圧縮アルゴリズムの性能の評価ってどうやるの？
c_i が元の符号(符号長 n で固定)で d_i をその圧縮後の符号として
Σ len(d_i)/Σ len(c_i)
とか計算したら大体どんな圧縮法でも大体1より
ちょっと大きくなるくらいになるよね？
635:デフォルトの名無しさん
07/08/10 18:57:30 .net
現行ツールだと大抵、自己展開CAB(exe)を実行せずに強制展開出来る、
あるいは拡張子を.CABに変えると出来たりするんだが…
それでも展開しにくいファイル、というのはあって、
ツールによって展開出来たり出来なかったりする。
で、そういうファイルを調べてみたら、ヘッダ("MSCF～")らしきものが複数あって、
最初のヘッダは不正で、3番目のヘッダが正解だった。
単にファイルの先頭からヘッダらしきものまで読み飛ばすだけだと、
こういうのに対応出来ないわけだ。
これ、確実な調べ方あるんだろうか？
それともヘッダらしきものを総当りで調べるんだろか？
636:デフォルトの名無しさん
07/10/15 02:36:44 .net
ここでの質問でいいのかわからないのですが、
フォルダ（ディレクトリ）をアーカイブファイルで保存・管理することを考えています。
そのとき、アーカイブのデータを使って元のフォルダの差異が知りたいのですが、
なにかうまい方法（「展開して差分」以外で）はあるでしょうか。
例えばフォルダAとフォルダBの内容が等しいかどうか（具体的には再帰的にファイル
内容の差分（Unix なら diff -r）をとって差があるかどうか）を、対応するアーカイブAと
アーカイブBの差から知りたいのです。
フォルダAとフォルダBの内容が等しい <=> アーカイブデータが等しい
となるようなアーカイブができるとうれしいのですが。
一般的なアーカイブフォーマットにはメタデータ（タイムスタンプ等）が含まれたりして、
アーカイブの単純な差分では駄目なようです。上記の目的のためにはタイムスタンプ等
はいりません。
よろしくお願いします。
637:デフォルトの名無しさん
07/10/15 03:34:02 .net
アーカイブファイル内のディレクトリ情報から、サイズとCRCを
比較するだけでいいと思うが。
で、ここがプログラム板だということは分かっているんだろうか？
638:デフォルトの名無しさん
07/10/15 10:11:49 .net
11
12
1121
122111
112213
639:デフォルトの名無しさん
07/10/15 11:53:08 .net
昨日の平成教育委員会にやってた google入社試験からの問題か
640:デフォルトの名無しさん
07/10/15 12:29:08 .net
連長圧縮？
641:デフォルトの名無しさん
07/10/15 12:33:29 .net
連長っちゃ連長だけど、ぜんぜん圧縮できてない
642:デフォルトの名無しさん
07/10/15 20:06:04 .net
>>639
いつのまにそんなの取り上げるようになったんだｗｗ
643:デフォルトの名無しさん
07/10/17 04:34:09 .net
俺時間内に解けなかった
どうしようorz
644:デフォルトの名無しさん
07/10/18 02:32:30 .net
12221131
1123123111
12213111213113
11221131132111311231
なんか3が出てきた時点で急速に発散
645:デフォルトの名無しさん
07/10/31 03:22:23 .net
だれかgzipを解凍する簡単なコードを見せてくれませんか？
646:デフォルトの名無しさん
07/10/31 04:27:38 .net
DLLつかえ
647:デフォルトの名無しさん
07/10/31 08:53:09 .net
どるるるるるるるるるるうるるるうう
648:デフォルトの名無しさん
07/10/31 16:23:27 .net
自前でやりたい。
649:デフォルトの名無しさん
07/11/09 12:30:47 .net
zlib を見よ！
650:デフォルトの名無しさん
08/02/21 20:27:21 .net
ラプラスで画像ファイル（ビデオ）を圧縮しても容量が小さくならないのは、
どうしてですか？
651:デフォルトの名無しさん
08/02/21 20:29:39 .net
むしろ大きくなってるだろ
652:デフォルトの名無しさん
08/02/21 23:07:20 .net
はたして、容量が小さくなってないものを「圧縮した」と言うのだろうか。
653:デフォルトの名無しさん
08/02/22 03:07:19 .net
可逆で圧縮率と解凍速度に優れたフォーマットって何になりますか？
654:デフォルトの名無しさん
08/02/22 08:45:44 .net
>>650
ラプラスって、ラプラス変換? あれは圧縮とは別次元だぞ。
例えば、CR(コンデンサー+抵抗)の回路などで作った
フィルターの特性を一次式に変換するとかそういう奴でしょう。
確かに、フィルターかましたり、
わざと見えないくらいのノイズを載せたりして
圧縮効率を上げる技はあるけど、
常に圧縮率が良くなるという話でもなかったりします。
655:デフォルトの名無しさん
08/02/22 08:58:12 .net
GB単位で圧縮かまさなければ速度なんて今は殆ど問題にならんような
BWTとかPPM系でもそこそこの速度で動くでしょ
それよりマルチコアが一般的になったからマルチスレッド動作可能なのを考えたい
まあデータを分割して既存のアルゴリズム適用すればいいだけの話だけど
656:デフォルトの名無しさん
08/02/29 03:42:53 .net
C#でzip32j.dllを使用して以下のような構成の圧縮を行いたい場合は
どうすれば良いでしょうか？
c:\aaa\bbb\ccc\ddd\file.txt
とある場合に、cccフォルダ以下を圧縮したいのですができません。
オプションで-rを指定するとaaaフォルダから圧縮され、
-rjを指定するとccc以下のテキストが指定した作成したzipﾌｧｲﾙ
直下に格納されます。
ちなみに、コマンドラインの圧縮対象には「c:\aaa\bbb\ccc」を
指定しています。
657:デフォルトの名無しさん
08/10/10 08:59:48 .net
10万ファイル格納されているZIPファイルのファイル一覧を、待ち時間無しで取得する方法ありますか。
定番のUNZIP32.DLLでは書庫をOPENするのにとても時間掛かります。
最近出たINFO-ZIP最新版だと軽いですか?
658:デフォルトの名無しさん
08/10/10 09:08:16 .net
ZIPフォーマット調べて、自分で読んでみりゃいいじゃん
ファイルの一覧取るくらいなら、圧縮とか気にしなくていいし
659:デフォルトの名無しさん
08/10/10 09:12:02 .net
>>685
すみません。ひとつひとつファイル名を取得して、あと個々に(メモリ上へ) 解凍もしたいんです。
速度が出ていいやつありませんか? UNZIP32.DLLはオープンに時間掛かるのでは除外します。
660:デフォルトの名無しさん
08/10/10 09:14:45 .net
Zipフォーマットは複数合ってすべてに対応するのは、自作では厳しいです。
661:657
08/10/10 10:36:48 .net
自己解決しました
UNZIP32では、1分待っても反応無しのが
7-zipにしたところ30秒で済み
XacRettではなんと0.3秒でopenﾃﾞｷﾏｼﾀ。
662:657
08/10/10 10:45:38 .net
XacRettはopen速いですが、個々のファイルの取得が超掛かります。使い物になりませんでした。
663:デフォルトの名無しさん
08/10/10 13:51:38 .net
だから世にあるフォーマットの仕様を確認すれば違いが判るじゃん。
得手不得手ってのがあるんだしさ。
664:657
08/10/10 16:22:18 .net
使えねえやつらだな。
665:デフォルトの名無しさん
08/10/10 16:26:37 .net
使う側だからね。
666:デフォルトの名無しさん
08/11/04 10:09:01 .net
UN○○32.DLLってOSが64bitでも動くの？
667:デフォルトの名無しさん
08/11/04 17:11:11 .net
x64のOSをまず使ってみてから、その愚かな質問についてあらためて考えるんだな
668:667
08/11/05 00:20:40 .net
(…ふー、うまくごまかせた)
669:デフォルトの名無しさん
08/11/05 19:45:49 .net
>>666
OSが64ビットLinuxだったら動かない。
……と言うボケは置いておいて。
XPは知らんがVistaではとりあえず動く。
動くけどそのDLLを使うソフトも32ビットじゃなくちゃダメ。
もっともそのDLL使うと明言していて64ビットで作ってる馬鹿はいないはずだが。
670:デフォルトの名無しさん
08/11/11 16:36:21 .net
結局のところ、lzwは使っても特許的に問題ないですか？
671:デフォルトの名無しさん
08/11/12 08:43:01 .net
パテントの有効期限切れて、更新ははしなかったらすいが > うにしす
ただ前も言うことをコロコロと変えているので、安心とは言えない気がする
672:デフォルトの名無しさん
08/11/12 19:40:18 .net
サブマリン特許ですね！
673:デフォルトの名無しさん
09/01/08 08:17:56 .net
>>634普通は1よりべらぼうに大きくなるだろエントロピー的に考えて・・・
1よりちょっと大きいだけって、ほとんど圧縮出来てないんじゃね？
674:デフォルトの名無しさん
09/01/10 17:54:00 .net
URLﾘﾝｸ(www.highcelight.com)
上のように、復元したものの文字列を直すフリーソフトってありませんか？
メモ帳のものを復元できたと思ったら、文字化けしていました。
675:デフォルトの名無しさん
09/01/10 21:09:51 .net
それは復元できてないだけです
676:デフォルトの名無しさん
09/01/16 15:05:14 .net
スレチかも知れませんが
.ewaという拡張子で暗号化・圧縮・分割・結合する
海外のソフトウェアを知りませんか？
1990年代後半に使われた物らしいですが
ソフト名がわからず困っています
677:デフォルトの名無しさん
09/01/16 20:15:40 .net
イタチなのでソフトウェア板に行って下さい
678:デフォルトの名無しさん
09/01/28 22:44:59 .net
Windows上で動作するゲームを作っているのですが
そのゲームで使う画像・音声ファイルを、どうやって1つのファイルに格納しようか迷っています
最初は自分でフォーマット決めて、各ファイルを順々に詰めていけばいいかと思ってたんですが
よく考えたらtarや無圧縮zipなどを使った方が
既存のライブラリを使える分、もっと楽だということに気づきました
こうした用途に向いているのは、どの圧縮形式でしょうか？
679:デフォルトの名無しさん
09/01/28 23:10:42 .net
自分が一番扱いやすいフォーマットでいいんじゃね？
680:デフォルトの名無しさん
09/01/29 01:49:37 .net
圧縮せずに、ただまとめるだけなら、自分でやったほうがいいと思う。
681:デフォルトの名無しさん
09/01/29 07:53:37 .net
tar一択だろフォーマット的に考えて・・・まさにその為のフォーマットなんだし。
ただ、自分でやった方が高速軽量になると思う。
単にまとめるだけにしては高機能杉るんだよtarは。
682:デフォルトの名無しさん
09/01/29 08:23:15 .net
ゲームでところどころ取り出すのにはtar向かないフォーマットだった気がするが？
tarはソリッド圧縮的な扱いでそういうの苦手だった気がするが
最近はその辺を改良したtarがあるのか？
そういう意味では個別抜き出しできそうなフォーマットで無圧縮使えばいい。
ライセンス的にLGPLで問題ないなら7-zipが明確。Zipはライセンス料発生するかもしれない。
683:デフォルトの名無しさん
09/01/29 14:29:22 .net
ここの>>570にのってるliblzfが個人的にお勧め。
BSDライセンスでコードも短い。圧縮は64k毎のデータの圧縮を連結している感じ。
ライセンスがある程度自由だと、自作のファイルフォーマットに組み込みやすい。
684:678
09/01/30 09:53:21 .net
ご意見ありがとうございます！
まとめると
1. 自分で詰め込む
2. 7-zipやliblzfを用いる
の2種類が適切なようですね。調べつつ考えてみます
685:デフォルトの名無しさん
09/01/30 10:29:49 .net
>>684
osaskのsar
686:デフォルトの名無しさん
09/01/30 12:41:08 .net
>>685
仕様やライブラリが公開されていないようなのですが
どこかに置いてあるのでしょうか？
687:デフォルトの名無しさん
09/03/09 12:54:48 .net
どうでもいいメモ。NTFSの圧縮形式はLZNT1であり、既にリバエンされている。
URLﾘﾝｸ(cs.fit.edu)
…ロシア語読めなさ杉ワロタ
688:デフォルトの名無しさん
09/03/15 10:42:47 .net
ははは
689:デフォルトの名無しさん
09/09/14 14:40:40 .net
独自でサバクラを作成ししています。
サーバからクライアントにZip圧縮したバイナリデータを送信して、クライアントのメモリ上で解凍する必要があります。
(ファイルにはしないで、ストリームデータです。)
このときに使用できるｄｌｌやライブラリを探しているのですがご存知の方はいないでしょうか？
unzip32.dllでは無理ですよね。
環境はWindwsXpです。
690:デフォルトの名無しさん
09/09/14 16:47:04 .net
unzip32でもできると思う
691:デフォルトの名無しさん
09/11/08 01:21:00 .net
rarにzlibみたいなライブラリ無いの？
rar3形式かどうか判定出来るだけでも機能が欲しい。
hexdumpしてみたけど、RAR3みたいなバージョン文字列は無い様なので、同じバイトコード列かどうか判定するしかない？
眺めた感じだと、１バイト目から１６バイト目までのバイト列と、４５バイト目から４８バイト目までのバイト列で判定すればいいの仮名？
692: ◆rK6fgwCWsM
09/11/08 10:20:25 .net
>>691
unrar.dllでReadHeader(Ex)を使い、RARHeaderData::UnpVerの値を読んでやると分かるかもしれません。
693:デフォルトの名無しさん
09/12/05 01:34:53 .net
可変長の符号をファイルに出力したいのですが
どのようにすればいいでしょうか？
例．値(10進)「3 3 6 3 6 2」
3・・・00
6・・・01
2・・・100
出力後のファイル(2進)「0000010001100」
最低１バイト単位でファイルに出力したいのですがググっても分かりません・・・
因みにVS C++ です。
スレチを承知ですが、宜しくお願いします。
694:デフォルトの名無しさん
09/12/05 02:04:27 .net
ｃ++スレへどうそ
695:デフォルトの名無しさん
09/12/05 02:33:55 .net
ｽﾚﾘﾝｸ(tech板)
C/C++の宿題片付けます 132代目
696:デフォルトの名無しさん
09/12/11 03:16:25 .net
一般的なソフトで
250kb程度のJPG画像の可逆圧縮で圧縮したら一般的にどの程度なんだろ？
原本JPG->204704byte
rar->204697byte
zip->203342byte
作ったやつ->152822byte
俺最高ｗｗｗｗ
697:デフォルトの名無しさん
09/12/11 13:43:46 .net
どんなjpgかによる。
単色なら数バイトに出来るんじゃね。
698:デフォルトの名無しさん
09/12/11 13:48:09 .net
>>1
zlibのソースを見るといいですよ。
699:デフォルトの名無しさん
09/12/11 23:34:00 .net
>>697
お前は単色の白や黒が一般的なのか(笑)
700:デフォルトの名無しさん
09/12/11 23:43:32 .net
>>699
うるさーい。
701:デフォルトの名無しさん
09/12/12 03:57:21 .net
２５６色減色アプリでも作ったほうがいいだろ。モノクロ２５６階調アプリでもいいけど。
702:デフォルトの名無しさん
09/12/12 04:19:52 .net
実際に画像ファイルの統計を取ったら単色の白や黒の比率はかなり高そうだな。
某人気漫画家の作品のような状態で放置されたファイルもたくさんあるだろうし。
703:デフォルトの名無しさん
09/12/12 20:47:38 .net
個人のストレージ節約には使えても
配布のためには用を為さないな
704:デフォルトの名無しさん
09/12/12 21:22:54 .net
配布なら尚更サイズ小さく出来たほうがメリット大きい。
705:デフォルトの名無しさん
09/12/12 21:52:21 .net
圧縮解凍プログラム作った時の疑問点なんですが、最初unzip32.dllを使用していて解凍したのですが、
必ず解凍確認ダイアログが表示されてしまうので、7zip.dllに乗り換えました。
解凍確認ダイアログ消す方法ってあるんですかね？
706:デフォルトの名無しさん
09/12/12 22:26:14 .net
>>704
や、単なるモノクロ絵を配布はあまりしないだろうという話
707: ◆rK6fgwCWsM
09/12/13 10:02:01 .net
>>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についてもおそらくその類のダイアログを表示しない方法はあると思います。
的外れな回答をしていたらすみません。
708:デフォルトの名無しさん
09/12/15 23:33:39 .net
>>707
的外れではなく、合っていますｗ
「解凍確認ダイアログ」というのは、解凍終了しました等、解凍した（何か動作した）と分かるようなPOPUP画面の事です。
自動上書き、進行状況非表示を引数で指定したのですが、進行状況を表示するための空のPOPUP画面がどうしても消えませんでした。（進行状況自体は消えましたが）
readmeを見たのですが、
それらしきオプションもなく断念しました。
709: ◆rK6fgwCWsM
09/12/16 20:27:47 .net
>>708
すみません。開発者用sdkのUNZIP32S.txtに次のように書かれていました。
> また、標準で結果窓が表示されるようになってます。これを禁止するには以下のレジストリに ShowResult と言う DWORD 値を作成し、0に設定してください。0 のかわりに 0xFFFFFFFF とすると、エラーがあったときだけ結果窓が表示されます。
> HKEY_CURRENT_USER\Software\ArchiverDll\UNZIP32\Settings\
UNZIP32.APIに記されている内容によれば、この設定は初期値でoffになっているようですが、何かの拍子に設定が変えられてしまっていませんでしょうか。
710:デフォルトの名無しさん
10/01/09 05:12:02 .net
データ復活/完全削除 【無料版】
これもうダウンロードできないけど
持っている人いないかな？
711:デフォルトの名無しさん
10/01/09 17:32:12 .net
ソフトウェア板で聞けよ
ここは作る方の板だ
712:デフォルトの名無しさん
10/01/09 19:02:46 .net
資料にするんだろ
713:デフォルトの名無しさん
10/01/09 21:17:11 .net
それならそれでスレ違いだな
714:デフォルトの名無しさん
10/01/09 21:32:01 .net
わざわざスレチ教えるなんてやさしい奴ら
でも「データ復活/完全削除」超えるフリー無いな
715:デフォルトの名無しさん
10/03/08 15:02:33 .net
新しい圧縮方法考えてみた。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
となる
あ…ありのまま 今 起こった事を話すぜ！
『自作の新圧縮方式を試していたら
いつのまにか容量が増えていた』
な… 何を言ってるのか わからねーと思うが
俺にもわからねえ
716:デフォルトの名無しさん
10/03/08 15:29:45 .net
>>715
それ、どう見てもランレングスだと思うけど。
新しいどころか、何十年前の話だ。
717:デフォルトの名無しさん
10/03/08 16:25:31 .net
1000→113
この時点でおかしいｗ
718:デフォルトの名無しさん
10/03/08 16:27:38 .net
自然対数の底とかなんとか
719:デフォルトの名無しさん
10/03/09 13:06:30 .net
>>716
全く同じでﾜﾛﾀ・・結構いいと思ったんだけどなぁ・・
>>717
113は
一文字目が'1'で始まる、二文字目は一文字目の数字が'1'つ続く、
三文字目は前と反転しているビットが'3'文字続く、の意味
そんなことしなくてもwikipediaみたいに・・
そもそもとっくにあるものの劣化版なのでどうでもいいな・・
720:デフォルトの名無しさん
10/03/09 20:44:27 .net
0 と 1 なら、数え上げ符号にしておけとあれほど・・・
721:デフォルトの名無しさん
10/03/10 14:11:25 .net
>自然対数の底とかなんとか
これって良く見るけど
そこ？
てい？
どっちですか
722:デフォルトの名無しさん
10/03/10 15:05:29 .net
高校で習うよ
723:デフォルトの名無しさん
10/03/10 16:52:42 .net
てい
724:デフォルトの名無しさん
10/03/10 17:39:36 .net
ありがとうございました
でもなんで 2.71828182845904523536028・・・ みたいな変な数字なんだろ
725:デフォルトの名無しさん
10/03/10 17:43:26 .net
e = 1/0! + 1/1! + 1/2! + 1/3! + 1/4! + ・・・・
だからさ
726:デフォルトの名無しさん
10/03/10 18:03:19 .net
それは自然対数の底だな。
分野によって10（工学関係とか）2（情報関係とか）が底のこともある。
2とかそれ以外が底だったら普通は明示される。
たいてい10かeが底で、底がeの対数は特にlogではなくlnと書かれたりする
（その場合logで示されるのは底が10）。
ネイピア数（ないしオイラー数）eは (1 + (1 / n)) ** n （ ** は冪乗）の n を∞にした
時の極限（ほかにもいろいろな定義はあるが）。いろいろな性質がある。
たとえば、y = e ** x というグラフの傾きは e ** x であるとか。
727:デフォルトの名無しさん
10/03/10 18:47:51 .net
logって何が便利なの？
728:デフォルトの名無しさん
10/03/10 18:53:07 .net
高校で習うよ
729:デフォルトの名無しさん
10/03/10 18:54:06 .net
eとかlogとかって圧縮復元に役に立つの？
730:デフォルトの名無しさん
10/03/10 18:57:36 .net
729の役には立たないよ
731:デフォルトの名無しさん
10/03/10 21:02:01 .net
>>727
例えば10進数で81桁の数値は64進数だと何桁必要か計算するときにlogを使う。
732:デフォルトの名無しさん
10/03/11 13:26:56 .net
６４進数とか要らないなw
733:デフォルトの名無しさん
10/03/11 20:41:09 .net
Base64なんかはある意味64進数といえなくもない
734:デフォルトの名無しさん
10/03/20 17:05:41 .net
位取りの概念がないじゃない
735:デフォルトの名無しさん
10/03/21 11:57:06 .net
は？馬鹿ですか？
736:デフォルトの名無しさん
10/09/17 23:12:57 .net
ぼくではない
737:デフォルトの名無しさん
10/11/10 20:50:47 .net
"Move To Front" の改良 良になっていると思います
過去２Byte値から今の１Byte値を"Move To Front"するテーブルを選ぶ
詳しい処理はソースを見てください
URLﾘﾝｸ(gmdev.xrea.jp)
[標準10MB] [148.zip] 実験用実行アプリ Delphi4 ソース付き
注意
実行アプリのウイルスチェックはしてません
感染は無いと思いますが自己責任ということで
738:デフォルトの名無しさん
10/11/10 23:18:20 .net
学生さんかな？
ここで晒してもしょうがないと思うのだけど…
MTFの改良とか一度は考えるよね
実際にやってみると大したこと無くてがっかりっていう
この手のやつをRecency Rankingというのだけど
頻度が考慮されないから算術符号やハフマン符号と比べるとだめなんだな
もっともっと勉強してちょうだい
739:デフォルトの名無しさん
10/11/11 00:25:01 .net
再帰順位符号化法は、理論的にはエントロピーを達成できるよ！できるよ！
740:天使 ◆uL5esZLBSE
11/07/03 13:21:22.14 .net
なんだ、ただのゴミか
741:デフォルトの名無しさん
11/07/07 21:50:49.65 .net
「容量無限のHDD」実現の可能性も、新たな物理現象が発見される - GIGAZINE
URLﾘﾝｸ(gigazine.net)
742:デフォルトの名無しさん
11/07/07 22:30:26.96 .net
LHCでブラックホール圧縮したほうが簡単。
743:デフォルトの名無しさん
11/07/07 23:25:05.99 .net
>>741
昔に流行ったπ（円周率）圧縮と原理は同じ
744:デフォルトの名無しさん
11/07/08 00:41:50.33 .net
それとは違うだろ
745:デフォルトの名無しさん
11/07/08 01:54:35.69 .net
>>741
圧縮と関係ないから。
746:デフォルトの名無しさん
11/07/18 16:25:30.65 .net
アキレスと亀みたいな無限圧縮理論があったろ。
あれと似てるねって話だろう。
747:デフォルトの名無しさん
11/08/20 12:26:41.97 .net
基本的なことを教えてください。
①１Mバイトのランダムなデータ列と２Mバイトのランダムなデータ列をファイルにしてzipにしました。
圧縮率はどっちが高いですか？
②１Mバイトのランダムなデータ列と１Mバイトの数列（０，１，２・・・ｆｆH・・・）をファイルにしてzipにしました。
圧縮率はどっちが高いですか？
③１Mバイトの数列（０，１，２・・・ｆｆH・・・）と２Mバイトの同じ数列（０，１，２・・・ｆｆH・・・）をファイルにしてzipにしました。
圧縮率はどっちが高いですか？
できれば、経験的な結果ではなくて、数学的？技術的結果を知りたいです。（経験的結果ももしあれば知りたいです）
よろしくお願いします。
当方ハード屋です。簡単なプログラミングはできるぐらいのキャリアです。
748:デフォルトの名無しさん
11/08/20 12:41:46.03 .net
>>747
zipなら自分でやってみればいい。
zipじゃないなら、圧縮率がどうなるかは圧縮アルゴリズムによる。
749:デフォルトの名無しさん
11/08/20 12:45:01.97 .net
>>748
レスどうも。
やっぱりやってみないとわからんものですか・・・
理論的にはどう考えたらいいのかを、聞きたかったんですが。
750:デフォルトの名無しさん
11/08/20 12:51:08.48 .net
>>747
ランダムデータは多分全く圧縮出来ない
数列が00hからffhの方はもの凄く縮む
123は全て後者の圧縮率が高いよ
>>748の通り実験あるのみ
751:デフォルトの名無しさん
11/08/20 13:03:32.15 .net
>>750
レス、どうも。
『データ量が多いほうが圧縮率が高くなる傾向がある』
と考えていいのでしょうか？
また質問ですみません。
752:デフォルトの名無しさん
11/08/20 13:11:59.31 .net
>>751
いや、zipはLZ法といって
同じパターンを検出して別の符号で置き換えるという仕組みになってる
ランダムデータは繰り返しがないから圧縮出来ないし
数列の方は00h-ffhが繰り返されるからそこで縮むのよ
753:デフォルトの名無しさん
11/08/20 13:27:20.28 .net
>>752
レス、どうも。
よくわかりました。
この場合ランダムデータと言えるか疑問ですが、
もし、ランダムデータでもちょっとでも繰り返しパターンが現れたとして、その大きさも出現率もランダムだとして、この場合少しは圧縮できると思います。
その場合は、
『データ量が多いほうが圧縮率が高くなる傾向がある』
とは理論的に言えないのでしょうか？
実験をして臨床的に？測定はできるでしょうが、まずは頭の中で整理したいので、よろしくお願いします。
754:デフォルトの名無しさん
11/08/20 13:36:12.73 .net
>>753
データ(情報源)次第としか言いようがないんだけど
データ量が増えるほど参照可能なデータが増えるので圧縮率は上がる
と言える
ので理屈としてはそれであってる
言うまでもなく計算量は増えるけども
755:デフォルトの名無しさん
11/08/20 14:12:35.01 .net
>>754
ありがとうございます。
ですよね。ランダムデータの共通概念を確認してから話すべきでした。
失礼しました。
756:デフォルトの名無しさん
11/08/20 16:35:41.98 .net
圧縮について理論的な裏付けを探しているなら、
次のキーワードについて調べてみるとよいでしょう。
初等的な情報理論の参考書に出ているものです。
情報源（符号化）
エントロピー
ユニバーサル
エルゴード性
エントロピーレート
757:デフォルトの名無しさん
11/08/20 17:20:35.51 .net
>>756
どうも。
わからないところが出てきたら、また教えてください。
758:デフォルトの名無しさん
11/08/21 00:44:08.36 .net
>>749
やってみないとわからないというより、何を目的に聞いているのかわからないから、答えにくい。
圧縮もzip(LZ法+ハフマン)に限る話なのか、あらゆるアルゴリズムを検討するかによっていろいろ変わってくる。
情報理論的にランダムデータは統計的には圧縮できない。
(圧縮できるケースも０ではないが、できないケースがそれをはるかに上回る)
759:デフォルトの名無しさん
11/09/08 00:22:45.54 .net
解凍速度重視でデコーダー書いてアセンブリ出力見て無駄が減り
実測でも速くなってるとお茶が美味い、でへへ
760:デフォルトの名無しさん
11/09/22 01:47:33.31 .net
>>510-512関連での質問なのですが、
もし対象のファイルが複数あり、それぞれ違うドライブの場合、
どのように対応すればよいのでしょうか?
761:デフォルトの名無しさん
11/10/04 04:33:33.93 .net
7zなら、パスを列挙したリストファイルを渡して圧縮させるコマンドが無かったか？
762:デフォルトの名無しさん
11/10/19 17:21:06.75 .net
zip32j.dllで同じファイルを圧縮しても、
出来るzipのCRCが毎回違うってのは正常？
WinRAR使うと毎回CRCは同じなんだが
763:デフォルトの名無しさん
11/10/19 17:53:00.10 .net
圧縮ルーチンの中で乱数使ってるんじゃないかな
解凍後のCRCが一致してれば問題なし
764:デフォルトの名無しさん
11/10/19 18:29:03.25 .net
>>762
できたzipファイルのCRC、圧縮されたエントリのCRC
どっち？
前者なら最終アクセス時間も記録してるとかって可能性もあるよ。
後者だと理由がサッパリわからんけど。
765:デフォルトの名無しさん
11/10/19 19:09:18.86 .net
>>763
なるほど。
確かに解凍後のファイルのCRCは一致してるんで、
実用上問題は無いんですが、ちと気になったもので。
これ常識なのかな、と。
>>764
前者です。
> 最終アクセス時間も記録
これですかね？
766:デフォルトの名無しさん
11/10/20 22:51:54.07 .net
スレ違い
767:デフォルトの名無しさん
11/11/29 22:44:34.18 .net
ふと気になってzipの仕様を見ていて疑問に思ったのだけれど、
「中央ディレクトリ」の存在意義ってなんですか？
わざわざローカルファイルヘッダと分離して、しかも書庫末端に配置
させている意味がわからないです。
書庫冒頭ならここを基点にランダムアクセスがしやすい、というのは
想像できるんですが、可変長コメントを終端に許容している時点で
後ろから計算するのも非常にめんどくさいことになってますし。
どうせだし作者にメールでも投げるか、と思ったら作者亡くなってるし。
768:デフォルトの名無しさん
11/11/29 23:04:07.92 .net
LZH書庫のゼロ終端と同レベルには必要。
769:デフォルトの名無しさん
11/11/29 23:11:50.61 .net
1passで書庫作る場合、中央ディレクトリみたいのをつけようとすると
どうしてもケツにしかつけられないってだけでしょ。
1passで書庫作れるようになってるのはzipの強みの一つだと思うんだが。
例えばlhaはチェックサム書き出すために一旦ヘッダまで戻らなきゃいかんから2passになる。
圧縮データをどっかに保存しておければ1passっぽくできるけど。そのために記憶領域が必要になる。
770:767
11/11/29 23:20:10.21 .net
解凍することだけ考えてて圧縮のこと何も考えてなかった。
なるほど。確かに1passで作れるっていうその点は強みですね。
すごいスッキリしました。ありがとう。
771:デフォルトの名無しさん
11/11/29 23:44:11.23 .net
ケツにもコメントの長さつけてくれれば
後ろから読むのが楽だったと思わずにはいられない
772:デフォルトの名無しさん
11/11/30 02:12:31.07 .net
ファイル先頭に置くと、ファイルを追加するたびに書庫ファイル全体を
書き直さないといけなくなるよ。
末尾にあれば追加された分と中央ディレクトリ分だけで済む。
773:デフォルトの名無しさん
11/11/30 03:49:27.68 .net
インデックスは末尾が当然だな。もしくはシーケンシャルアクセスで良いならTARのようにする。
774:デフォルトの名無しさん
11/11/30 13:05:45.71 .net
圧縮と暗号化を両方行いたい場合
先に暗号化してから圧縮すると
圧縮してから暗号化したときに比べて
サイズがかなり大きくなってしまいます
圧縮と暗号化を同時に行うアルゴリズムだと
効率は良くなるのでしょうか？
775:デフォルトの名無しさん
11/11/30 13:11:04.03 .net
符号化と暗号化を勉強しろｗ
776:デフォルトの名無しさん
11/11/30 13:22:50.71 .net
>>1
777:デフォルトの名無しさん
11/11/30 13:25:01.15 .net
まあアルゴリズムの話はともかく
どうして暗号化ツールには圧縮機能がなくて
圧縮ツールには暗号化機能がないのはなぜ？
778:デフォルトの名無しさん
11/11/30 14:22:37.76 .net
君が馬鹿だからそういう疑問が出る。
>>775
779:デフォルトの名無しさん
11/11/30 14:57:55.25 .net
一番の問題点は仕様がアホみたいに巨大かつ肥大化を続けてることだろう
780:デフォルトの名無しさん
11/11/30 15:28:11.94 .net
モチはモチ屋的な思考する人が多いからじゃねーかと思ったが、
圧縮ソフトは暗号化機能つけてるのも結構あるよね。
781:デフォルトの名無しさん
11/11/30 15:44:18.70 .net
圧縮するときの符号化した辞書を暗号化すれば医院で内科医
782:デフォルトの名無しさん
11/11/30 15:53:09.43 .net
馬鹿には無理
783:デフォルトの名無しさん
11/12/02 05:52:08.41 .net
ちょっとした思いつき
ABCCABBCA
というような並びのデータがあるとして、このままではあまり圧縮に適してないが
これを
ABC
CAB
BCA
と並べて右上から右下斜めに読むと
CBBAAACCB
となって圧縮しやすくなる
これを斜め読みアルゴリズムと名付けた
データを二次元に展開すると読み方は横読み、右下斜め読み、縦読み、左下斜め読みの4種類定義できるが
この4種類を順番に適用して圧縮を繰り返すと、可逆を維持したままファイルサイズをものすごく小さくできるかもしれない
これを回転圧縮法と名付けた
暇な人は論文でも書いてみたらお金になるかも
784:デフォルトの名無しさん
11/12/02 06:02:58.46 .net
URLﾘﾝｸ(ja.wikipedia.org)
785:デフォルトの名無しさん
11/12/02 11:35:07.19 .net
馬鹿には無理
786:デフォルトの名無しさん
11/12/02 12:16:26.63 .net
俺も考えたぜ！
１ はなっから元のデータを線形合同法で作る
２ シード値のみ保存
やばい 1/10000000000ぐらいいく
誰か論文作れ
787:デフォルトの名無しさん
11/12/02 12:40:08.63 .net
それは似たようなことをIBMが専用チップを作ってやろうとしてたね
788:デフォルトの名無しさん
11/12/02 12:44:45.72 .net
馬鹿には無理
789:デフォルトの名無しさん
11/12/02 14:28:29.13 .net
データを最適化する手法は昔からあるわけで、恥ずかしいから馬鹿は黙っておけｗ
790:デフォルトの名無しさん
11/12/03 11:06:16.82 .net
静止画・動画とかアプリケーションが既知の場合なら、データの統計的性質分かってるわけだから、予め超巨大な辞書を作ってみんなで共有しておけば、めっちゃ圧縮できそうな気がするんだけど。
なんで未だに離散コサイン変換＋ベクトル量子化で頑張ってるの？
詳しい人おしえて！
791:デフォルトの名無しさん
11/12/03 11:19:41.21 .net
それってさ、「ここのURLにデータがあるよ」ってアドレス渡す事と同義なんだよ
データ自体が小さくなるわけじゃないんだ
792:デフォルトの名無しさん
11/12/03 11:26:41.08 .net
量子テレポーテーションをうまく応用すれば圧縮に使えるのではないか。
793:デフォルトの名無しさん
11/12/03 12:05:45.58 .net
>>791
データ自体が小さくなるってことじゃね？
画像の元サイズＸ、圧縮後のサイズＹ、枚数Ｎ、辞書のサイズＺとすると
N*X > N*Y + Z
になってれば圧縮できてるよね。
Ｎがでかけりゃでかいほど、辞書でかくしてもいいじゃん。
１Ｇ
794:デフォルトの名無しさん
11/12/03 12:22:40.45 .net
研究発明にはこういう馬鹿も必要だ
795:デフォルトの名無しさん
11/12/03 12:49:44.40 .net
しかも、辞書分のＺを全員が共有できてるという前提であれば、
N*X > N*Y
って、すごい圧縮できそうやん！
コサイン基底なんか使わずに、１0ＧByte分くらいの過剰な基底を用意しとけば、画像なんか超小さくなるべ！
796:デフォルトの名無しさん
11/12/03 18:32:29.10 .net
>>790
別に頑張ってないよ。
もっと先の技術はちゃんとあるが、馬鹿は知らなくていいよ。
ハッシュ値(またはそれに類するもの)で元のデータを引っ張って来れる仕組みを圧縮と見なすなら、
ファイル共有ソフトは一種の圧縮であり、winnyなりshareなり、既にある。
797:デフォルトの名無しさん
11/12/03 18:34:54.58 .net
>>795
ならないよ。
JPEGエンコーダなんて一日もあれば作れるから、本当にそう思うなら作って実験してみようよ。
そうすることで自分の愚かな間違いにちゃんと気が付けるよ。
798:デフォルトの名無しさん
11/12/03 19:04:11.19 .net
昔、「ハノイ圧縮」ってネタがあったけど、これって辞典型の究極と言える。
ところが、このハノイ圧縮で、世界中のデータを圧縮していくと、
たちまち圧縮できなくなっていき、かえってサイズが増えることになる。
ちょっと試算してみるとわかるけど、
データ圧縮が圧縮となる世界って、非常に狭いんだよね。
ハノイ圧縮で圧縮できている範囲だけ利用するとしても、
結局それは、現在の他のデータ圧縮法よりは多少マシかなぁ程度。
ハノイ圧縮とLZ78を比べると面白いかもしれない、程度。
799:デフォルトの名無しさん
11/12/03 20:28:46.35 .net
>>796
圧縮アルゴリズム構築時に既知のデータと、圧縮時に未知のデータと分けて考える必要があるね。
ちなみに非可逆ね。
アルゴリズム構築時にハッシュテーブル作っておいて、様々な未知データに対してハッシュ値計算してハッシュテーブルを引く。
ハッシュテーブルにハッシュ値がなかったら、圧縮画像＝真っ黒画⇒像残差デカイってこと。
残差小さくしつつ圧縮率上げるんだから、非可逆の圧縮アルゴリズム考えてる人たちは、この間を責めてるわけだよな。
COS関数という既知の基底以外でも、ウェーブレットみたいに基底も学習しておけば、圧縮率上がるケースも当然あるだろうね。
800:デフォルトの名無しさん
11/12/03 20:31:16.19 .net
ちなみに、8x8の画像だったら64次元の基底があれば、任意の画像を線形和で表せるけど、
基底を10000万個用意しておいても良いわけだ。
圧縮したい画像の枚数が多ければ、10000万個基底用意しておいたとしても、勝てる場合がありそう。
801:デフォルトの名無しさん
11/12/03 20:49:07.46 .net
>>800
ちなみに、10000次元の係数の大半がゼロになるように、L1正則化でもかけて、基底学習できればよさげだな。馬鹿馬鹿いってるやついるけど、血の巡り悪そうだな。
802:デフォルトの名無しさん
11/12/03 21:55:07.14 .net
>>797
隣り合うピクセルの色が近いからCOSで基底変換すると、高周波数成分が0になっるって気付いた奴がいるわけだよね。
そいつは、何枚かの画像（学習データ）を観察して、それに気付いたわけだ。
そして、未知の画像に対しても、同様の統計的性質があるに違いないと思った。これが暗にあるわけだな。
>>796
ちゃんと辞書のサイズZって書いてあるだろ。
ハッシュの先に格納されてるデータがあって、そこのサイズも考慮すれば、それって圧縮できてないよね。
803:デフォルトの名無しさん
11/12/03 22:49:37.03 .net
このデータがこのシステムでこれだけのサイズになりましたっていう実測値だしてくれよ
804:デフォルトの名無しさん
11/12/03 23:10:54.75 .net
WikipediaデータすべてがLinuxで1MBになった。
805:デフォルトの名無しさん
11/12/03 23:20:20.81 .net
話にならんな
806:デフォルトの名無しさん
11/12/03 23:24:13.18 .net
>>805
bzip2を知らんのか。
807:デフォルトの名無しさん
11/12/03 23:58:56.90 .net
話にならんって言ってんだ
流れを読めよ
808:デフォルトの名無しさん
11/12/04 00:04:18.76 .net
>>807
お前Linuxのインストールで躓いたくちだろ。
809:デフォルトの名無しさん
11/12/04 00:07:16.85 .net
流れが読めない…
810:デフォルトの名無しさん
11/12/04 00:17:57.42 .net
今のLinuxのインストールにどうやって躓く要素があるんだ？
811:デフォルトの名無しさん
11/12/04 00:19:41.82 .net
Linuxができないのに圧縮を語るとは世も末。
812:デフォルトの名無しさん
11/12/04 00:24:16.25 .net
LHA、ZIP、GZIPをはじめとする圧縮ユーティリティーの大部分はLinuxで開発された。
まずLinuxの勉強からやり直せ。
813:デフォルトの名無しさん
11/12/04 00:25:10.02 .net
Linuxは俺が教えた
814:デフォルトの名無しさん
11/12/04 00:28:07.22 .net
これからはLinuxの時代
815:デフォルトの名無しさん
11/12/04 00:56:55.25 .net
>>812
えっ
816:デフォルトの名無しさん
11/12/04 00:58:14.31 .net
>>786の要望に応えられる圧縮をLinuxで作ってくれよ。
817:デフォルトの名無しさん
11/12/04 00:59:28.04 .net
>>815
お前は圧縮ユーティリティーがCUIとして作られたことも知らないのか。
818:デフォルトの名無しさん
11/12/04 00:59:33.37 .net
bzip2を知らんのか。
819:デフォルトの名無しさん
11/12/04 01:00:20.11 .net
馬鹿には無理
820:デフォルトの名無しさん
11/12/04 01:00:53.14 .net
CUI=Linuxだ(ｷﾘｯ)
821:デフォルトの名無しさん
11/12/04 01:03:49.60 .net
>>816
それは車輪の再発明と言って優秀なリソースを分散させる結果となる。
822:デフォルトの名無しさん
11/12/04 01:07:07.61 .net
できないんならひっこんでろ。
823:デフォルトの名無しさん
11/12/04 01:09:20.06 .net
>>822
bzip2を知らんのか。
824:デフォルトの名無しさん
11/12/04 01:11:00.95 .net
できてないじゃん。
825:デフォルトの名無しさん
11/12/04 01:13:36.24 .net
最近ム板に変なのが住み着いて、ほとんどのスレが機能しなくなってるのは
なにか対策を考えて欲しい。
もう2chでは無理かね。
826:デフォルトの名無しさん
11/12/04 01:13:58.37 .net
>>817
＞LHAは、奥村晴彦が開発したアルゴリズムをもとに、吉崎栄泰がMS-DOS向けに開発したもので、1988年にパソコン通信で初公開された。
URLﾘﾝｸ(ja.wikipedia.org)
827:デフォルトの名無しさん
11/12/04 01:16:49.73 .net
フォントですか？
828:デフォルトの名無しさん
11/12/04 03:17:42.97 .net
>>800
だから、やってみろよ。自分が馬鹿だったってわかるから。
829:デフォルトの名無しさん
11/12/04 03:29:31.18 .net
>>802
全然違うよ。
JPEGのエンコーダを書いたこともなく、ろくに理解もしないで何言っているの？
統計的性質なんて関係ないから。
＞ちゃんと辞書のサイズZって書いてあるだろ。
共有しているなら、辞書がネットワーク上にあったっていいだろ。
ローカルストレージに限定する理由はない。
＞ハッシュの先に格納されてるデータがあって、そこのサイズも考慮すれば、それって圧縮できてないよね。
本当に馬鹿だな。
ネットワーク全体で冗長度が下がっていれば、それは圧縮と同じなんだよ。
ハッシュは、辞書の符号化に相当する。
830:デフォルトの名無しさん
11/12/04 06:10:22.03 .net
>>829
>統計的性質なんて関係ないから。
JPEGエンコーダってDCTしてハフマン符号化じゃねーのかよ。
統計的性質使って圧縮してんだろ、馬鹿か？
全然違うって、何が違うか指摘しろよ。議論の基本を知らないのか？
>共有しているなら、辞書がネットワーク上にあったっていいだろ。
>ネットワーク全体で冗長度が下がっていれば、それは圧縮と同じなんだよ。
ならハッシュ値計算してデータをひっぱってくるシステムも、圧縮できているわけだな。
今現在ある全ての画像を一箇所に溜めて、未来に撮影される画像もそこに含まれていれば、圧縮できていると言えるだろうな。
とりあえず、学習データで圧縮アルゴリズム作って、検証用のデータで精度を測るって、基本は理解してるか？