タグ付けされた質問 「data-compression」

2
算術コーディングへのハフマンコーディングの一般化はありますか？
ハフマン符号化、算術符号化、および範囲符号化の関係を理解し​​ようとするとき、ハフマン符号化の欠点が分数ビットパッキングの問題に関連していると考え始めました。 つまり、シンボルに240の可能な値があり、これをビットにエンコードする必要がある場合、8は256の可能な値を表すことができるため、「フル」8は必要ないとしても、シンボルごとに8ビットでスタックすることになります。シンボルごと。この問題の解決策は、「フラクショナルビットパッキング」と呼ばれるもので、乗算を使用して2のべき乗ではない「ビットシフト」が可能です。2のべき乗の乗算がシフトするのx * 2 == x << 1と同じようにx * 4 == x << 2、2のべき乗すべてに対して同様に続きます。そのため、代わりに乗算することにより、2のべき乗でない値で「シフト」し、小数ビットサイズのシンボルにパックできます。 。 この問題はハフマンコーディングと同様です。結局、長さが小数ビットサイズでなければならないコードが作成されるため、このパッキング効率は低くなります。ただし、フラシトンビットパッキングのソリューションは、固定サイズのシンボルを想定しているため、単に使用することはできません。 問題は、算術コーディングに似たものを達成するために、フラクショナルビットパッキングと同様のアイデアでハフマンコーディングを改善するための論文や解決策はありますか？（または反対の結果）。
1
線形時間での圧縮/エンコードについて
私はNJ Larsson、A. Moffat：Offline Dictionary-Based Compressionの論文を読んでいます。これは、私が正しく理解していれば、バイトペアエンコーディングに非常に似ている圧縮アルゴリズムについて説明しています。 長さnの文字列が与えられた場合、この圧縮方法を使用して線形O（n ）時間で圧縮する方法を理解しようとしています。これはどのように正確に行われますか？私はこの論文を読みましたが、どのようにして線形時間を達成するのかまだ理解していません。そのため、別の方法で説明されているのかもしれません。SSSnnnO(n)O(n)\mathcal O (n) 私の最初の混乱は、アルゴリズムの最初のステップで発生します。たとえばabcababcabc、最も一般的なペアabが新しいシンボルに置き換えられる場合などXcXXcXcです。最も一般的なペアをすばやく見つける方法がわかりません。私の素朴なアプローチは、最初のペアabを最初に見て、bc発生数を数え、次に次のペアを見て、発生数を数えるなどです。しかし、これは、最も多くを見つけるためだけにすでに与えます。共通のペア1回。O(n2)O(n2)\mathcal O (n^2) 次に、時間で最も一般的なペアを見つける方法を理解したとしても。私の次の問題は、O（n ）回までの最も一般的なペアを見つける必要がないかということです。したがって、これはO（n 2）の合計時間を与えますか？O(n)O(n)\mathcal O(n)O(n)O(n)\mathcal O(n)O(n2)O(n2)\mathcal O(n^2)
1
MP3エンコーダーが心理音響モデルを適用する前に高速フーリエ変換を使用するのはなぜですか？
Karlheinz Brandenburgは、次のようなMP3エンコーダーを示しています。 出典：MP3およびAACの説明 FFTを実行する必要がある理由がよくわからないので、FFTにマークを付けました。FFTを実行せずに修正離散コサイン変換（MDCT）を実行した後、心理音響モデルをいわゆるラインに適用できないのはなぜですか？ 周波数分解能が十分に正確ではないと言って、ここにいくつかの文献があります。これは、元の信号を（フィルターバンクやMDCTのように）576ラインに分割することは、心理音響モデルが適切に機能するのに十分正確ではないことを意味しますか？FFTはより正確ですか？
5
base 80を使用したファイルの圧縮
80ベースの番号である独自の番号付けシステムを使用してファイルサイズを圧縮したいのですが、これが可能かどうかを本当に知りたいのですか？16進数はA、B、C、D、E、Fのような記号を使用して10、11、12、13、14、15を表すことを学びました-そしてそれは私が自分の番号付けシステムにしたいのですが、より大きなスケールで。何か不足している場合は修正してください。 出来ますか ？
4
すべての入力メッセージを圧縮できる圧縮アルゴリズムはありませんか？
Guy E. Blellochによる、Introduction to Data Compressionという本を読み始めました。1ページ目で、彼は次のように述べています。 真実は、1つのメッセージがアルゴリズムによって短縮された場合、他のメッセージを長くする必要があるということです。これを実際に確認するには、GIFファイルでGZIPを実行します。実際、さらに進んで、固定長の一連の入力メッセージについて、1つのメッセージが圧縮されている場合、すべての可能な入力にわたる圧縮メッセージの平均長は、常に元のメッセージよりも長くなることを示すことができます。入力メッセージ。 たとえば、8つの可能な3ビットメッセージを考えてみます。1つが2ビットに圧縮されている場合、2つのメッセージが4ビットに拡張されなければならず、平均で3 1/8ビットになることを理解するのは難しくありません。 本当に？それを自分に納得させるのはとても難しいと思います。実際、これが反例です。3ビットの文字列を入力として受け入れ、次の出力にマップするアルゴリズムを考えます。 000 -> 0 001 -> 001 010 -> 010 011 -> 011 100 -> 100 101 -> 101 110 -> 110 111 -> 111 だからあなたはそこにいます-入力はより長い出力にマッピングされていません。確かに4ビットに拡張された「2つのメッセージ」はありません。 それで、著者は正確に何を話しているのですか？私には明らかではないいくつかの暗黙の警告があるか、または彼はあまりにも抜本的な言語を使用しているのではないかと思います。 免責事項：私のアルゴリズムを繰り返し適用すると、実際にデータが失われることを理解しています。入力110に2回適用してみてください。110-> 000-> 0であり、110と000のどちらが元の入力であったかがわかりません。ただし、一度だけ適用すると、私にとっては無損失のようです。それは著者が話していることに関連していますか？
4
「実際に発生するビット文字列はランダムにはほど遠い」ので、圧縮関数は実用的です。
これは、このスレッドでのAndrej Bauerの回答に関係しているので、コメントしました。しかし、私はそれは質問の価値があると信じています。 Andrejは、長さが3以下のすべてのビット文字列のセットが与えられた場合、ロスレス圧縮関数はそれらの一部のみを「圧縮」できると説明しています。その他、たとえば「01」は、実際には「0001」などの長さ4の文字列に圧縮する必要があります。圧縮率は、単に入力セット全体の平均圧縮です。 このため、可逆圧縮は実用的ではないように見えますが、重要な引用は次のとおりです。 実際に発生するビット文字列はランダムではなく、多くの規則性を示します。 たとえば、マルチメディアファイルがランダムなビット文字列以外のもので表現されているとは信じがたいです。アルゴリズムが実際に役立つようにするために圧縮関数が活用するパターンは本当にありますか？
2
配列の最小限の説明を見つける方法は？
次の配列は、メモリ内の10000スロットを占有します。 a = [0,1,2,3,4,5,6,7,8,9,10,...,10000] しかし、同じ配列を次のように簡単に表すことができます。 a = {len:10000, get: λ idx -> idx} はるかにコンパクトです。同様に、コンパクトに表現できる配列がいくつかあります。 a = {a:1000, get: λ idx -> idx * 2} Is a description for [0,2,4,6,8,10,...,2000] a = {a:1000, get λ idx -> idx ^ 2} Is a description for [0,1,2,4,9,...1000000] And so on... 非常に多くの配列を提供すると、各要素をメモリに格納するよりもはるかに短い方法で表現できます。 この現象に名前はありますか？ 特定の配列の最小表現を見つける方法はありますか？ …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.