FFTの周波数分解能について

Question

前提・実現したいこと

現在音声を録音し、その音に対してフーリエ変換を行うことで周波数解析を行っています。
1Hzの周波数分解能でデータを取得したかったので、
サンプリングレート44.1kHz,量子化ビット数16ビット,サンプリング点数65336でデータを取得すると、0.67Hzの周波数分解能で取得することができました。

しかし、サンプリングレート44.1kHz,量子化ビット数16ビット,サンプリング点数1024の設定で取得したデータを繋ぎ合わせ、サンプリング点数を先ほどと同じ数まで増やしても、周波数分解能が細かくならず43.06Hzになってしまいます。

この現象について、納得の行く答えが出せず困っています。
もしお分かりなら教えていただけないでしょうか？

イメージ図

![

Comments

[jbpb0]

周波数分解能を具体的にどうやって計算してるのかの情報を提示しないで、計算した結果が変だけど何で？ って聞かれても、他人には分かりません
計算が間違ってるのでしょう、って思うだけです

間違えずに計算したら、周波数分解能は全データ長さの逆数なので、そのデータがもともと一つのデータでも、複数のデータをつないだものでも、全データ長さが同じなら、周波数分解能は同じです

なお、ここでの全データ長さとは、データ数ではなく、単位は時間とか距離とかです
この質問の場合は、音声データの秒数です

> サンプリングレート44.1kHz,量子化ビット数16ビット,サンプリング点数65336でデータを取得すると、0.67Hzの周波数分解能

の場合は、65536/(44.1*1000)秒なので、その逆数の
44.1*1000/65536=0.67Hz
ですね

データがつなげたものだろうと、

> サンプリングレート44.1kHz,量子化ビット数16ビット,サンプリング点数65336

が同じなら、周波数分解能も同じです

【追記】
上記はFFTの場合の話です
FFT結果の周波数は0から始まって等間隔に並びますけど、その周波数の間隔のことを周波数分解能として説明しました

[thkana]

なんだか「分解能」っていう言葉を誤解している気がする。43.06(40.06)ってどういう数字でしょう?
フーリエ変換した結果から「分解能」が導かれることはないと思います。二つの、周波数がdHz異なる正弦波についてフーリエ変換を比較した結果がどう違うか、という形でなら「分解能」になるでしょうけれど。

> データを繋ぎ合わせ、サンプリング点数を先ほどと同じ数まで増やしても
それが同じでないのなら「繋ぎ合わせ」の操作もなにか私の思うものと違っていそうです。「繋ぎ合わせ」とはどうすることでしょう?

[sepasepa]

私の質問が不十分で申し訳ございません。

>43.06(40.06)ってどういう数字でしょう?
この数字は、サンプリング周波数44100、サンプリング定数1024で取得したときの周波数分解能で、以下の式で導きました。
周波数分解能=サンプリング周波数/サンプリング点数=44100/1024=43.06Hz

> それが同じでないのなら「繋ぎ合わせ」の操作もなにか私の思うものと違っていそうです。「繋ぎ合わせ」とはどうすることでしょう?
サンプリング周波数44100、サンプリング定数1024の設定で音声データを1024個取得し、配列に格納します。
この処理をwhileループで回しながら実行し、65536個のデータに達するまで配列に音声データを格納して、繋ぎ合わせるという作業をしています。

補足なのですが、AndroidのAudioRecordを用いて実装しています。

[jbpb0]

> サンプリング周波数44100、サンプリング定数1024で取得したときの周波数分解能で、以下の式で導きました。
周波数分解能=サンプリング周波数/サンプリング点数=44100/1024=43.06Hz

音声データをつながずに、1024個だけでFFT処理した場合は、そうです

つなげてもっと長いデータにしたら、違います

65536個のデータがある時、そのデータがもともと65536個あったのか、それともつなげて65536個になったのかなんて関係無いです

[sepasepa]

丁寧に返信ありがとうございます。

今回の実装は音声データを繋げてFFT処理をしているので、皆さんの意見を聞く限り、私のコードが間違っている確率が高そうです。

もう一度コードを見直してみます。

[jbpb0]

逆の場合を考えてみてください

65536個のデータをそのままFFTした場合の周波数分解能は0.67Hzですよね

では、そのデータを64分割して、それぞれが1024個のデータになりました
それをFFTした場合の周波数分解能は0.67Hzでしょうか？
そんなはずないですよね
1024個のデータなら43.1Hzです
データを64分割したから、周波数分解能は64倍に大きく(粗く)なります

分割してデータ数が減ったら周波数分解能は大きく(粗く)なり、つなげたらその反対

Answer 1

FFT結果の周波数は0から始まって等間隔に並びますけど、質問の「周波数分解能」がその周波数の間隔のことだと解釈して、以下書きます

周波数分解能は全データ長さの逆数なので、そのデータが元々一つのデータでも、複数のデータをつないだものでも、全データ長さが同じなら、周波数分解能は同じです

なお、ここでの全データ長さとは、データ数ではなく、単位は時間とか距離とかです
この質問の場合は、音声データの秒数です

サンプリングレート44.1kHz,量子化ビット数16ビット,サンプリング点数65336でデータを取得すると、0.67Hzの周波数分解能

の場合は、全データ長さが65536/(44.11000)秒なので、周波数分解能はその逆数の
44.11000/65536=0.67Hz
ですね

データがつなげたものだろうと、

サンプリングレート44.1kHz,量子化ビット数16ビット,サンプリング点数65336

が同じなら、周波数分解能も同じです
(量子化ビット数は関係ないけど)

　
【追記】

1Hz毎に振幅が立つような音声を流したとします。

その音声をサンプリング周波数44.1kHz、サンプリング点数1024個で録音し、そのデータを繋げて全データ長65536個にしたとします。
この音声にFFT処理を行った際、周波数分解能通り(0.67Hz)だとある程度特徴を捉えた結果が得られると思う

適切に処理すれば、f特の特徴は分かると思います

下記は1Hzのみの場合で、左が元データ、右がFFT後の振幅です
青線がデータそのままFFT処理した場合で、赤線が窓関数(ハミング窓)を適用してからFFT処理した場合です
どちらの場合も、0.67Hz間隔のデータなので1Hz付近の結果が得られないため、1Hzに近い両側の周波数の振幅が上がっています
窓関数無しの青線はさらに、1Hzから離れた周波数にも、薄いですが広がっています
これは、元データの両端が滑らかに繋がらないないためです
窓関数を用いる理由

下記は1, 2, 3Hzが混在してる場合で、振幅は順番に1, 2, 3です
青線よりも赤線の方がFFT処理結果が比較的真値に近く、特徴をよく捉えています

下記は同じく1, 2, 3Hzですが、振幅が順番に3, 1, 3の場合です
やはり、青線よりも赤線の方がFFT処理結果が比較的真値に近く、特徴をよく捉えています

もっとたくさんの周波数の信号が混ざっていても、窓関数を適用してからFFT処理をすれば、f特の特徴は分かるでしょう

Comments

[sepasepa]

丁寧に解説してくださりありがとうございます。今回はjbpb0さんをベストアンサーにさしていただきますが、回答してくださった皆様本当にありがとうございました。

もしお答えできるならでよろしいのですが、追加で質問です。
1Hz毎に振幅が立つような音声を流したとします。
その音声をサンプリング周波数44.1kHz、サンプリング点数1024個で録音し、そのデータを繋げて全データ長65536個にしたとします。
この音声にFFT処理を行った際、周波数分解能通り(0.67Hz)だとある程度特徴を捉えた結果が得られると思うですが、実際はどうなのでしょうか？

[sepasepa]

分かりやすく実例まで載せて追記していただいて本当にありがとうございます。
おかげさまで疑問が解決できました。

Answer 2

サンプリングの時間間隔、ひいてはサンプリング周波数を考えてみればいいかと
分解能50Hzのデータをいくら集めたところで50Hzのままです

Comments

[sepasepa]

他の人と情報の整合性が取れていないため、少しお待ち下さい。