目錄 一. PCM格式是什么 二. 瀏覽器中的音頻采集處理 三. 需求實現 方案1——服務端FFmpeg實現編碼 方案2——ScriptProcessorNode手動處理數據流 參考文獻 示例代碼托管在:http://www.github.com/dashnowords/blogs 博客園地址:《大史住在大前端》原創博文目錄 華為云社區地址:【你要的前端打怪升級指南】 本文中最重要的信息:32為浮點數表示16bit位深數據時是用-1~+1的小數來表示16位的-32768~+32767的!翻遍了MDN都沒找到解釋,我的內心很崩潰! 最近不少朋友需要在項目中對接百度語音識別的REST API接口,在讀了我之前寫的【Recorder.js+百度語音識別】全棧方案技術細節一文后仍然對Web音頻采集和處理的部分比較困惑,本文僅針對音頻流處理的部分進行解釋,全棧實現方案的技術要點,可以參見上面的博文,本篇不再贅述。 一. PCM格式是什么 百度語音官方文檔對于音頻文件的要求是: pcm,wav,arm及小程序專用的m4a格式,要求參數為16000采樣率,16bit位深,單聲道。 PCM編碼,全稱為"脈沖編碼調制",是一種將模擬信號轉換成數字信號的方法。模擬信號通常指連續的物理量,例如溫度、濕度、速度、光照、聲響等等,模擬信號在任意時刻都有對應的值;數字信號通常是模擬信號經過采樣、量化和編碼等幾個步驟后得到的。 比如現在麥克風采集到了一段2秒的音頻模擬信號,它是連續的,我們有一個很菜的聲卡,采集頻率為10Hz,那么經過采樣后就得到了20個離散的數據點,這20個點對應的聲音值可能是各種精度的,這對于存儲和后續的使用而言都不方便,此時就需要將這些值也離散化,比如在上例中,信號的范圍是0~52dB,假設我們希望將0~63dB的值都以整數形式記錄下來,如果采用6個bit位來存儲,那么就可以識別(2^6-1=63)個數值,這樣采集的信號通過四舍五入后都以整數形式保存就可以了,最小精度為1dB;如果用7個bit位來保存,可存儲的不同數值個數為(2^7-1=127)個,如果同樣將0~63dB映射到這個范圍上的話,那么最小精度就是0.5dB,很明顯這樣的處理肯定是有精度損失的,使用的位數越多精度越高,計算機中自然需要使用8的整數倍的bit位來進行存儲,經過上述處理后數據就被轉換成了一串0和1組成的序列,這樣的音頻數據是沒有經過任何壓縮編碼處理的,也被稱為“裸流數據”或“原始數據”。從上面的示例中很容易看出,用10Hz的采樣率,8bit位存儲采樣點數值時,記錄2秒的數據一共會產生2X10X8 = 160個bit位,而用16bit位來存儲采樣點數據時,記錄1秒的數據也會產生1X10X16 = 160個bit位,如果沒有任何附加的說明信息,就無法知道這段數據到底該怎么使用。按照指定要求進行編碼后得到的序列就是pcm數據,它在使用之前通常需要聲明采集相關的參數。 下圖就是一段采樣率為10Hz,位深為3bit的pcm數據,你可以直觀地看到每個步驟所做的工作。 wav格式也是一種無損格式,它是依據規范在pcm數據前添加44字節長度用來填充一些聲明信息的,wav格式可以直接播放。而百度語音識別接口中后兩種格式都需要經過編碼算法處理,通常會有不同程度的精度損失和體積壓縮,所以在使用后兩種數據時必然會存在額外的編解碼時間消耗,所以不難看出,各種格式之間的選擇其實就是對時間和空間的權衡。 二. 瀏覽器中的音頻采集處理 瀏覽器中的音頻處理涉及到許多API的協作,相關的概念比較多,想要對此深入了解的讀者可以閱讀MDN的【Web 媒體技術】篇,本文中只做大致介紹。 首先是實現媒體采集的WebRTC技術,使用的舊方法是navigator.getUserMedia( ),新方法是MediaDevices.getUserMedia( ),開發者一般需要自己做一下兼容處理,麥克風或攝像頭的啟用涉及到安全隱私,通常網頁中會有彈框提示,用戶確認后才可啟用相關功能,調用成功后,回調函數中就可以得到多媒體流對象,后續的工作就是圍繞這個流媒體展開的。 瀏覽器中的音頻處理的術語稱為AudioGraph,其實就是一個【中間件模式】,你需要創建一個source節點和一個destination節點,然后在它們之間可以連接許許多多不同類型的節點,source節點既可以來自流媒體對象,也可以自己填充生成,destination可以連接默認的揚聲器端點,也可以連接到媒體錄制APIMediaRecorder來直接將pcm數據轉換為指定媒體編碼格式的數據。中間節點的類型有很多種,可實現的功能也非常豐富,包括增益、濾波、混響、聲道的合并分離以及音頻可視化分析等等非常多功能(可以參考MDN中給出的AudioContext可創建的不同類型節點)。當然想要熟練使用還需要一些信號處理方面的知識,對于非工科背景的開發者而言并不容易學習。 三. 需求實現 一般的實現方法是從getUserMedia方法得到原始數據,然后根據相關參數手動進行后處理,相對比較繁瑣。 方案1——服務端FFmpeg實現編碼 很多示例都是將音頻源節點直接連接到默認的輸出節點(揚聲器)上,但是幾乎沒什么意義,筆者目前還沒有找到使用Web Audio API自動輸出pcm原始采樣數據的方法,可行的方法是使用MediaRecorder來錄制一段音頻流,但是錄制實例需要傳入編碼相關的參數并指定MIME類型,最終得到的blob對象通常是經過編碼后的音頻數據而非pcm數據,但也因為經過了編碼,這段原始數據的相關參數也就已經存在于輸出后的數據中了。百度語音官方文檔推薦的方法是使用ffmpeg在服務端進行處理,盡管明顯在音頻的編解碼上繞了彎路,但肯定比自己手動編碼難度要低得多,而且ffmepg非常強大,后續擴展也方便。參考數據大致從錄音結束到返回結果,PC端耗時約1秒,移動端約2秒。 核心示例代碼(完整示例見附件或開頭的github代碼倉): //WebRTC音頻流采集 navigator.mediaDevices.getUserMedia({audio:true}) .then((stream) => { //實例化音頻處理上下文 ac = new AudioContext({ sampleRate:16000 //設置采樣率 }); //創建音頻處理的源節點 let source = ac.createMediaStreamSource(stream); //創建音頻處理的輸出節點 let dest = ac.createMediaStreamDestination(); //直接連接 source.connect(dest); //生成針對音頻輸出節點流信息的錄制實例,如果不通過ac實例調節采樣率,也可以直接將stream作為參數 let mediaRecorder = window.mediaRecorder = new MediaRecorder(dest.stream, { mimeType: '',//chreome中的音軌默認使用格式為audio/webm;codecs=opus audioBitsPerSecond: 128000 }); //給錄音機綁定事件 bindEventsForMediaRecorder(mediaRecorder); }) .catch(err => { console.log(err); }); 錄音機事件綁定: //給錄音機綁定事件 function bindEventsForMediaRecorder(mediaRecorder) { mediaRecorder.addEventListener('start', function (event) { console.log('start recording!'); }); mediaRecorder.addEventListener('stop', function (event) { console.log('stop recording!'); }); mediaRecorder.addEventListener('dataavailable', function (event) { console.log('request data!'); console.log(event.data);//這里拿到的blob對象就是編碼后的文件,既可以本地試聽,也可以傳給服務端 //用a標簽下載; createDownload(event.data); //用audio標簽加載 createAudioElement(event.data); }); } 本地測試時,可以將生成的音頻下載到本地,然后使用ffmpeg將其轉換為目標格式: ffmpeg -y -i record.webm -f s16le -ac 1 -ar 16000 16k.pcm 詳細的參數說明請移步ffmpeg documentation,至此就得到了符合百度語音識別接口的錄音文件。 方案2——ScriptProcessorNode手動處理數據流 如果覺得使用ffmpeg有點“殺雞用牛刀”的感覺,那么就需要自己手動處理二進制數據了,這是就需要在audioGraph中添加一個腳本處理節點scriptProcessorNode,按照MDN的信息該接口未來會廢棄,用新的Audio Worker API取代,但目前chrome中的情況是,Audio Worker API標記為試驗功能,而舊的方法也沒有明確的提示說明會移除(通常計劃廢除的功能,控制臺都會有黃色字體的提示)。但無論如何,相關的基本原理是一致的。 scriptProcessorNode節點使用一個緩沖區來分段存儲流數據,每當流數據填充滿緩沖區后,這個節點就會觸發一個audioprocess事件(相當于一段chunk),在回調函數中可以獲取到該節點輸入信號和輸出信號的內存位置指針,然后通過手動操作就可以進行數據處理了。 先來看一個簡單的例子,下面的示例中,處理節點什么都不做,只是把單聲道輸入流直接拷貝到輸出流中: navigator.mediaDevices.getUserMedia(constraints) .then((stream) => { ac = new AudioContext({ sampleRate:16000 }); let source = ac.createMediaStreamSource(stream); //構造參數依次為緩沖區大小,輸入通道數,輸出通道數 let scriptNode = ac.createScriptProcessor(4096, 1, 1); //創建音頻處理的輸出節點 let dest = ac.createMediaStreamDestination(); //串聯連接 source.connect(scriptNode); scriptNode.connect(dest); //添加事件處理 scriptNode.onaudioprocess = function (audioProcessingEvent) { //輸入流位置 var inputBuffer = audioProcessingEvent.inputBuffer; //輸出流位置 var outputBuffer = audioProcessingEvent.outputBuffer; //遍歷通道處理數據,當前只有1個輸入1個輸出 for (var channel = 0; channel < outputBuffer.numberOfChannels; channel++) { var inputData = inputBuffer.getChannelData(channel); var outputData = outputBuffer.getChannelData(channel); //用按鈕控制是否記錄流信息 if (isRecording) { for (let i = 0; i < inputData.length; i = i + 1) { //直接將輸入的數據傳給輸出通道 outputData[i] = inputData[i]; } } }; } 在上面的示例加工后,如果直接將結果連接到ac.destination(默認的揚聲器節點)就可以聽到錄制的聲音,你會聽到輸出信號只是重復了一遍輸入信號。 但是將數據傳給outputData輸出后是為了在后續的節點中進行處理,或者最終作為揚聲器或MediaRecorder的輸入,傳出后就無法拿到pcm數據了,所以只能自己來假扮一個MediaRecorder。 首先在上面示例中向輸出通道透傳數據時,改為自己存儲數據,將輸入數據打印在控制臺后可以看到緩沖區大小設置為4096時,每個chunk中獲取到的輸入數據是一個長度為4096的Float32Array定型數組,也就是說每個采樣點信息是用32位浮點來存儲的,【recorder.js】給出的轉換方法如下: function floatTo16BitPCM(output, offset, input) { for (let i = 0; i < input.length; i++, offset += 2) { let s = Math.max(-1, Math.min(1, input[i])); output.setInt16(offset, s < 0 ? s * 0x8000 : s * 0x7FFF, true); } } 看起來的確是不知道在干嘛,后來參考文獻中找到了相關解釋: 32位存儲的采樣幀數值,是用-1到1來映射16bit存儲范圍-32768~32767的。 現在再來看上面的公式就比較容易懂了: //下面一行代碼保證了采樣幀的值在-1到1之間,因為有可能在多聲道合并或其他狀況下超出范圍 let s = Math.max(-1, Math.min(1, input[i])); //將32位浮點映射為16位整形表示的值 output.setInt16(offset, s < 0 ? s * 0x8000 : s * 0x7FFF, true); 如果s>0其實就是將0~1映射到到0~32767,正數第一位符號位為0,所以32767對應的就是0111 1111 1111 1111也就是0x7FFF,直接把s當系數相乘就可以了;當s為負數時,需要將0~-1映射到0~-32768,所以s的值也可以直接當做比例系數來進行轉換計算,負數在內存中存儲時需要使用補碼,補碼是原碼除符號位以外按位取反再+1得到的,所以-32768原碼是1000 0000 0000 0000(溢出的位直接丟棄),除符號位外按位取反得到1111 1111 1111 1111,最后再+1運算得到1000 0000 0000 0000(溢出的位也直接丟棄),用16進制表示就是0x8000。順便多說一句,補碼的存在是為了讓正值和負值在二進制形態上相加等于0。 公式里的output很明顯是一個ES6-ArrayBuffer中的DataView視圖,用它可以實現混合形式的內存讀寫,最后的true表示小端系統讀寫,對這一塊知識不太熟悉的讀者可以閱讀阮一峰前輩的ES6指南(前端必備工具書)進行了解。 參考文獻 how-to-convert-between-most-audio-formats-in-net。
轉載自://www.cnblogs.com/dashnowords/p/11795251.html
欧美黄色网