5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

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

2 :デフォルトの名無しさん:03/01/18 05:29
おんなしすれ無かったっけ? 

3 :デフォルトの名無しさん:03/01/18 05:38
2げっとしろよ

4 :デフォルトの名無しさん:03/01/18 05:59
ha

5 :デフォルトの名無しさん:03/01/18 08:24
非可逆mp3みたいなのが一番なんじゃないの?
そういう規格があるのかは知らんけど。

6 :デフォルトの名無しさん:03/01/18 11:45
>>1 なぜそんなものが必要なんですか?

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

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

7 :デフォルトの名無しさん:03/01/18 13:35
wma9 で可逆圧縮の規格があったな。
でも、圧縮率は非常に悪い。

8 :デフォルトの名無しさん:03/01/18 15:18
>>5
可逆mp3ね。

9 :デフォルトの名無しさん:03/01/18 15:51
>>6
自前でシーケンサ書いててピアノ音源とかこだわると容量が洒落にならない。
このドライバを組み込んだアプリやゲームなんかをリリースしたくなった時を考え
やはり圧縮時の容量は軽めにしたい。でmp3だとそれなりにCPUが犠牲になる

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

10 :デフォルトの名無しさん:03/01/18 16:42
>>6
>mp3とそうでない区別は容易ではないよ。

言い過ぎ。

11 :デフォルトの名無しさん:03/01/18 17:41
FALC サイトの可逆音声圧縮ソフト比較ページ
http://flac.sourceforge.net/comparison.html

12 :デフォルトの名無しさん:03/01/18 20:34
>>9 MPEG7やMPEG21(?)を待つのは駄目?

13 :デフォルトの名無しさん:03/01/18 21:03
>>9
もしかして、ADPCMを知らないのか?
音質劣化ほとんど無しで、四分の一位になる。

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

14 :デフォルトの名無しさん:03/01/18 21:12
完全な可逆っていうなら、音声はほとんど乱数を圧縮するのと同じだな。

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

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

とりあえず、論文嫁。

17 :デフォルトの名無しさん:03/01/18 23:26
>>11 ありがとう。いくつかそれっぽいのをダウンロードさせてもらいますた

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

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

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

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


18 :デフォルトの名無しさん:03/01/18 23:41
>>17
圧縮プログラムを書くのと、圧縮しやすいデータに加工するプログラムを書くのと、
大して違いはないと思うのだが。

19 :デフォルトの名無しさん:03/01/18 23:47
>>18
まあ考え方はいっしょというわけか。

20 :デフォルトの名無しさん:03/01/18 23:49
PCM MeXimizer

21 :デフォルトの名無しさん:03/01/19 01:00
>>18
最終的にzipとかlzhとか一般的な圧縮アルゴリズムで効果出さなきゃならんのだから
ADPCMのアルゴリズムやそう言った音声に特化した方法は意味ないだろ

22 :デフォルトの名無しさん:03/01/19 01:08
>>20
こんな感じのソフトです。はい。けど悲しい事に私マッカーなんで
今では自作するしか無いんです。
あぽーは突然9erを切り捨てるトか言ってるのでこれを気にウィンにシフト予定ですが

23 :デフォルトの名無しさん:03/01/19 01:11
>>9
> やはり圧縮時の容量は軽めにしたい。でmp3だとそれなりにCPUが犠牲になる

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

24 :デフォルトの名無しさん:03/01/19 01:26
LZHやgzip使うなら、LZ77の圧縮に適した変換にするわけだろ?

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

ってのはどうかね?

25 :デフォルトの名無しさん:03/01/19 02:11
>>むしろ可逆考えると余計に重くなるよ
どう言う意味?可逆だけでって事?

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



26 :デフォルトの名無しさん:03/01/19 02:21
ファイルを適度な大きさで細切れにし
似てる波形が近くになるように並べ替えると良さげ

27 :デフォルトの名無しさん:03/01/19 02:26
>>25
誤差の部分は符号化しちゃってもいいんでは?

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

28 :デフォルトの名無しさん:03/01/19 02:28
>>26
似ているものを近くに並べても圧縮できない罠。
近くに寄せるなら、同じ値が連続するものじゃないと。
それじゃなきゃ、>>24みたいにしてから並び替え。

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

30 :デフォルトの名無しさん:03/01/19 03:31
それって可逆でなくない?

31 :デフォルトの名無しさん:03/01/19 03:52
フーリエ変換するのとどう違うの?

32 :デフォルトの名無しさん:03/01/19 04:29
>>28
似てるものを近くに並べれば圧縮率は高くなるよ
多分、数パーセントしか変わらないだろうが
WAVEのような、圧縮率の低いものには、それでも充分に大きい

33 :デフォルトの名無しさん:03/01/19 14:46
>>32
LZH,gzip使うんだろ?
だったら、似ているものを近くに寄せるより、
同じものを作り出したほうがより圧縮率向上。


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

34 :デフォルトの名無しさん:03/01/19 15:13
>>32
まじっすか。私はフーリエ変換の理解に四苦八苦してる状態です

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

35 :デフォルトの名無しさん:03/01/19 15:43
>>33でした、すまそ
ttp://rivernet.cool.ne.jp/upload/img/200301191540acg.zip
ttp://rivernet.cool.ne.jp/upload/img/200301191541sim.zip

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

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

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

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

39 :デフォルトの名無しさん:03/01/20 16:16
>>13
おまえ、おもろいな。

40 :デフォルトの名無しさん:03/01/20 19:17
>>39
どこが?

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

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

42 :デフォルトの名無しさん:03/01/20 22:47
良スレの予感

43 :デフォルトの名無しさん:03/01/20 23:02
日本だと可逆圧縮は音声よりも画像が多いが、
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

44 :デフォルトの名無しさん:03/01/21 00:23
>>42
つっこみどころ満載ですな



45 :デフォルトの名無しさん:03/01/22 00:51
FFTで例えば4点でのDFTを求めたとして
バタフライ演算とかやって最終的にX0~3とか出てきますが
これらはどう言う数字なのでしょうか。
ここから周波数と振幅の表にするにはどうしたらいいですか?

46 :山崎渉:03/01/23 20:11
(^^)

47 :デフォルトの名無しさん:03/01/28 00:29
hoshuage

14 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)