吳游 馮金金

摘 要： 針對多媒體通信技術在網(wǎng)絡帶寬有限和傳輸音頻數(shù)據(jù)量大的情況下，帶寬利用率低，傳輸效率低的問題，在局域網(wǎng)通信系統(tǒng)中選擇并優(yōu)化實現(xiàn)了G.723.1編解碼算法。在VC++ 6.0平臺上，采用TCP/IP協(xié)議，在兩臺計算機之間分別采用客戶端/服務器模式完成了系統(tǒng)設計。實驗結果表明，優(yōu)化后的算法提高了性能，有較高的壓縮比，編碼后音頻數(shù)據(jù)占用存儲空間小，可以節(jié)省傳輸帶寬，提高傳輸效率。

關鍵詞： 局域網(wǎng)通信系統(tǒng)； 語音編解碼； G.723.1； TCP/IP協(xié)議

中圖分類號： TN912.32?34； TP391 文獻標識碼： A 文章編號： 1004?373X（2016）09?0070?05

Abstract： Since the bandwidth utilization ratio and transmission efficiency are low when the multimedia communication technology is used in the situation of the limited network bandwidth and mass audio data transmission， the G.723.1 coding and decoding algorithm was selected and optimally implemented in the local area network （LAN） communication system. The client/server modes are respectively adopted between two computers to accomplish the system design on VC++ 6.0 platform by using TCP/IP protocol. The experimental results show that the performance of the optimized algorithm is improved， its compression ratio is high， and the coded audio data occupies less storage space， which can save the transmission bandwidth and improve the transmission efficiency.

Keywords： LAN communication system； speech coding and decoding； G.723.1； TCP/IP protocol

0 引 言

由于數(shù)字化語音在傳輸過程和存儲方面，都要比模擬語音更加可靠、更具有抗干擾性、價格等方面更具有競爭力，目前在衛(wèi)星通信、綜合業(yè)務數(shù)字通信網(wǎng)、微博接力通信、移動通信等系統(tǒng)中沒有一個不采用數(shù)字化語音傳輸和存儲[1]。但數(shù)字化語音的傳輸和存儲的不足之處是占用的頻帶較寬，為了節(jié)省數(shù)字信號傳輸所需的帶寬，人們開始深入的研究語音編碼技術。

經(jīng)過多年的發(fā)展，語音編碼技術廣泛應用于因特網(wǎng)、保密通信、衛(wèi)星通信以及水下通信等領域，語音編碼技術領域的研究成果也層出不窮，其中包括很多突破性的研究成果和實用的語音編碼方案。隨著研究成果應用的普及，主要的標準制定組織國際電信聯(lián)盟ITU已經(jīng)制定了一系列語音編碼標準，其編碼速率越來越低。

本文采用模塊化的方式對局域網(wǎng)通信系統(tǒng)進行介紹，因為系統(tǒng)是非實時實現(xiàn)音頻信號傳輸?shù)?，所以對需要的音頻信號進行采集。在眾多的語音編碼標準中選擇G.723.1算法進行研究分析，在分析的基礎上實現(xiàn)算法的性能優(yōu)化，采用TCP/IP協(xié)議，運用客戶端/服務器模式，通過局域網(wǎng)實現(xiàn)了音頻數(shù)據(jù)的傳輸。

1 系統(tǒng)的整體設計

如圖1所示，該系統(tǒng)的設計工作主要包括四個部分：音頻信號的采集，音頻信號的編碼，音頻信號的傳輸和音頻信號的解碼。

系統(tǒng)的工作流程如下：首先需要采集測試需要的音頻信號并按G.723.1算法要求作格式處理后進行存儲，再對音頻信號作數(shù)據(jù)分析；然后對音頻信號的數(shù)據(jù)部分進行編碼處理，將編碼后的數(shù)據(jù)經(jīng)過局域網(wǎng)發(fā)送到服務器端，前提是客戶端和服務器已經(jīng)根據(jù)TCP/IP協(xié)議建立了連接，能夠?qū)崿F(xiàn)數(shù)據(jù)通信。服務器端先接收音頻數(shù)據(jù)，再進行解碼處理，最后對音頻數(shù)據(jù)作分析。

2 系統(tǒng)設計的關鍵技術

2.1 音頻信號采集

由于G.723.1算法要求輸入的音頻信號是以8 kHz采樣率進行采樣，量化位數(shù)為16 b的單聲道線性PCM數(shù)據(jù)；所以對于測試用的音頻信號，可以用Windows的錄音機錄制一段wav格式的語音片段或是一段MP3格式的語音文件用軟件Arial Audio Converter轉(zhuǎn)換成8 kHz采樣率，16 b量化，單聲道的PCM形式的wav文件。

Wav文件由文件頭和數(shù)據(jù)體兩部分組成[2]。文件頭是由文件標識字段與格式塊兩部分組成，后者保存的是編碼參數(shù)和聲音參數(shù)，而文件頭部分不需要進行編碼和解碼。對于8 kHz，16 b量化，單聲道的PCM形式的標準wav文件來說，文件頭占44 B，所以這44 B的內(nèi)容是通過直接從輸入文件寫入到輸出文件中。對wav文件的文件頭進行分析，對編寫解碼端的wav文件至關重要。選用時長為1 s的音樂片段作為測試文件，這個wav文件不是Windows標準的wav文件，就得用Ultra Edit軟件分析wav文件的頭部字節(jié)大小。分析wav頭文件發(fā)現(xiàn)數(shù)據(jù)部分是從58位才開始的，所以在計算數(shù)據(jù)部分長度時存在58位的偏移量。

2.2 編解碼算法的優(yōu)化實現(xiàn)

世界多個標準組織和工業(yè)實體提出了很多話音編碼方案，但應用比較普遍的則是ITU組織提出的一系列語音編碼協(xié)議。從算法是否復雜、編碼速率的高低、延時多大和語音質(zhì)量的好壞這四個方面評價語音編碼算法[3]。ITU?T標準算法的性能比較，如表1所示。在這些編碼算法中，高比特率（Kb/s）的語音數(shù)據(jù)會占用過多的系統(tǒng)資源，所以低比特率的算法在網(wǎng)絡電話技術中應用最為廣泛。

該系統(tǒng)采用了這些算法中編碼速率較低，語音質(zhì)量較好，在目前的語音傳輸中又經(jīng)常用的G.723.1編碼算法[4]。G.723.1標準是為可視電話而制定的一種低碼率編碼方案[5]，它有兩個編碼速率[6]，分別為6.3 Kb/s和5.3 Kb/s。

G.723.1算法編碼過程主要包括以下幾個部分：LPC（線性預測編碼器）分析部分，計算LPC參數(shù)；共振峰感知加權濾波部分，得到感知加權語音信號；LSP（線性頻譜對參數(shù)）量化部分，將最后一子幀的LPC參數(shù)轉(zhuǎn)為LSP參數(shù)；基音估值部分，進行開環(huán)基音周期的估計；計算諧波噪聲成形濾波部分；閉環(huán)基音預測部分，由估計基音周期和脈沖響應計算可得；脈沖響應計算器，由諧波噪聲成形濾波器、共振峰感知加權濾波器、LPC合成濾波器三部分組成[7]，脈沖響應送入解碼器；激勵信號，由自適應碼本激勵、固定碼本激勵構成，該激勵信號是解碼器需要的；自適應碼本激勵，需要閉環(huán)基音周期、自適應碼本增益索引這2個參數(shù)，將閉環(huán)基音預測器的結果從目標信號中減去得到；固定碼本激勵，對于6.3 Kb/s，采用了多脈沖最大似然量化激勵（MP?MLQ）[8]；而對5.3 Kb/s，則采用代數(shù)編碼激勵（ACELP）；最后發(fā)送編碼信息。

G.723.1解碼過程包括：基音解碼和激勵解碼部分，由基音周期、固定碼本激勵、自適應碼本激勵得到激勵信號；前向和后向基音后置濾波部分，對每一子幀作濾波處理；LPC合成濾波部分，從接收信息中提取LSP參數(shù)，通過LSP解碼、內(nèi)插將其轉(zhuǎn)化為LSP系數(shù)，然后得到LPC系數(shù)，經(jīng)過此濾波器后語音得以重建；共振峰后置濾波部分，對輸出的語音作濾波處理；經(jīng)過增益調(diào)整單元得到最后的輸出。

在編碼過程中，算法的計算量主要集中在基音估值器、自適應碼本搜索和固定碼本搜索模塊，想要減少運算量，降低復雜度，對這三個模塊進行優(yōu)化是必要的。

2.2.1 開環(huán)基音預測優(yōu)化

2.2.2 卷積運算的優(yōu)化

在分析過程中發(fā)現(xiàn)，在取出64個歷史自適應激勵后計算卷積，計算時需要分成5輪進行，可以根據(jù)每個階的特點降低計算的復雜度。首先是計算第5階與沖激響應的卷積，這是按正常的方式計算的，然后從第4階開始，依次更新到第1階。前4輪的卷積是在最后一輪的基礎上迭代出來的，這樣就減少了不少的計算量。

2.3 音頻信號傳輸

套接字是一個簡單的網(wǎng)絡應用程序接口，而Windows Socket則是應用比較廣泛的網(wǎng)絡編程接口，這是因為Windows Socket 規(guī)范是Windows下的一套開放的、支持多種協(xié)議的網(wǎng)絡編程接口[9]。數(shù)據(jù)通信時通過應用程序調(diào)用Windows Socket APl實現(xiàn)，另外，Windows Socket又利用下層的網(wǎng)絡通信協(xié)議、物理介質(zhì)和操作系統(tǒng)完成數(shù)據(jù)傳輸[10]。

局域網(wǎng)通信系統(tǒng)采用TCP/IP協(xié)議，兩臺計算機在VC++ 6.0下分別采用客戶端（編碼發(fā)送端）/服務器模式（接收解碼端）通過Windows Socket實現(xiàn)。編碼發(fā)送端與接收解碼端的通信流程圖，如圖2所示。

客戶端與服務器連接之前，必須先知道服務器的名稱，這個名稱就是IP地址和端口號。服務器的套接字處于監(jiān)聽狀態(tài)，用來監(jiān)聽客戶端的連接請求，這是通過調(diào)用lisen（）函數(shù)完成的?？蛻舳艘残枰粋€套接字，向服務器發(fā)送連接請求是通過connect（）函數(shù)完成的。當服務器收到發(fā)來的請求后，通過調(diào)用accept（）函數(shù)接受連接請求。連接后，雙方就可以進行通信了。

2.4 系統(tǒng)測試

該系統(tǒng)要先啟動服務器，等待客戶端的連接，并選擇與客戶端相對應的解碼模式。客戶端打開電腦中需要編碼發(fā)送的語音文件，輸入服務器的IP地址，服務器IP地址為192.168.58.155，端口號在程序中設置為4568，連接服務器。如圖3所示，客戶端已經(jīng)通過TCP/IP協(xié)議成功連接到服務器。

由前面的分析可知文件頭和數(shù)據(jù)部分需要分開，所以先把測試文件的文件頭中的44 B內(nèi)容發(fā)送出去，寫入輸出文件。然后發(fā)送數(shù)據(jù)部分，從數(shù)據(jù)段開始讀取數(shù)據(jù)，每一次從文件中讀出一段數(shù)據(jù)編碼進行編碼，把編碼后的數(shù)據(jù)直接發(fā)送出去，發(fā)送結束后會發(fā)送E類型給接收端通知發(fā)送結束。

服務器接收到文件頭后先寫入輸出文件中，然后接收類型為D的數(shù)據(jù)部分將每次接收到的數(shù)據(jù)暫時先放入緩沖區(qū)，然后進行解碼，得到解碼后的數(shù)據(jù)再寫入輸出文件。編解碼結束后雙方即可關閉套接字。圖4所示為低速率編碼實現(xiàn)界面（高速率界面與之相似）。

3 結果分析驗證

3.1 優(yōu)化算法的正確性分析

（1） 數(shù)據(jù)分析

用Cool Edit軟件分別打開算法優(yōu)化前編解碼后得到的音頻文件和算法優(yōu)化后得到的音頻文件，觀察文件里的具體數(shù)據(jù)是否一致。圖5為算法優(yōu)化前后的部分音頻數(shù)據(jù)。

在對算法進行優(yōu)化時，可以邊優(yōu)化邊比對兩個文件的數(shù)據(jù)，若發(fā)現(xiàn)兩個數(shù)據(jù)的內(nèi)容不一致時，則說明優(yōu)化方法存在問題，就需要采用其他優(yōu)化方法。

（2） 聽音驗證

聽音驗證就是以人耳的主觀聽覺感受為依據(jù)，通過人耳試聽重建后的語音判斷語音是否清晰可懂[11]。在本地計算機上播放原始語音文件，在接收計算機上播放重建后的語音文件，從聽音感覺看，兩種速率的編解碼效果都非常好，語音清晰可懂。

（3） 波形驗證

用計算機分別生成原來的語音信號波形和經(jīng)兩種速率編解碼后生成的語音信號波形，將它們作比較。圖6分別為測試語音在編碼前、經(jīng)過5.3 Kb/s和6.3 Kb/s編解碼后得到的語音波形圖，從圖上可以看出，經(jīng)編解碼后的語音信號波形與原來的語音信號波形還是很相似的。

但圖6（a）和圖6（b）之間，圖6（a）和圖6（c）之間還是有誤差的，這是因為一方面G.723.1語音編碼算法屬于參數(shù)編碼的范疇，另一方面則是因為數(shù)據(jù)部分存在58位的偏移量，所以波形就有一些差異。

3.2 算法的壓縮效率分析

在實現(xiàn)G.723.1算法時特意生成了編碼后的中間文件，以此驗證算法壓縮的高效性。編解碼之后的結果顯示，原始文件大小為16 942 B，經(jīng)速率為5.3 Kb/s的編碼之后，文件大小為746 B，解碼后得到的文件大小為16 366 B；經(jīng)速率為6.3 Kb/s的編碼之后，文件大小為886 B，解碼后得到的文件大小為16 846 B。兩種速率下的壓縮比都達到了19[∶]1，可見壓縮效率很高，在通信中可節(jié)省帶寬，提高傳輸效率。

通過對wav文件的分析，在輸出的音頻文件中編寫了正確的wav頭文件。在兩臺PC上分別實現(xiàn)了語音編碼發(fā)送和接收解碼，從聽覺來看，用優(yōu)化算法編解碼后的語音質(zhì)量清晰可懂；從編碼過程看，算法的性能得到了提高；從編碼結果看，可節(jié)省傳輸帶寬，提高傳輸速度，為以后進一步研究實時語音通信技術提供了基礎和方法。

4 結 語

通過對wav文件的分析，在輸出的音頻文件中編寫了正確的wav頭文件。在兩臺PC上分別實現(xiàn)了語音編碼發(fā)送和接收解碼，從聽覺來看，用優(yōu)化算法編解碼后的語音質(zhì)量清晰可懂；從編碼過程看，算法的性能得到了提高，從編碼結果看，可節(jié)省傳輸帶寬，提高傳輸速度，為以后進一步研究實時語音通信技術提供了基礎和方法。

參考文獻

[1] 李曄，崔慧娟，唐昆，等.數(shù)字語音編碼技術[M].北京：電子工業(yè)出版社，2013.

[2] 王若鈞，何杉.wav文件格式分析與詳解[J].數(shù)字技術與應用，2014（3）：93?94.

[3] 張雪英，賈海蓉，張偉雄.語音與音頻編碼[M].西安：西安電子科技大學出版社，2011.

[4] 彭仁明，陳擘威.一種語音壓縮和網(wǎng)絡傳輸系統(tǒng)設計[J].綿陽師范學院學報，2010，29（5）：31?34.

[5] 李小東，梁宇，林嘉宇.一種語音編解碼算法的研究與實現(xiàn)[J].微處理機，2011，32（3）：52?54.

[6] ITU. Dual rate speech coder for multimedia telecommunications transmitting at 5.3 and 6.3 Kbit/s： ITU?T G.723.1 [S]. US： ITU， 1996.

[7] 李斌.G.723.1標準及其在語音處理中的應用[J].科技信息，2013（35）：163?164.

[8] LIN R S， CHEN Y C， CHEN F K. Low complexity search method for G.723.1 MP?MLQ algorithm [C]// Proceedings of the Eighth International Conference on Intelligent Systems Design and Applications. Kaohsiung， China： IEEE， 2008.

[9] 劉端，黃元，李順利.WINSOCK在網(wǎng)絡測試編程中的使用[J].數(shù)字技術與應用，2012（8）：23.

[10] 孫海民.精通Windows Sockets網(wǎng)絡開發(fā)：基于Visual C++實現(xiàn)[M].北京：人民郵電出版社，2008.

[11] 王偉，李劍雄，周廣祿.G.723.1語音壓縮算法的分析及DSP實現(xiàn)[J].微計算機信息，2008，24（12）：160?162.