簡介

2021年7月13日，我和我的三個研究生一起拜訪了玉米樹，和王總等一起針對睡眠音頻分割及識別問題進行了深入的討論，達成了如下共識。

輸入

由于保存整個晚上的睡眠音頻所需要的存儲空間過大，目前擬采用每隔30分鐘（可自定義）錄制一段睡眠音頻，然后對這段音頻進行分割及識別，并保存鼾聲、夢話等片段。
選擇30分鐘作為時間片段，主要基于存儲空間的考慮，下面對存儲空間進行分析。
30分鐘單通道、16位采樣位數、采樣頻率44.1kHz音頻的不壓縮數據存儲量計算方法如下：
每秒44100個采樣點，44100 * 2=88200字節，30分鐘：30 * 60 * 88200=158760000字節
158760000/1024/1024 約等于150MB。

輸出

（1）一些睡眠事件的開始和結束時間，比如鼾聲、夢話、翻身、咳嗽、打噴嚏、磨牙及其它；

• 開始和結束時間有兩種方式來表示，第一種方式是以事件為基礎（時間不定長），第二種方式是以固定時間段為基礎（時間定長，用戶設定），到底采用哪種方式需要進一步討論；
• 如果采用以事件為基礎，則涉及到音頻片段合并策略；
  （2）這些睡眠事件對應的標簽分布。

方案

采用的方案包括音頻分割及識別兩個方面。

分割策略

策略一：對音頻按等時長進行分割，如每隔4s（可自定義），然后對分割后的音頻進行識別，如果是靜默音，則不保存；

優點：計算資源要求較低；
缺點：容易漏測或者多測，預測精度較低。比如在第3s開始打鼾，預測時第一個窗口被認定為鼾聲，這會導致0~4s都認為是鼾聲。

策略二：采用滑動窗口進行分割，如窗口大小為4s(可自定義)，步長為1s(也可自定義，一般要小于窗口長度)，對每個窗口執行預測，若為目標檢測事件，則記錄開始時間與結束時間。

優點：這種策略分割的音頻就會有重疊部分，可以更好的檢測音頻事件的開始位置；
缺點：音頻重復參與運算，計算資源要求較高。
準備對兩個策略進行對比實驗后，再決定最終方案選擇哪個策略。

識別方法

擬采用PANN框架（YouTube）進行識別，面臨的問題有：
（1）睡眠聲音識別后大致劃分為鼾聲、夢話、翻身、咳嗽、打噴嚏、磨牙、其它幾個大類；
（2）在PANN框架中有527個音頻類別，但沒有翻身、夢話、磨牙等我們需要的類別。
（3）夢話的形式較多，可能包括尖叫、呻吟、普通說話聲、嗡嗡聲等復雜聲音，不太確定能歸為527個類別中哪些類。
（4）如何平滑連續音頻的問題，我們認為連續音頻之間具有某種關聯性，如何刻畫這種關聯性呢？（可以作為研究生發表論文的方向）
擬采用如下方法來解決：
（1）音頻獲取：從網絡上獲取翻身、夢話、磨牙等音頻，如freesound.org；如果網絡上沒有，則需要我們自己來錄制這些音頻；
（2）解決標簽不匹配問題：基于獲取到的翻身、夢話、磨牙等音頻，利用PANN框架進行識別，看看該框架會給出什么標簽，則將該標簽作為翻身、夢話、磨牙對應的標簽。
（3）連續音頻的處理：一個10s的連續音頻，首先得到每個1s音頻的標簽分布，然后對這10s進行一個標簽分布的平均，最后根據這個平均值來進行綜合判斷（這個處理需要再討論）。

平臺兼容性

建議開發出適用于Android及IOS的版本。

Android版本目前進展及面臨的問題

1、目前的進展：
可以使用PANN框架對分割后的音頻片段進行識別，識別的類型為該框架提供的527個類別，還沒有根據目前的需求識別出規定的類別；
2、下一步的工作：
（1）采集翻身、夢話、磨牙等類型的音頻，進行識別，獲得對應的標簽類別；
（2）編寫開發文檔及Java代碼，代碼符合玉米樹規范，采用面向對象，利于后期維護。
3、面臨的問題：
使用android studio運行程序遇到卡殼問題，建議重新創建一個線程來運行。

IOS版本目前進展及面臨的問題

1、目前進展：還沒有開始。
2、可能會面臨的問題：使用xcode運行IOS程序時，會遇到一些底層代碼調用報錯問題，重寫會比較麻煩。

其它

PANNs模型需要wav文件必須是單通道，采樣率為32kHz；而YAMNet模型需要wav文件也必須是單通道，采樣率為16kHz。

時間及人員安排

實驗部分

音頻采集及測試：2周。（梁翔宇、樊俊）
分割策略實驗：2周。（容斌元、李鵬程）

開發部分

提供一個接口，輸入是音頻文件，返回分割后的音頻及標簽分布。
（1）Android端代碼開發及文檔編寫：4周。（梁翔宇、樊俊）
（2）IOS端代碼開發及文檔編寫：4周。（容斌元、李鵬程）

參考文獻

[1] PANN框架
[2] 玉米樹程序編寫規范

總結

以上是生活随笔為你收集整理的睡眠音频分割及识别问题(六)--输入输出及方案讨论的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。