音声の可逆圧縮率を上げる方法

音声はLZHとかで圧縮してもほぼ無音にしか影響がでない
既にスレタイのようなユーティリティがいくつかあるが
ここではそのアルゴリズムやさらなる発展をするため語り合うスレだ。

おんなしすれ無かったっけ？　

2げっとしろよ

ha

非可逆mp3みたいなのが一番なんじゃないの？
そういう規格があるのかは知らんけど。

>>1 なぜそんなものが必要なんですか?

mp3でいいんでない?
よほどの音感が良い人でないとmp3と圧縮されていない音声の区別も
付かないと思うよ。クラシック聴いている人とか高級なアンプ、高級なスピーカ
持っている人でないとmp3とそうでない区別は容易ではないよ。

>>1がいいたいシステムは、音声ファイルを再生するときに圧縮された音声ファイルを
その場で解凍してから再生するという仕組みですか?

wma9 で可逆圧縮の規格があったな。
でも、圧縮率は非常に悪い。

>>5
可逆mp3ね。

>>6
自前でシーケンサ書いててピアノ音源とかこだわると容量が洒落にならない。
このドライバを組み込んだアプリやゲームなんかをリリースしたくなった時を考え
やはり圧縮時の容量は軽めにしたい。でmp３だとそれなりにCPUが犠牲になる

今んとこ考えてるのはLZHなどの圧縮アルゴリズムに合わせてデータを最適化するというもの
ごく単純なものだと欄レングスが係り易いように値の近い隣接するデータを統一するとか
その為の判定アルゴリズムの向上とか、要するにWAveのままでどれだけクオリティを
保ったまま単純化できるかしたかった。
別に物凄い圧縮率を期待してたわけではなく、音声だけが余りに縮まないので．．

>>6
>mp3とそうでない区別は容易ではないよ。

言い過ぎ。

FALC サイトの可逆音声圧縮ソフト比較ページ
http://flac.sourceforge.net/comparison.html

>>9 MPEG7やMPEG21(?)を待つのは駄目?

>>9
もしかして、ADPCMを知らないのか？
音質劣化ほとんど無しで、四分の一位になる。

２０年以上前からある非常に有名な技術でつ…。

完全な可逆っていうなら、音声はほとんど乱数を圧縮するのと同じだな。

>>1
圧縮関係は特許が絡んできて面倒だから、フリーで使えるのだとあまり方法が
無いよ。
とりあえず微分してZIPやLZHで圧縮するだけでも、素で圧縮するよりは遥かに
圧縮率が良くなるかと。元の音質がよければ、たぶん2階微分の方がいいと思う。
（2階微分+ハフマンだけでもLZHよりは縮みそうな気がする）

音声を圧縮するには、次の音のレベルを予測する技術が必要だ。
ADPCMなどは、次の音のレベルを現在の音を基準にするので、有効となる。
同じように、現在の音を中心にして考えるのが>>15のような微分の手法。
他には、waveletのように周波数成分に分解して符号化する、
アナログtoディジタル信号変換符号化法のような数値データ圧縮法を
音楽データに流用する方法（数値を2次から3次程度で補間する）、
などがある。

とりあえず、論文嫁。

>>11 ありがとう。いくつかそれっぽいのをダウンロードさせてもらいますた

MPEG7やMPEG21(?)を待つのは駄目？>MPEG99くらいならOK(w

ADPCM＞
それ自体が圧縮だよね。エン／デコーダ書かなきゃならないでしょ
最悪の場合それでもいいと思うけど、Waveそのものの無駄を削るツール
書いた方が後々の為に便利かなと。ハードディスク容量が惜しいわけじゃ無いし

>>15
よく分からないンで勉強してきま〜す
あと、よくよく考えてみたら８ビットにしないまでも１２ー３ビットあたりでも結構行けますね

>>16
スレタイが分かりにくかったようだ。スマソ。
圧縮したいんじゃ無く圧縮の為の最適化がしたかった
極端な話２２khzを４４khzにリサンプルして圧縮しても容量変わらないよね
けどこれだと温室がやヴァいからサンプル落としても差し支えない部分を調べて部分的に
最適化してくれるツールが書きたかったわけです。
どちらにしろ勉強不足な事には変わりナインで休日使って色々やってみるわ。

>>17
圧縮プログラムを書くのと、圧縮しやすいデータに加工するプログラムを書くのと、
大して違いはないと思うのだが。

>>18
まあ考え方はいっしょというわけか。

PCM MeXimizer

>>18
最終的にzipとかlzhとか一般的な圧縮アルゴリズムで効果出さなきゃならんのだから
ADPCMのアルゴリズムやそう言った音声に特化した方法は意味ないだろ

>>20
こんな感じのソフトです。はい。けど悲しい事に私マッカーなんで
今では自作するしか無いんです。
あぽーは突然９erを切り捨てるトか言ってるのでこれを気にウィンにシフト予定ですが

>>9
> やはり圧縮時の容量は軽めにしたい。でmp３だとそれなりにCPUが犠牲になる

mp3もほかの圧縮方式も一緒。
むしろ可逆考えると余計に重くなるよ？

LZHやgzip使うなら、LZ77の圧縮に適した変換にするわけだろ？

同じような波形を持つ部分を、同じ波形に無理やり変形。
そのときの誤差は、別に記録する。

ってのはどうかね？

>>むしろ可逆考えると余計に重くなるよ
どう言う意味？可逆だけでって事？

>>同じような波形を持つ部分を、同じ波形に無理やり変形。
そのときの誤差は、別に記録する
似て非なる部分が多い音声にはやっぱり一番効果的だと思うけど
誤差〜はLZH、zip任せなので無理。判定をうまくやってできるだけ同じ部分を
たくさん作るぐらいだね。

ファイルを適度な大きさで細切れにし
似てる波形が近くになるように並べ替えると良さげ

>>25
誤差の部分は符号化しちゃってもいいんでは？

それよりも、LZHやgzipを後段に使う意味は、どこにあるんだろうか。
前処理が独自の手法ならば、後段に汎用ツール使っても、再生時に独自手法が必要なわけで。
さらに、どちらもLZSS+Huffmanであり、音声圧縮には殊のほか向いていない。
ADPCMか微分してLZHが、一番圧縮率がかせげそうだが、
それ以外のことをするんだったら、wavelet変換してrangecoderにかけた方が、
よっぽど圧縮できて、しかも処理時間はLZHよりよっぽど速い。

>>26
似ているものを近くに並べても圧縮できない罠。
近くに寄せるなら、同じ値が連続するものじゃないと。
それじゃなきゃ、>>24みたいにしてから並び替え。

>>27　前処理が独自の手法ならば、後段に汎用ツール使っても、再生時に独自手法が必要なわけで
だから前処理はあくまでWAVEとしての範囲内だって。
だから並べ替えるとか誤差を別に符号化とか無理でしょ。
完全独自とこのやり方どっちがイイかはおいといて
普通のWaveファイルとして扱えて圧縮しやすいっていうのも遣い所アルと思うんだが

それって可逆でなくない？

フーリエ変換するのとどう違うの？

>>28
似てるものを近くに並べれば圧縮率は高くなるよ
多分、数パーセントしか変わらないだろうが
WAVEのような、圧縮率の低いものには、それでも充分に大きい

>>32
LZH,gzip使うんだろ？
だったら、似ているものを近くに寄せるより、
同じものを作り出したほうがより圧縮率向上。


あと、音声データのコーパス用意してよ>>1
議論だけじゃなく実際にプログラム書いて実験してみるからさ。

>>32
まじっすか。私はフーリエ変換の理解に四苦八苦してる状態です

音声データは別に何でもいいんですが著作権的に大丈夫そうなのを
後でどっかにうpします

>>33でした、すまそ
ttp://rivernet.cool.ne.jp/upload/img/200301191540acg.zip
ttp://rivernet.cool.ne.jp/upload/img/200301191541sim.zip

>>33
可逆なんだから同じ物に戻すには差分ファイルが必要になります
で、その差分ファイルを集めて圧縮した時の圧縮率は
差分ファイルに特徴が出ない限り
似たようなものを集めて圧縮率と、ほぼ同じになります
で、音声のファイルの差分に特徴が出る事は期待出来るかどうかですが
おそらく特徴はあまり出ないと思われます
理由としては、そこで特徴が出るなら
もっと圧縮率の高いツールが世の中に出回ってると思うから(←他力本願)

>>36
LZSSは似たようなものを圧縮することはできないよ。
あくまで、離散的に完全一致部分列が近隣に出現した場合のみ、圧縮できるのだから。
差分ファイルはLZSS以外の手法（算術符号など）でおそらくかなり有効に圧縮できるはず。
なぜなら、似ているデータの差分の差分は、0近辺に偏ることが期待できるため。

>>37
>LZSSは似たようなものを圧縮することはできないよ。
似てるものを集めれば、辞書が一致する可能性が増えるので
それでも、やらないよりは、圧縮に期待が出来ます
>似ているデータの差分の差分は、0近辺に偏ることが期待できるため。
確かに、MIDIなどから規則正しくWAVEに変換したものなら
かなり0方向へ偏る事は期待出来ますが、世の中の音源は
いくら似ていても、差分は、そんなに偏らないと>>36で言ってるのです

それでも差分を使いたいのなら、それまでのデータから次の値を予測し
その予測との誤差を差分にする方が、比較的良いと思われます

>>13
おまえ、おもろいな。

>>39
どこが？

>>40
ADPCM自体は、値を現在値との差分にするだけ。
通常16bitの音声データならば、大体12bit程度になる。
>>13の4分の1程度にすることも可能ではあるが、
それはもともとの量子化ビットを16bitより小さくするのに等しく、劣化が起きる。
ただ、データが非常に単調な場合はADPCMは有効なわけで。

であるがしかし、実はADPCMは数値データ圧縮法の簡易バージョンなのであった。
ADPCMを発展させたような手法が数値データ圧縮法にはたくさんあるので、
いろいろ勉強していきやしょう。

良スレの予感

日本だと可逆圧縮は音声よりも画像が多いが、
waveletやDCTなど、両方に有効な手法も多い。
数値データの圧縮は90年頃盛んで、もう古いよ。
http://search.ieice.org/jpn/2001/abs/j84-a_3_298.htm
http://search.ieice.org/jpn/2002/abs/j85-d2_3_448.htm
http://search.ieice.org/jpn/2000/abs/j83-a_10_1197.htm
http://search.ieice.org/jpn/2001/abs/j84-a_9_1206.htm
http://search.ieice.org/jpn/2001/abs/j84-a_7_893.htm

>>42
つっこみどころ満載ですな

FFTで例えば４点でのDFTを求めたとして
バタフライ演算とかやって最終的にX0~3とか出てきますが
これらはどう言う数字なのでしょうか。
ここから周波数と振幅の表にするにはどうしたらいいですか？

（＾＾）

hoshuage

可逆で圧縮率１００％を発明したら天才

>>48
だから、定義を明確にしろと小(ry

圧縮率100%とは、元データと全く同じサイズのデータを吐き出すということ。
ある条件のもとでそれは常に成り立つ。

圧縮率100%とは、ファイルサイズを0にすること。
これは理論的には成り立つが、実際には不可能。

圧縮率100%とは、ファイルサイズを半分にすること。
これは最近のMediaPlayerに実装された可逆圧縮が平均で達成するね。

圧縮率100%とは、ファイルサイズが２倍になること。
これは可能。

自分で考えたつもりでも、先人がいると
特許がらみで自由に使えなくなるって面倒だよな・・。

>>50
つまり一度文明を滅ぼせと・・・

>>51
特許制度だけでいいんじゃ？

時系列順に並んだPCMを可逆圧縮して、圧縮率を高めようってのは
無理だね。
楽曲となるとパターンがすげーランダムだから既存の方法だとモデル化が難しい。
つまりエントピー下げるの無理。

>>41
dpcmとadpcmの違いがわかってない様子

>>49
ファイルサイズを0にするのは
全てのデータをファイル名に含ませたりする事で可能
つーわけで、正しくは情報量だね

>55
なにが「つーわけで」なの？
ファイル名に使えるサイズは高々256byte程度なんですが。

>>56
ﾌﾟ

凡人には出来ないから安心しろ

役に立たんスレだな。

汎用ので可逆圧縮するならデジコがいい感じにょ

>>60
それだ！！

>>41
ADPCMは適応予測が入るから意味が有るんだよ。

>>1
非可逆じゃないけれど、A-LawやμｰLaw変換してやると2/3くらいになるよ。
音質もさほど変わらんし。
どうしても可逆じゃなくちゃいかんのなら
・波形が下降している場合は次も下降する可能性が高い
・同じく波形が上昇している場合は次も上昇する可能性が高い
等のコヒーレンスを考慮した適応型のハフマン圧縮が比較的有効だと思う。
コード書いた事ないからどれくらい圧縮できるか知らんけれど。

DPCMはただの1次微分で、
ADPCMは2次微分の変形だね。

Windowsだったら、ADPCMやμ-Law形式のWAVってそのまま再生できるんじゃないの?
デフォルトでオーディオCODECに入ってたような気がするんだが。

ちゅうか実数演算かました時点で誤差丸めが発生するから可逆には、ならん罠。
可逆が条件になると、DCTもDFTも使えないな。

>>63
＞Windowsだったら、ADPCMやμ-Law形式のWAVってそのまま再生できるんじゃないの?
＞デフォルトでオーディオCODECに入ってたような気がするんだが。

それはそうかも知れんが、>>1はマカーだから、困るのとちゃう？
μ則の変換/逆変換なんざテーブル持たせれば実時間で演算可能だから、特に問題ないかと…

マカ−って死滅しちゃうの？

>>64
可逆DCT, DFT を使えばよいのではないだろうか。

>>65
CODECを作れば今回は耐えられそうです。

>>66
> 可逆DCT, DFT を使えばよいのではないだろうか。
確かに。しかし性能出す事は茨の道でもあったりする。ガンバレ！

可逆でコサイン・フーリエ変換しても、圧縮が全然できない罠。
画像のLOCO-Iみたいに、音声でも可逆圧縮特有の方法を探さないと。

鏡像圧縮。
プラスはそのまま、マイナスはx_max/2プラス方向にシフトさせてmaxから始まり
maxに終る波形に整形する事により、1/2に圧縮可能。
デコードはminからmaxへの微分値極大を検出して判定して行う。
前提としてナイキスト周波数以下にLPFをかけたような、微分値極大が発生しない
元データであることが必要。

特許とろうとしたら既に先行技術であった（泣

おとなしくラグランジュ補間でもしてもけもけ

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

ほしゅあげ

一回微分してマルコフ情報源と看做すって程度で良いんでは。

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

議論再開を願ってからあげ

ほしゅ

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

　__∧＿∧_
　|（　　＾＾ ）|
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　

（＾＾）

>>45　（その１）
４点ＦＦＴの結果に関して、
Ｘ０　：　ＤＣ成分
Ｘ１　：　４ポイントで１周期となる正弦波に対する相関結果
　　　　（例えば、１ＫＨｚサンプリング時の場合、２５０Ｈｚの成分）
Ｘ２　：　４ポイントで２周期となる正弦波に対する相関結果
　　　　（例えば、１ＫＨｚサンプリング時の場合、５００Ｈｚの成分）
Ｘ３　：　４ポイントで３周期となる正弦波に対する相関結果
　　　　（例えば、１ＫＨｚサンプリング時の場合、６６６Ｈｚの成分
　　　　　但し、１ＫＨｚサンプリングにより再現できる周波数は
　　　　　５００Ｈｚｍａｘなので、Ｘ３は折り返し成分になる？
　　　　　／４ポイントのデータで３周期の正弦波は表現できない）

>>45 （その２）
　フーリエ変換自体は、正弦波（余弦波）に対する相関演算ですが、もし、
単一の位相の正弦波に対して相関演算をすると、位相が９０度ズレた
信号が入力された場合、相関結果が零となってしまいます。
　これを避けるため、フーリエ変換では、９０度異なる位相を持つ２つの正弦波
（余弦波と正弦波）との相関演算を行い、実部（余弦波に対する相関結果）、
と虚部（正弦波に対する相関結果）を組み合わせた複素数の形で結果を
出すようです。

　このため、各出力の複素数の絶対値（二乗平均）を取ることにより、
各成分の大きさを得ることができます。
　また、複素数の実部と虚部のアークタンジェントを取ることにより、
各成分の位相情報を得ることができます。

　尚、ポイント数で周期が完結しない信号を与えた場合には、全出力に
誤差が乗るので、その影響を抑えるために窓関数などというものが
使われるのは、教科書に載っている通りです。

　先に申しましたように、高いほうの約半分のデータ（１０２４ポイントの場合、
Ｘ５１３〜Ｘ１０２３）はスペクトラム情報としては使えないのではないかと
思います。

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

おとなしくラグランジュ補間でもしてもけもけ

今、ＰＣＭ形式を解読してるんだけど、

サンプルレート　8 kHz
サンプルサイズ　8 bit
チャネル　1
ビットレート　PCM

で録音して、バイナリエディタで開いたところ、

00000000: 5249 4646 89c2 4b01 0057 4156 4566 6d74 RIFF..K..WAVEfmt
00000010: 2012 0000 0001 0001 0040 1f00 0040 1f00 ........@...@..

最初の 5249 4646(RIFF) 89...の89が何かがわからないんです。
これはなんなのでしょうか？

×ビットレート　PCM
○ビットレート　64kbps

説明不足・・・です。

ファイルサイズは　84,938byteで　C24B 0100 (84,938 - 8 byte)となります。

5249 4646 <<???89???>>（c2 4b01 00）57 4156 4566 ...

>>84
|∀･)ﾉ゛　ttp://member.nifty.ne.jp/Ryuz/programing/wavefmt.html

ん？ちょっとマテ。確かに変だな？なにこれ？

サンプルレート　22 kHz
サンプルサイズ　8 bit
チャネル　1
ビットレート　176kbps

でやると、


00000000: 5249 4646 121a 0100 5741 5645 666d 7420 RIFF....WAVEfmt
00000010: 1200 0000 0100 0100 2256 0000 2256 0000 ........"V.."V..

不明なバイナリはなくなってます。これは一体・・・

サンプルレート　8 kHz
サンプルサイズ　8 bit
チャネル　1
ビットレート　64kbps

で数ファイル調べてみたのですが、89が付くやつと付かないやつがあります。
キモちわるー

ちなみに、

00000000: 5249 4646 89a2 89da 0000 5741 5645 666d RIFF......WAVEfm
00000010: 7420 1200 0000 0100 0100 401f 0000 401f t ........@...@.

89と来てa2まで付いてる･･･。

あ、スレ消費ｽﾏｿ

原因？わかりました

Meadowのhexlモードで開くと

00000000: 5249 4646 89a2 89da 0000 5741 5645 666d RIFF......WAVEfm
00000010: 7420 1200 0000 0100 0100 401f 0000 401f t ........@...@.

なのが、

Stirlingで開くと

52 49 46 46 A2 DA 00 00 57 41 56 45 66 6D 74 20
12 00 00 00 01 00 01 00 40 1F 00 00 40 1F 00 00

同じファイルなのに。。。

Meadowのhexl-modeはおかしい？？？という結論

一応age

そのファイルどっかにあげてくれ。
あと、hexl-find-fileでも同じかね？

★★★無修正DVDの老舗★★★　★★★復活★★★
ペントハウス10月号で徹底検証　★加藤iの★　全裸盗撮DVD鮮明画像原版入荷
新宿歌舞伎町店頭価格10,000円の品　他商品と同価格　★★★4枚１０，０００円★★★
　　　商品映像確認後の★完全アト払い★　ダマしよう無し
同時入荷　　★朝河　蘭　新作　　★D-MODE20　白石ひより　　
　　　　　　★援交ハメ撮り　品薄入手困難なNo．３・５・８
　　　　　　★女子高生拉致監禁飼育シリーズ　小雪・桃井望　
　　
： http://go.fc2.com/yamazaki/

　　　　　及川奈央　堤さやか　長瀬愛　も依然バカ売れ
　サンプル画像充実　日本一安い、安心、確実。歌舞伎町店頭販売10年の
　実績と信用と★検挙回数★の多さ？　　ご覧下さい。　★★★自信有ります。★★★
　　　　　　　　　　　　
http://go.fc2.com/yamazaki/

フラクタル

既出ではないようなので。
圧縮しやすいように音声を変形させるだけなら、
一度64kbps WMAにでもして可逆WMAにすればいいでしょ。

MUSE

◆1haVRB54HY は放置でお願いします＞各位

ぬるぽ

a

>>101
ガッ


ついでに唐揚げうまうま

【技術/IT】データ量を200分の１以下に圧縮する音声映像圧縮技術
http://news16.2ch.net/test/read.cgi/scienceplus/1093621474/l50
*******
ＪＧＳ、音声や映像の圧縮技術を開発――データ量を200分の１以下に

　ソフト開発のジェイジーエス（東京・文京、里見和彦社長）は音声などのデータ量を
200分の１以下に圧縮できる技術を開発した。音や映像を波形データとしてとらえ、数式
に変換することで圧縮比率を高めた。ソフト会社や携帯端末メーカーなどに売り込む。

　開発した圧縮技術の名称は「ＭＹＣ（マイク）」。元データを波の変化としてとらえ、
約50種類の数式を活用してデータ量が最も少ない数式に変換する。映像データも色や輝度
などの変化を数式に置き換え、圧縮する。プログラムに学習機能を持たせており、似た
データは次回以降、さらに効率的に圧縮できる。

情報システムニュース/日経産業新聞　8月25日
http://bizplus.nikkei.co.jp/genre/it/index.cfm?i=2004082408456b7

株式会社ジェイジーエス　高度技術研究室　MYCプロジェクト
http://www.jgs-g.co.jp/hdtl/myc/index.html

*****
どうよ？

すまん。自分誘導。

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

の方でやってますた。