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

48 :デフォルトの名無しさん:03/02/13 17:19
可逆で圧縮率100%を発明したら天才

49 :ひまだからあげ:03/02/15 00:25
>>48
だから、定義を明確にしろと小(ry

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

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

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

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

50 :デフォルトの名無しさん:03/02/15 00:29

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



51 :よい子は実行しないでください:03/02/17 10:14
>>50
つまり一度文明を滅ぼせと・・・

52 :デフォルトの名無しさん:03/02/17 12:37
>>51
特許制度だけでいいんじゃ?

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

54 :デフォルトの名無しさん:03/03/04 04:59
>>41
dpcmとadpcmの違いがわかってない様子

55 :デフォルトの名無しさん:03/03/04 05:01
>>49
ファイルサイズを0にするのは
全てのデータをファイル名に含ませたりする事で可能
つーわけで、正しくは情報量だね

56 :デフォルトの名無しさん:03/03/04 05:28
>55
なにが「つーわけで」なの?
ファイル名に使えるサイズは高々256byte程度なんですが。

57 :デフォルトの名無しさん:03/03/04 05:48
>>56
プ

58 :デフォルトの名無しさん:03/03/06 09:45
凡人には出来ないから安心しろ

59 :デフォルトの名無しさん:03/03/16 10:31
役に立たんスレだな。

60 :デフォルトの名無しさん:03/04/03 18:40
汎用ので可逆圧縮するならデジコがいい感じにょ

61 :デフォルトの名無しさん:03/04/05 22:02
>>60
それだ!!

62 :デフォルトの名無しさん:03/04/05 22:24
>>41
ADPCMは適応予測が入るから意味が有るんだよ。

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

63 :デフォルトの名無しさん:03/04/06 03:21
DPCMはただの1次微分で、
ADPCMは2次微分の変形だね。

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

64 :デフォルトの名無しさん:03/04/07 01:53
ちゅうか実数演算かました時点で誤差丸めが発生するから可逆には、ならん罠。
可逆が条件になると、DCTもDFTも使えないな。

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

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

65 :デフォルトの名無しさん:03/04/07 23:23
マカ−って死滅しちゃうの?

66 :デフォルトの名無しさん:03/04/08 01:49
>>64
可逆DCT, DFT を使えばよいのではないだろうか。

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

67 :デフォルトの名無しさん:03/04/08 01:53
>>66
> 可逆DCT, DFT を使えばよいのではないだろうか。
確かに。しかし性能出す事は茨の道でもあったりする。ガンバレ!

68 :デフォルトの名無しさん:03/04/08 23:31
可逆でコサイン・フーリエ変換しても、圧縮が全然できない罠。
画像のLOCO-Iみたいに、音声でも可逆圧縮特有の方法を探さないと。

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

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

70 :デフォルトの名無しさん:03/04/09 01:38
おとなしくラグランジュ補間でもしてもけもけ

71 :山崎渉:03/04/20 04:35
   ∧_∧
  (  ^^ )< ぬるぽ(^^)

72 :デフォルトの名無しさん:03/05/08 02:14
ほしゅあげ

73 :デフォルトの名無しさん:03/05/08 11:56
一回微分してマルコフ情報源と看做すって程度で良いんでは。


74 :山崎渉:03/05/28 13:06
     ∧_∧
ピュ.ー (  ^^ ) <これからも僕を応援して下さいね(^^)。
  =〔~∪ ̄ ̄〕
  = ◎――◎                      山崎渉

75 :デフォルトの名無しさん:03/05/31 01:28
議論再開を願ってからあげ

76 :デフォルトの名無しさん:03/06/25 01:28
ほしゅ

77 :山崎 渉:03/07/15 15:23

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

78 :デフォルトの名無しさん:03/07/20 02:10
 __∧_∧_
 |(  ^^ )|
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|  

79 :山崎 渉:03/08/02 02:30
(^^)

80 :デフォルトの名無しさん:03/08/12 23:13
>>45 (その1)
4点FFTの結果に関して、
X0 : DC成分
X1 : 4ポイントで1周期となる正弦波に対する相関結果
    (例えば、1KHzサンプリング時の場合、250Hzの成分)
X2 : 4ポイントで2周期となる正弦波に対する相関結果
    (例えば、1KHzサンプリング時の場合、500Hzの成分)
X3 : 4ポイントで3周期となる正弦波に対する相関結果
    (例えば、1KHzサンプリング時の場合、666Hzの成分
     但し、1KHzサンプリングにより再現できる周波数は
     500Hzmaxなので、X3は折り返し成分になる?
     /4ポイントのデータで3周期の正弦波は表現できない)




81 :デフォルトの名無しさん:03/08/12 23:14
>>45 (その2)
 フーリエ変換自体は、正弦波(余弦波)に対する相関演算ですが、もし、
単一の位相の正弦波に対して相関演算をすると、位相が90度ズレた
信号が入力された場合、相関結果が零となってしまいます。
 これを避けるため、フーリエ変換では、90度異なる位相を持つ2つの正弦波
(余弦波と正弦波)との相関演算を行い、実部(余弦波に対する相関結果)、
と虚部(正弦波に対する相関結果)を組み合わせた複素数の形で結果を
出すようです。

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

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

 先に申しましたように、高いほうの約半分のデータ(1024ポイントの場合、
X513〜X1023)はスペクトラム情報としては使えないのではないかと
思います。


82 :山崎 渉:03/08/15 15:37
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

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

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

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