問題タブ [lossless-compression]

Androidのオーディオファイルを（ロスレス圧縮）圧縮できるAndroidのライブラリまたはその他の方法はありますか。Ps 適切なドキュメントがあるライブラリを参照してください。 bcoz ffmpeg を見つけましたが、使用できませんでした。

テキスト圧縮の Lempel–Ziv–Welch ( LZW ) のWeissman Scoreとは?

Weissman スコアは 1.0 であると想像できますが、それは既に標準的なコンプレッサーであるためです。それとも間違っていますか?

可能な限り最高の圧縮率で 1 分で圧縮するサイズが 500 MB の大きなファイルがあります。これらのアルゴリズムが私の用途に適していることがわかりました。

1. lz4
2. lz4_hc
3. きびきび
4. クイックルズ
5. ブロック

誰かがこれらのアルゴリズムの速度と圧縮率を比較できますか?

私はもともと信号処理でこの質問をしましたが、トピックから外れていました。それで、ここに行きます！

Audacity から記録を 2 回エクスポートしようとしましたが、毎回同じパラメーターとタグを使用しました。結果のファイルには異なるチェックサムがありました。そこで、2 つのファイルの差分を (バイナリとして) 開きました。

私が最初に試したのは、32 ビット フロート PCM を含む wav ファイルでした。ファイル全体で 3 ビットだけが異なっていました。

なりました

私の最初の質問は次のとおりです。これらの 3 つのビットは何に使用されますか?

次に、これと同じ手順をflacファイルで試しました。長くなりすぎるのでここには貼り付けませんが、何が起こったのかというと、ファイルの先頭ではあちこちにわずかな違いしかありませんでしたが、ファイルの奥に行くほど、ファイルが異なっていました。

何故ですか？flac 圧縮アルゴリズムは決定論的ではありませんか?

最後に、16 ビット署名付き PCM を含む wav ファイルを取得し、それを 16 ビット署名付き flac ファイルに変換してから、wav に戻しました。私が取得したファイルは元のファイルと非常に似ていますが、これらのファイルのサンプルからわかるように、データが 33 バイトずれているようです。

元のファイル:

新しいファイル:

なんで？

私は OpenH264 コーデックを使用しています。OpenH264 は、ヘッダー関連情報に Exp-Golomb Coding を使用しています。いくつかの Web サイトを調べて、Exp-Golomb コーディングに関する情報を少し集めました。OpenH264 では、4 種類の Exp-Golomb コーディング方式が使用されます。彼らです：

• 上[数値が非負数のみの場合]
• Te [値が 1 または 0 のみの場合]
• Se [値が負と正の両方の数量の場合]
• Me [値に対して標準コード マップが定義されている場合]

メソッドUeで構築または解析する方法を学びました。

Exp-Golomb(Ue) = [M-Zeros][1][INFO] の構文形式。

構築: Code_Num = 226 があるとし
ます
。M = floor(log2(Code_Num)) = floor(log2(226)) = 7
INFO = Code_Num + 1 - pow(2,M) = 226 + 1 - 128 = 99 = (1100011) in Binary
So,
CodeWord = 0000000 1 1100011 [M-zeros, 1 ignoring bit, INFO]

解析: CodeWord = 000000011100011 があると仮定
Code_Num = pow(2,M) + INFO - 1 = 128 + 99 - 1 = 226

これで、Exp-Golomb(Ue) を計算できます。しかし、Se、Te、Me に関連するすべての理論を学びたいと思っています。しかし、他の方法のリソースを見つけることができません。私を助けてください。

画像 (カラーおよびモノクロ)で構成されるデータセットを圧縮するのに、 [LZW または JBIG の間で]どちらのロスレス圧縮アルゴリズムが適していますか?

私は両方を実装し、[それぞれ 100 枚の画像を含む] より小さなデータ セットでテストしましたが、決定的な結果が得られませんでした。

注意:: 解凍後のデータはソースのデータと同一でなければならないため、Jpeg のような非可逆圧縮は使用できません。解凍を担当するファームウェアでサポートされていないため、PNG のような他のロスレス アルゴリズムも使用できません。

クラスの課題でハフマン圧縮プログラムを作成しています。私はそれを実装する方法を知っていますが、デコーダーはエンコーダーによって保存された変換テーブルを使用するか、ハフマンツリーを最初から作成する必要があるため、完全なハフマンツリーをエンコーダーによってそのまま保存して、デコーダーが再構築する必要がないようにしたかったのです。それ。ポインターを使用して保存することは同じではないことを知ったので、シリアライゼーションが役立つ可能性があることがわかりました。私の主な質問は次のとおりです。

1-シリアライゼーションはツリーをそのまま保存できますか? 2-ツリーを保存すると、変換テーブルを保存して再構築するよりも多くのスペースが必要ですか?

エンコードされたファイルに格納されるツリー データを最小限に抑えたい。ここではプレーンテキスト圧縮について話しています。- ありがとう

私の主なプロジェクトの 1 つは、マイクロコントローラー用のディスプレイ ライブラリです。その一部として、フォント (ビットマップ) とアイコン (アルファ チャネル) のコレクションがあります。

マイクロコントローラではリソース (フラッシュ メモリと RAM) が限られているため、これらのフォントとアイコンのデータを保存するより良い方法を検討しています。

私は、データに分離平面配置を使用することに傾いています (Amiga で使用されている ILBM のように)。つまり、各ピクセルのすべてのビットを一緒に保存する代わりに、画像全体の最初のすべてのビットを一緒に保存し、その後にこれは、2 の累乗ではない画像深度を扱う場合により効率的になります (3 ビット データを 8 ビット データ ストリームにパックしようとしましたか?)。

また、これらの各ビットプレーンを圧縮したいと思います。RLE が最も賢明なようです。しかし、私は現在、整数ではなくビットのストリームを扱っているので、RLE を実装する最善の方法は何かと考えています。

8 のブロックでビットを処理し、繰り返されるバイトを探すという従来の方法に固執することもできます (2 つ以上の同じもの、2 つの同じものに置き換え、続いて実行中の数のカウント)。 1 つのビットプレーンを構成するビット単位のデータに関しては、これは非常に優れています。(ちなみに、ILBM はこのバイト単位のさまざまな方法を使用します。つまり、データを純粋にバイトとして扱い、必要に応じてそれらを繰り返し、次のバイトの処理方法を定義する「ヘッダー」バイトを使用します)。

別の方法は、交互ビットカウント方式を使用することです。つまり、ビットが 0 であると仮定して開始し、実行中のそのビットの数を記録します。次に、1 に切り替えて、実行中の 1 ビットの数を記録します。次に、再び 0 に切り替えて、ビット数を記録します。等。

繰り返しますが、同じビットが長く続く場合は素晴らしいですが、ビットが急速に変化するとすぐに、使用されるスペースが大幅に増加します (たとえば01010101、8 ビットは の 8 バイトになる可能性があります[1,1,1,1,1,1,1,1])。

ここでの主な注意点は、圧縮を解除するための CPU と、解凍中に作業バッファーを保持するためのメモリの両方で、効率的でなければならないということです。そのため、他の方法ではなく RLE を考えています。

だから、私が見逃していたアイデアを探していると思います。単一ビットのストリームを圧縮し、その圧縮データをバイト中心のシステムで表現するための最良の実装は何でしょうか?

グリフの例 (10 進数):

したがって、ビットプレーン 0 ～ 3 は

ただし、このサイズのグリフを圧縮しようとすることさえありそうにありません。意味がないくらい小さいです。ただし、ビットプレーンの階層化と、ビットストリームが元のデータに関連してどのように見えるかを示しています。