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してハフマン符号化じゃねーのかよ。
統計的性質使って圧縮してんだろ、馬鹿か？
全然違うって、何が違うか指摘しろよ。議論の基本を知らないのか？
>共有しているなら、辞書がネットワーク上にあったっていいだろ。
>ネットワーク全体で冗長度が下がっていれば、それは圧縮と同じなんだよ。
ならハッシュ値計算してデータをひっぱってくるシステムも、圧縮できているわけだな。
今現在ある全ての画像を一箇所に溜めて、未来に撮影される画像もそこに含まれていれば、圧縮できていると言えるだろうな。
とりあえず、学習データで圧縮アルゴリズム作って、検証用のデータで精度を測るって、基本は理解してるか？
831:デフォルトの名無しさん
11/12/04 08:54:51.86 .net
↑
こいつ最高にアホ(AAry
832:デフォルトの名無しさん
11/12/04 09:36:28.61 .net
とりあえず、ハッシュマップの話は飽きたよ。
100枚画像があって、20枚重複してて、実質80枚分のデータだったら、サイズ0.8倍になるのね。
DCTとハッシュマップの間を責めれば圧縮率あがるだろってことでしょ？
833:デフォルトの名無しさん
11/12/04 12:21:13.24 .net
>>830
初心者はWindowsでも使ってろ。
834:デフォルトの名無しさん
11/12/04 17:45:11.22 .net
>>830
＞JPEGエンコーダってDCTしてハフマン符号化じゃねーのかよ。
そうだよ。で、君はJPEGエンコーダぐらい書いたことあるんだよね？
俺はちゃんと0から自作したことあるよ。
＞統計的性質使って圧縮してんだろ、馬鹿か？
どこが？
DCTは統計とは関係がないし、ハフマン符号は対象データの中での出現頻度であって、
先の様々な画像の統計的性質とは無関係だよ。
量子化テーブルをどういうものにするかは、ある統計的な性質と関係あるが、
それは画像の統計的性質じゃなくて、人間が見たときに許容できる誤差としての統計的性質。
＞全然違うって、何が違うか指摘しろよ。議論の基本を知らないのか？
こんな枯れた技術は議論する価値もないだろ。
調べればわかるし、わからないような馬鹿や、調べることもできないような馬鹿はここに来るな。
最低限、自分のアイデアを自作してみてからここに来い。
その上で、わからないことがあれば、俺様が教えてやる。
835:デフォルトの名無しさん
11/12/04 17:46:44.08 .net
webp っていいの？
持ってる jpeg ファイル全部 webp 化して
元の画像捨てても平気？
836:デフォルトの名無しさん
11/12/04 18:12:14.39 .net
>>835
お前が今後使うブラウザやビュアが対応しているならいいんじゃね
可逆モードもあるしな。
837:デフォルトの名無しさん
11/12/04 18:16:28.65 .net
>>834
＞DCTは統計とは関係がないし、ハフマン符号は対象データの中での出現頻度であって、
＞先の様々な画像の統計的性質とは無関係だよ。
ん？関係あるよね？
なんでDCTで直行変換かますと、多くの軸の係数が0になるの？
近くのピクセルの色が似てるからだよね。
こーいうのを、人は統計的性質と呼ぶのでは？
＞それは画像の統計的性質じゃなくて、人間が見たときに許容できる誤差としての統計的性質。
人の見が感じる違いと2乗誤差は違うから、そこを責めてる話もあるけど。
そこに拘らなければ、まぁ2乗誤差だろうな。
DCT後の軸の係数が小さいところを0に打ち切るだけ。
上の議論は、COS以外の基底を使って、より少ない非ゼロの軸で、2乗誤差を小さくすることが出来ないかって話じゃね？
後ろのハフマン符号化には触れてない。
838:デフォルトの名無しさん
11/12/04 18:20:06.53 .net
>>837
まず、答えろよ。
君はJPEGエンコーダぐらい書いたことあるの？ないの？どっち？
お前のレベルに合わせて教えてあげるから。
839:デフォルトの名無しさん
11/12/04 18:24:29.29 .net
>>837
＞なんでDCTで直行変換かますと、多くの軸の係数が0になるの？
ならないよ。
＞DCT後の軸の係数が小さいところを0に打ち切るだけ。
違うよ。
量子化テーブルをなんで使うのかわかってる？
840:デフォルトの名無しさん
11/12/04 18:29:21.23 .net
>>839
0になるというか、係数が小さくなるってことな。
それで量子化テーブルの数値がきまってんだろ。馬鹿か？
841:デフォルトの名無しさん
11/12/04 18:34:19.38 .net
>>840
小さくならないよ。小さくするために量子化テーブルを使うの。
馬鹿なことを書いて恥をかく前に、JPEGエンコーダぐらい自作しろよ。
基本部分は一日あればできるし、理解も深まるから、こんなスレに書き込んでいるよりずっといいぞ。
それができないような馬鹿なら、この世界に首を突っ込まない方がいい。
842:デフォルトの名無しさん
11/12/04 18:37:49.68 .net
>>841
URLﾘﾝｸ(ja.wikipedia.org)
ほら、Wikipediaにのってるよ。
右の画像のDCTみてね！
843:デフォルトの名無しさん
11/12/04 18:44:10.50 .net
さらにいうと、どんな画像食わせても、高周波数成分は小さくなる。
この大きさに合わせて量子化テーブルの値が決まってるわけだな。
おまえ、作ったことあんじゃねーの？理解せずにコード書き写しただけ？
844:デフォルトの名無しさん
11/12/04 18:51:27.51 .net
>>842
だから何？実際の数値見たことないの？
量子化テーブルが周波数によって数値が違う意味わかってる？
845:デフォルトの名無しさん
11/12/04 18:55:04.30 .net
>>843
＞この大きさに合わせて量子化テーブルの値が決まってるわけだな。
違うよ。
実際には、高周波成分に大きな値が来ることが多々ある。
低周波の値より、高周波の値の方が無視できるから、量子化テーブルの係数が大きくなるの。
低周波は数値が小さくても無視しない方がいいから、テーブルの係数が小さい。
846:デフォルトの名無しさん
11/12/04 18:55:58.56 .net
>>844
大体、低周波数が大きくならないなら、DCTする意味ねーだろ。
ひとつおりこうさんになったな。
847:デフォルトの名無しさん
11/12/04 18:57:19.48 .net
>>845
そう。
多々ある。その頻度と、各基底が人の目に影響を与える比率で、係数が決まっている。
848:デフォルトの名無しさん
11/12/04 18:57:47.70 .net
>>843
作ったことあるも何も、仕事でやってて、それで飯食っている。
849:デフォルトの名無しさん
11/12/04 19:03:34.67 .net
>>846
＞大体、低周波数が大きくならないなら、DCTする意味ねーだろ。
JPEGにおいてDCTは高周波成分と低周波成分を分ける意味しかない。
つまり、どの情報を捨てるかというフィルタ(後段の量子化テーブル)を使って、圧縮率を上げている。
(他にも色情報を落とすとかもあるが)
変換誤差があるものの、DCT自体はnear可逆変換なので、それだけでは圧縮にならない。
850:デフォルトの名無しさん
11/12/04 19:17:15.10 .net
>>849
そんなはずはない。
色んなソフトで使われてる係数は、「頻度の逆数ｘ視覚への影響」で決まってるはずだぞ。
つまり、基底組み替えた結果、スペクトルに偏りがあるってのは重要なんだよ。
どっかに、量子化係数の決め方の解説があったが、見つからんな。
851:デフォルトの名無しさん
11/12/04 19:21:25.29 .net
この話って、そもそも基本なはずだが。
つーか仕事でやってんのに、こーいうの理解してないの？
流石に周波数分離するだけってのはないだろ。
音の圧縮だって同じじゃん。
852:デフォルトの名無しさん
11/12/04 19:27:28.31 .net
>>850
＞色んなソフトで使われてる係数は、「頻度の逆数ｘ視覚への影響」で決まってるはずだぞ。
頻度じゃなくて、重要度で決まっている。
高周波成分は頻度があっても、基本的には重要ではない。
それこそ量子化テーブルは、画像単位で変えれるが、
ある画像ので低周波成分の頻度やDCT後の数値が低いからと言って、
量子化テーブルの値を大きくできるわけじゃないぞ。
そんなことをしたら悲惨な画像になる。
＞つまり、基底組み替えた結果、スペクトルに偏りがあるってのは重要なんだよ。
高周波成分を捨てるために、分けることが重要なだけ。
853:デフォルトの名無しさん
11/12/04 19:28:35.66 .net
>>851
JPEGは周波数分離のためにDCTを使っているの。
854:デフォルトの名無しさん
11/12/04 19:45:01.33 .net
で、元の問題である、
>>795
＞コサイン基底なんか使わずに、１0ＧByte分くらいの過剰な基底を用意しとけば、画像なんか超小さくなるべ！
だが、なんでそうなるんだ？
数値として存在しうる全パターンの基底を用意しても圧縮なんてできんぞ。
どうやるの？
DCTも変換しただけでは圧縮なんてできないのに。
855:デフォルトの名無しさん
11/12/04 19:45:03.58 .net
>>852
重要度ってどうやって決めてんの？
856:デフォルトの名無しさん
11/12/04 19:52:30.24 .net
>>854
存在しうる全パターンの基底を用意する意味がよく分からんが。
8x8の各ブロックを、常に3個の基底のみの線形和で十分表現できれば、それだけで3/64になる。
857:デフォルトの名無しさん
11/12/04 19:53:20.99 .net
>>855
だから、頻度でその重要度が決まってんだろ。
人間の目は、たまにしか出現しないものには鈍感になってんだよ。
858:デフォルトの名無しさん
11/12/04 19:54:49.69 .net
>>855
ぶっちゃけ好みの問題。
文字、アニメ絵、写真、CGで、それぞれ変えた方が良い感じになるが、
ほとんどの実装系があんまり気にしないで一般的数値を利用している。
真剣に設定しているのはフォトショップぐらい。
そもそも今時JPEGなんて糞フォーマット、議論する価値もないぞ。
859:デフォルトの名無しさん
11/12/04 20:01:18.37 .net
>>856
＞8x8の各ブロックを、常に3個の基底のみの線形和で十分表現できれば、それだけで3/64になる。
馬鹿か。できるわけないだろ。
860:デフォルトの名無しさん
11/12/04 20:09:43.25 .net
>>859
だから、何故できるわけないのか、理由を答えろよ。
861:デフォルトの名無しさん
11/12/04 20:15:58.64 .net
>>860
何故できないのか、わからないから教えて欲しいのか？
それなら口のきき方を改めろよ。
862:デフォルトの名無しさん
11/12/04 20:17:16.20 .net
>>861
いいから説明してみ？
>>858
あと、これも回答になってない。
量子化係数の逆数と、スペクトル比較してみろよ。
863:デフォルトの名無しさん
11/12/04 20:32:51.64 .net
>>862
＞いいから説明してみ？
尊大な馬鹿に説明してやる義理はないな。
＞量子化係数の逆数と、スペクトル比較してみろよ。
そんなものは画像による。
「DCT後の数値が高い＝重要」ではないの。
平坦な画像では、低周波成分に集中するのと、低周波成分が重要だから
DCT後の数値が高いところと、量子化係数が低いところが、たまたま一致する傾向があるだけ。
DCT後の数値は、大きくても、小さくても、低周波なら重要なんだよ。
数値の大きさで、重要度(量子化テーブルの値)が決まるわけじゃない。
大きいなら大きいなり、小さいなら小さいなりに、「解像度」が必要。
864:デフォルトの名無しさん
11/12/04 21:02:04.86 .net
ここまでおれのじえん
865:デフォルトの名無しさん
11/12/04 21:33:40.43 .net
なんかスレのびてんな。
両者同じこと言ってねーか？
866:デフォルトの名無しさん
11/12/04 23:47:38.83 .net
ま、頭でっかちな子は一度手を動かしてみるといいよ。
そしたら、案外、この2人も仲良くなったりしてな。
867:デフォルトの名無しさん
11/12/05 03:04:34.19 .net
基底を3つ用意して線形和とか言ってるのを除けば、
既存の概念以上の何かを語っているに過ぎないような。
基底の話は、なんだかなぁ
DCTでやるかwaveletでやるかの違いよりもどうでもいい。
868:デフォルトの名無しさん
11/12/05 08:04:31.27 .net
ドザはDCTすら理解できていないことが分かった。
やっぱりLinuxerの方が優秀。
869:デフォルトの名無しさん
11/12/05 14:41:58.73 .net
／ ＼_＿＿＿
⌒ﾞｉ＼ ＼ ＼
. ﾞｉ ＼ ﾞｉ(ﾟ) ﾞｉ ____＼ ー‐┐ 一十一
。., ' ⌒｡ﾞｉ ) ﾞｉ ＼ ﾉ´ ノ |
ｏ｡∴｡ﾟ／／ ┬-､_ ＼ ー‐┐
(∴Ｕ／／ }ﾉ ﾉ ＼ ,> ﾉ´ ─┬─
|Ｕﾞ/ ／ i | l、 く. ー‐┐ |
ー‐┐ 一十一 / u' ＼ヽ‐'´ !| ﾄ､ ＼ ,ﾉ´ ─┴─
ﾉ´ ノ | /_____, }j ハ､ ヽ ヽ,＿＿_/ ／ ー‐┐ ─┬─
ー‐┐ . ／ ___ノ ／＼_,≧/ u 人. ／ ,ﾉ´ ─┴─
ﾉ´ ─┬─ く {上rﾝ´ ,厶..／ ／ ヽヽ ＼ |｜
ー‐┐ | ／ ￣ ノ{こ, ／,〃 !| ＼ ･・ ─┬─
ﾉ´ ─┴─ ＼ ,.ｲ !l｀T´ | / |:| / ..─┴─
ー‐┐ ─┬─ ＼ // l | |_| ∠.、
ﾉ´ ─┴─ ／ ﾋ_ー--､＿|ｰ､____,ノj┘ / ─┬─
ー‐┐ ／ ＼￣＼ー`トｰ-＜ ／ .─┴─
ﾉ´ ─┬─ ＼ ＼ ヽ ＼ ヽ ￣￣|
| | .─┴─ > ＼. ヽ. ヽ ｌ |／l ／| ∧ /＼
･・ ／ ） lヽ ', l、 |／ | / Ｖ
─┬─ ＼ , イ､_,上ﾊ } 小 |/
─┴─ ＼ (乙≧='''"´ ,∠,__ノ/
／ 厶乙iﾌ/
─┬─ く ｀¨¨¨´
─┴─ ＼
870:デフォルトの名無しさん
11/12/05 15:23:01.99 .net
プログラム板だろ
コード書けよ
871:デフォルトの名無しさん
11/12/05 17:59:33.84 .net
～～～～
↑
コード
872:デフォルトの名無しさん
12/01/08 08:51:31.36 .net
DLLを使ってZIP圧縮をするとき
-t mmddyyyy形式で指定日付以降のファイルの圧縮を指定できますが
時間の指定はできないのでしょうか？
-t mmddyyhhmmss とか
-t yyyy-mm-dd-hh-mm-ss とか
やってみましたが、ダメでした。
873:デフォルトの名無しさん
12/01/08 11:00:01.66 .net
DLLに聞けよ
874:デフォルトの名無しさん
12/08/02 16:10:36.61 .net
7zip64.dllって32ビット版と何がちがうん？
875:デフォルトの名無しさん
12/08/02 17:07:01.40 .net
>>874
64bit板として作られている。
876:デフォルトの名無しさん
12/08/03 16:45:31.23 .net
こうなったら体に聞くしかないな
877:デフォルトの名無しさん
12/09/25 23:36:05.02 .net
ハフマンに興味を持って、セジウィック先生の1-3巻購入したんだけど
いまひとつ分らんのです。
奥村先生の本はどんなかんじでしょうか？
まあ、購入するつもりになってるのですが、
圧縮とかハフマンとかの開設は詳しいのでしょうか？
878:デフォルトの名無しさん
12/09/26 06:46:34.26 .net
セジウィック本も、奥村本も、原理は簡単にしか書いてない
同じ実装向けでも、「データ圧縮ハンドブック」あたりだと詳しく載っていたはず。
完全に理論からだと、情報理論の参考書がよい。
「情報源符号化」とか。
879:デフォルトの名無しさん
12/09/28 20:06:55.81 .net
rarを作れるプログラムわどこにあるの?
880:デフォルトの名無しさん
12/09/28 20:33:12.71 .net
>>878
ありがとー
アマで中古が10,000か・・・
881:電脳プリオン 忍法帖【Lv=40,xxxPT】(3+0：5) 【14m】
13/01/27 19:01:23.78 ?PLT(12080).net
∧＿∧
（ ・∀・） 人 ｶﾞｯ
（ つ―-‐-‐-‐-‐-‐○ < >__Λ∩
人 Y ノ. Ｖ｀Д´）/
し（＿） / ←>>127
882:デフォルトの名無しさん
13/04/17 15:30:00.55 .net
ファイルのタイムスタンプをUTCで保存している圧縮フォーマットってないの？
883:デフォルトの名無しさん
13/11/18 17:46:07.95 .net
Z01とかって拡張子のファイルを結合、解凍できるソフトってどんなのがありますか?
884:デフォルトの名無しさん
13/11/18 20:36:22.54 .net
>>883
ソフトウェア板行け
885:デフォルトの名無しさん
14/01/02 03:04:42.98 .net
>>812>>817が恥ずかしすぎるな
886:デフォルトの名無しさん
14/01/03 00:42:03.07 .net
昨今音声認識や画像認識でニューラルネットがもてはやされてるけれど
オートエンコーダーの技術でできた優秀なコーディックってないの？
887:デフォルトの名無しさん
14/04/17 20:40:26.29 WnuPjrTt.net
おまえも東尋坊にでも行けば？
888:デフォルトの名無しさん
14/05/20 11:56:27.03 Y+03zp8V.net
deflateの終端ってどうやって判断するの？
889:デフォルトの名無しさん
14/05/20 13:55:09.80 dsJU0YCN.net
ブロックの先頭1ビットが、最終ブロックかどうかを指してる
890:デフォルトの名無しさん
14/05/20 20:33:29.63 Y+03zp8V.net
そのブロックのヘッダはどう見分ければいいの？
RFC1951見てみたけど全くわからん
891:デフォルトの名無しさん
14/05/21 00:13:57.01 TqDi4OMb.net
最初のブロックは最初の1ビット目
残りのブロックは順次復号していくしかない。
892:デフォルトの名無しさん
14/05/21 00:33:52.29 u1VeI0rj.net
>>891
なるほど ありがとう
コード書かなきゃだめか
893:デフォルトの名無しさん
14/06/17 10:35:41.26 RbI2cI1i.net
1000分の1くらいにまで圧縮できるソフトがあれば便利なのにな。
無謀な意見そのものなのだが。
894:デフォルトの名無しさん
14/06/17 12:17:18.05 Zuw0gcgB.net
情報量について勉強してこい、というのがマジレスかな。
THcompでググれ、というのがお約束。
895:デフォルトの名無しさん
14/06/17 12:56:51.62 Ws1v548F.net
出来たら出来たで、それを前提にしたクソシステムがどっと出てくるから無意味
ＣＰＵ速度や記憶媒体で何度も通った道
896:デフォルトの名無しさん
14/06/18 08:44:02.18 SROYhCqR.net
ディレクトリ名やファイル名にデータ埋め込んでみましたとかな
897:デフォルトの名無しさん
14/06/18 12:18:57.23 csAcA5GD.net
理論的に不可能なことを「出来たら出来たで」とか言うほうが無限倍無意味w
898:デフォルトの名無しさん
14/06/18 12:35:03.67 G43Rg57i.net
>>896
里芋とかそんな名前のソフト無かったっけ
899:デフォルトの名無しさん
14/06/19 15:32:35.10 gduOxxnf.net
質問です
何年か前に話題になったと思うのですが
「圧縮したらサイズが0になった」
みたいな題名で(タイトルはうろ覚え)
NTFSなどのファイルシステムで
ディレクトリ名やファイル名にデータを格納し
ファイルサイズは0にしておくと
ディスク使用容量は0のまま
とかなんとかいうアルゴリズムを
OneDriveやGoogleDriveに適用すると
やはり7GBとか15GBとかの無料枠を
超えずに使い続けることが可能でしょうか？
だれか実験したひととかサイトとかご存知ですか？
900:デフォルトの名無しさん
14/06/19 15:42:50.59 dWoxSXDO.net
実験したこともないしサイトも知らんけど
ランダムな名前でサイズ0の大量のファイルの転送とかは
新手のサイバーテロと捉えられる可能性が高いので自分でやるのは止めとけよ
901:デフォルトの名無しさん
14/06/19 16:19:44.82 wfyUZ16B.net
わざとやってるだろw 「里芋」と、他に適当なフレーズを加えて検索したら
当該ソフトが見つかったけど、実用的な意味は全く無い。
Unixとかでは、ディレクトリのサイズとしてファイル名とかの情報が入ったブロックが
カウントされるけど、Windowsでは0と表示されるから、というだけのお遊び。
ディスクの空き容量は同じように減っていく。
MS-DOS時代に、ディスクの空き容量が倍に見える（だけど、ファイルを作ると、
本来必要な量の倍の量が減っていく）というジョークソフトがあったけど、
そういうのの同類で、実験ないしジョーク以上の意味は無い。
902:デフォルトの名無しさん
14/06/19 18:55:48.69 BRW9+QBS.net
>>901
＞MS-DOS時代に、ディスクの空き容量が倍に見える（だけど、ファイルを作ると、本来必要な量の倍の量が減っていく）というジョークソフト
ほしい！原理は？
903:デフォルトの名無しさん
14/06/19 21:37:22.91 wfyUZ16B.net
原理は、セクタサイズとクラスタサイズを不整合にする....んだと思う。多分。
『近代プログラマの夕』 （単行本）p.99～100に書いてある。ネット検索では見つからない。
一応THcompのジョークの話の次に書いてあるけど、ジョークではないはず。
904:デフォルトの名無しさん
14/08/08 10:44:25.74 vtGL8yip.net
★2ch勢いランキングサイトリスト★
☆ +ニュース
・ 2NN
・ 2chTimes
☆ +ニュース新着
・ 2NN新着
・ Headline BBY
・ Unker
☆ +ニュース他
・ Desktop2ch
・ 記者別一覧
☆ 全板
・ 全板縦断勢いランキング
・ スレッドランキング総合ランキング
☆ 実況込み
・ 2勢
・ READ2CH
・ i-ikioi
※ 要サイト名検索
905:デフォルトの名無しさん
15/07/19 07:35:40.61 U6RW1Bqf.net
奥村本は図書館ないし大学の図書館にあるよな？
906:デフォルトの名無しさん
15/10/18 05:31:09.57 07EIVbsR.net
初めまして。
数ヶ月前にハードディスクからUSBに切り取った動画を復元したいのですが、数ヶ月前という点から復元することは難しいのでしょうか？
パソコンはインターネットをするくらいで初心者です。
よろしくお願いいたします。
907:デフォルトの名無しさん
15/10/18 12:22:51.56 EniZd4JV.net
>>906
スレチ
スレタイの復元はデコードでリカバリーではありません（；＾ω＾）
908:デフォルトの名無しさん
15/10/18 13:02:31.75 Q87slw7q.net
>>906
数か月USBをマウントしてない状態で切り離したままだったら復元出来るかもな