speech codec (G.711, G.723, G.726, G.729, iLBC)
各種各樣的編解碼在各種領域得到廣泛的應用，下面就把各種codec的壓縮率進行一下比較，不正確之處望各位同行指正。
Speech codec：
現(xiàn)主要有的speech codec 有:
G.711, G.723, G.726 , G.729, ILBC，QCELP, EVRC, AMR, SMV

主要的audiocodec 有:
real audio, AAC,AC3, MP3, WMA, SBC等，各種編解碼都有其應用的重點領域。
本文主要對speech codec相關指標進行總結(jié)：
ITU 推出G.7XX系列的speechcodec, 目前廣泛應用的有：G.711，G.723,G.726, G.729. 每一種又有很多分支，如G.729就有g.729A, g.729Band g.729AB

G.711:

G.711就是語音模擬信號的一種非線性量化，細分有二種:G.711 A-lawand G.711 u-law.不同的國家和地方都會選取一種作為自己的標準. G.711 bitrate 是64kbps. 詳細的資料可以在ITU 上下到相關的spec，下面主要列出一些性能參數(shù)：
G.711（PCM方式：PCM＝脈碼調(diào)制 ：Pulse Code Modulation）
• 采樣率：8kHz
• 信息量：64kbps／channel
• 理論延遲：0.125msec
• 品質(zhì)：MOS值4.10

G.723.1:

G.723.1是一個雙速率的語音編碼器，是 ITU-T建議的應用于低速率多媒體服務中語音或其它音頻信號的壓縮算法；其目標應用系統(tǒng)包括H.323、H.324等多媒體通信系統(tǒng)，目前該算法已成為IP電話系統(tǒng)中的必選算法之一；編碼器的幀長為30ms，還有7.5ms的前瞻，編碼器的算法時延為37.5ms；編碼器首先對語音信號進行傳統(tǒng)電話帶寬的濾波（基于G.712），再對語音信號用傳統(tǒng)8000-Hz速率進行抽樣（基于G.711），并變換成16 bit線性PCM碼作為該編碼器的輸入；在解碼器中對輸出進行逆操作來重構(gòu)語音信號；高速率編碼器使用多脈沖最大似然量化（MP-MLQ），低速率編碼器使用代數(shù)碼激勵線性預測（ACELP）方法，編碼器和解碼器都必須支持此兩種速率，并能夠在幀間對兩種速率進行轉(zhuǎn)換；此系統(tǒng)同樣能夠?qū)σ魳泛推渌纛l信號進行壓縮和解壓縮，但它對語音信號來說是最優(yōu)的；采用了執(zhí)行不連續(xù)傳輸?shù)撵o音壓縮，這就意味著在靜音期間的比特流中加入了人為的噪聲。除了預留帶寬之外，這種技術使發(fā)信機的調(diào)制解調(diào)器保持連續(xù)工作，并且避免了載波信號的時通時斷。

G.726:

G.726有四種碼率：, 32, 24, 16 kbit/s Adaptive Differential Pulse Code Modulation(ADPCM)，最為常用的方式是 32 kbit/s，但由于其只是 G.711速率的一半，所以可將網(wǎng)絡的可利用空間增加了一倍。G.726具體規(guī)定了一個 64 kbpsA-law 或 µ-law PCM 信號是如何被轉(zhuǎn)化為40, 32, 24或16 kbps 的ADPCM 通道的。在這些通道中，24和16 kbps 的通道被用于數(shù)字電路倍增設備(DCME)中的語音傳輸，而40 kbps 通道則被用于 DCME 中的數(shù)據(jù)解調(diào)信號（尤其是4800 kbps 或更高的調(diào)制解調(diào)器）。

G.726 encoder 輸入一般都是G.711 encoder的輸出：64kbps A-law or u-law.其算法實質(zhì)就是一個ADPCM， 自適應量化算法。

G.729:

G..729語音壓縮編譯碼算法
采用算法是共軛結(jié)構(gòu)的代數(shù)碼激勵線性預測(CSACELP)，是基于CELP編碼模型的算法；能夠?qū)崿F(xiàn)很高的語音質(zhì)量（長話音質(zhì)）和很低的算法延世；算法幀長為10ms，編碼器含5ms前瞻，算法時延15ms；其重建語音質(zhì)量在大多數(shù)工作環(huán)境下等同于32kb/s的ADPCM（G.726），MOS分大于4.0；編碼時輸入16bitPCM語音信號，輸出2進制比特流；譯碼時輸入為2進制比特流，輸出16bitPCM語音信號；在語音信號8KHz取樣的基礎上，16bit線性PCM后進行編碼，壓縮后數(shù)據(jù)速率為8Kbps；具有相當于16：1的壓縮率。
G.729系列在當前的VOIP得到廣泛的應用，且相關分支較多，可以直接從ITU網(wǎng)上得到source code 和相關文檔。
G.729（CS-ACELP方式：Conjugate Structure Algebraic Code Excited Linear Prediction）
• 采樣率：8kHz
• 信息量：8kbps／channel
• 幀長：10msec
• 理論延遲：15msec
• 品質(zhì)：MOS值3.9

iLBC(internet low bitrate codec):

是全球著名語音引擎提供商Global IP Sound開發(fā)，它是低比特率的編碼解碼器，提供在丟包時具有的強大的健壯性。iLBC 提供的語音音質(zhì)等同于或超過 G.729 和 G.723.1，并比其它低比特率的編碼解碼器更能阻止丟包。iLBC 以13.3 kb/s (每幀30毫秒)和15.2 kb/s (每幀20毫秒)速度運行，很適合撥號連接。
iLBC的主要優(yōu)勢在于對丟包的處理能力。iLBC獨立處理每一個語音包，是一種理想的包交換網(wǎng)絡語音編解碼。在正常情況下，iLBC會記錄下當前數(shù)據(jù)的相關參數(shù)和激勵信號，以便在之后的數(shù)據(jù)丟失的情況下進行處理；在當前數(shù)據(jù)接收正常而之前數(shù)據(jù)包丟失的情況下，iLBC會對當前解碼出的語音和之前模擬生成的語音進行平滑處理，以消除不連貫的感覺；在當前數(shù)據(jù)包丟失的情況下，iLBC會對之前記錄下來的激勵信號作相關處理并與隨機信號進行混合，以得到模擬的激勵信號，從而得到替代丟失語音的模擬語音。總的來說，和標準的低位速率編解碼相比，iLBC使用更多自然、清晰的元素，精確的模仿出原始語音信號，被譽為更適合包交換網(wǎng)絡使用的可獲得高語音質(zhì)量的編解碼。
此外，大部分標準的低位速率編解碼，如G.723.1和G.729，僅對300Hz——3400Hz的頻率范圍進行編碼。在這個頻率范圍里，用G.711編解碼所達到的語音質(zhì)量，就是傳統(tǒng)PSTN網(wǎng)絡進行語音通話的效果。
iLBC充分利用了0——4000Hz的頻率帶寬進行編碼，擁有超清晰的語音質(zhì)量，這大大超出傳統(tǒng)300Hz——3400Hz的頻率范圍。
廣受歡迎的Skype網(wǎng)絡電話的核心技術之一就是iLBC語音編解碼技術，Global IP Sound稱該編碼器語音品質(zhì)優(yōu)于PSTN，而且能忍受高達30%的封包損失。
總的來說，在相同的包交換通信條件下，iLBC的語音質(zhì)量效果比G.729、G.723.1以及G.711更好，聲音更加圓潤飽滿，且丟包率越高，iLBC在語音質(zhì)量上的優(yōu)勢就越明顯！
目前，在國際市場上已經(jīng)有很多VoIP的設備和應用廠商把iLBC集成到他們的產(chǎn)品中。如：Skype, Nortel等。在國內(nèi)市場上，目前尚無VoIP廠家正式推出支持“iLBC”的網(wǎng)關設備，迅時公司 率先推出支持“iLBC”的中繼網(wǎng)關和IAD設備。

如何計算一路話音消耗的帶寬

在voice這方面，是如何計算使用某種codec所消耗的帶寬呢？在默認情況下，把模擬話音轉(zhuǎn)換為數(shù)字話音后，按20ms一段20ms一段切開，用rtp封裝起來，然后包上udp header，ip header，最后是layer 2的包頭，然后發(fā)出去。
假設咱們用g.729編碼，并在ethernet上傳輸。一起來算算一路話音需要多大帶寬吧。
g.729每路話音是8kbit/s，那么開始轉(zhuǎn)換：
8000bps / 8 = 1000 bytes/s，得到g.729每秒需要帶寬1000 bytes
那么默認都是把20ms的話音封成一個packet，也就可以算出1秒內(nèi)發(fā)送多少個packet：
1s / 20ms = 50個
也就是說g.729每20ms需要的帶寬為：1000bytes/s / 50 = 20bytes/s
之后以太網(wǎng)幀頭6-byte，ip包頭20-byte，udp包頭8-byte，rtp包頭12-byte，這樣，再加上g.729的payload為20bytes，也就是說每20ms就要產(chǎn)生一個6 + 20 + 8 + 12 + 20 = 66-byte長度的幀，那么一秒就要發(fā)送50個66-byte，等于3300-byte，轉(zhuǎn)成kbit/s： 3300byte/s * 8 /1000 = 26.4kbit/s
最終得出g.729一路話音占用帶寬（包括layer2 header）為26.4kbps

本文來自CSDN博客，轉(zhuǎn)載請標明出處：http://blog.csdn.net/worldpharos/archive/2009/03/10/3977018.aspx

語音編碼的帶寬計算

VOIP Bandwidth consumption naturally depends on the codecused.
VOIP消耗的帶寬一般取決于所使用的語音編碼.
When calculating bandwidth, one can't assume that everychannel is used all the time. Normal conversation includes a lot of silence,which often means no packets are sent at all.So even if one voice call sets uptwo 64 Kbit RTP streams over UDP over IP over Ethernet (which adds overhead),the full bandwidth is not used at all times.
計算帶寬時,不能假設每一個通道都處于使用狀態(tài).正常的通話過程包括一系列的靜音,也就意味著并不是一直都有包在傳送.所以一個語音呼叫建立兩個經(jīng)過UDP,IP和以太網(wǎng)的64Kbit的RTP流(總開銷),全部帶寬并末一直被使用.
A codec that sends a 64kb stream results in a much largerIP network stream. The main cause of the extra bandwidth usage is IP and UDPheaders. VoIP sends small packets and so, many times, the headers are actuallymuch larger than the data part of the packet.
一個傳送64kb流的語音編碼很大程度上都是IP網(wǎng)絡流的結(jié)果.額外的帶寬使用主要是IP或UDP頭的增加.VOIP只傳送少量的包,很多時候,實際上是包頭遠遠大于包數(shù)據(jù).
Codec BR NEB
G.711 64 Kbps 87.2 Kbps
G.729 8 Kbps 31.2 Kbps
G.723.1 6.4 Kbps 21.9 Kbps
G.723.1 5.3 Kbps 20.8 Kbps
G.726 32 Kbps 55.2 Kbps
G.726 24 Kbps 47.2 Kbps
G.728 16 Kbps 31.5 Kbps
iLBC 15 Kbps 27.7 Kbps
BR = Bit rate
NEB = Nominal Ethernet Bandwidth (one direction)
根據(jù)我的使用經(jīng)驗，8K的G.729加上IP封裝后達到32K,為了防封殺，還有的用戶使用IP Sec設備將語音做成VPN，這樣G.729加上IP封裝，再加上VPN會達到60多K。
注:頭三段中文是我自己譯過來的,所以讀起來并不怎么準確,而且會感覺別扭,呵呵.多多包涵了.有興趣的朋友可以再譯一次.以供借鑒.
集群通軟交換電話-所需帶寬說明
VoIP所需要的帶寬，通常取決于它所使用的codec編碼方法。在計算帶寬時，不能假定每個通道總是在使用之中。通常的會話過程中包括大量的靜默時段，就是不發(fā)送任何數(shù)據(jù)包。
一個會話建立了兩個64kbps的RTP流，在UDP/IP/Ethernet上,并非在所有的時間都使用全部的帶寬。
一種編碼方法發(fā)送64kbps的數(shù)據(jù)流，會導致大得多的IP網(wǎng)的數(shù)據(jù)流，引起額外帶寬的主要原因是IP和UDP的報文頭.當VoIP發(fā)送小的數(shù)據(jù)包時，在大多數(shù)時候，報文頭實際上要比包中的數(shù)據(jù)大得多。
下面的表列出了各種編碼方法，所需要的帶寬：

編碼方法	編碼所需帶寬	實際所需要的網(wǎng)絡帶寬
G.711	64 Kbps	87.2 Kbps
G.729	8 Kbps	31.2 Kbps
G.723.1	6.4 Kbps	21.9 Kbps
G.723.1	5.3 Kbps	20.8 Kbps
G.726	32 Kbps	55.2 Kbps
G.726	24 Kbps	47.2 Kbps
G.728	16 Kbps	31.5 Kbps

編碼所需帶寬，是指理論上所需要的帶寬。但在實際的傳輸過程中，還要付出其他的消耗，如報文頭。真正需要的帶寬是實際所需要的網(wǎng)絡帶寬，這是大致的數(shù)值，而不是嚴格的精確值。實際所需要的網(wǎng)絡帶寬通常是以太網(wǎng)所需要的帶寬，或者是ppp連接所要的帶寬。
QQ使用的編碼技術GIPS，實際使用起來感覺聲音比較清晰，相對于SIP的編碼就顯得聲音有些不好，請問，GIPS理論占用的帶寬有多大？能不能在SIP加入GIPS編碼方式？
GIPS公司用的語音編碼技術是 iLBC編碼。
iLBC若采30ms一幀，則理論帶寬需要13.33 kbps。若20ms 一幀，則理論帶寬需要15.2kbps 。
iLBC的語音質(zhì)量要比 G.729A好些，但是能夠容忍丟失更多的包；也就是在丟包后，iLBC恢復能力更強。
iLBC計算復雜度與G.729A差不多。都是計算度比較復雜的算法。
SIP終端中，也有使用 iLBC編碼的。skype 、QQ在語音編碼上并沒有什么優(yōu)勢。由于它們是私有協(xié)議，目前在穿透私網(wǎng)（NAT）和防火墻上，更好做些，所以媒體流的路徑，可能比SIP標準（目前）好做些而已。穿透易，路徑選得近些，音質(zhì)就顯得好些。
G711在大約有 100Kbps 帶寬時，有很好的語音質(zhì)量。
G.726 在大約有 50Kbps 帶寬時，有好的語音質(zhì)量。
G.729 在大約有 30Kbps 帶寬時，有好的語音質(zhì)量。

GIPS公司用的語音編碼技術是帶寬可變的碼率，也就是根據(jù)網(wǎng)絡 實際的帶寬狀態(tài)，調(diào)整語音編碼的壓縮比率。 也就是帶寬越少，語音壓縮得越厲害，失真損失越多；帶寬越好，就壓縮不厲害，失真損失少。

注意語音編碼用的壓縮，都是有損壓縮，也就壓縮后語音會些失真。
什么是iLBC？
iLBC是一種專為包交換網(wǎng)絡通信設計的編解碼，優(yōu)于目前流行的G.729、G.723.1，對丟包進行了特有處理，既使在丟包率 相當高的網(wǎng)絡環(huán)境下，仍可獲得非常清晰的語音效果。
iLBC所占用帶寬？
30ms ptime的iLBC所占用的總通信帶寬比通常采用的ptime 20ms的G.729的帶寬還要小，以下是iLBC與傳統(tǒng)編解碼占用帶寬列表：
iLBC——語音質(zhì)量的飛躍
語音質(zhì)量一直是VoIP應用的主要難點，如何保證和提高IP網(wǎng)絡傳輸語音的通話效果，是VoIP應用迫切需要解決的問題。“iLBC”編解碼的出現(xiàn)，解決了在包交換的IP網(wǎng)絡中，傳輸語音所遇到的網(wǎng)絡丟包嚴重影響通話質(zhì)量等實際問題，實現(xiàn)了“語音質(zhì)量的飛躍”。
下圖為在不同的網(wǎng)絡丟包環(huán)境下，使用iLBC與G.729A、G.723.1編解碼的語音質(zhì)量比較。
圖1. iLBC與 G.729A、G.723.1的比較(Dynastat, Inc)
無論在高丟包率條件下還是在沒有丟包的條件下，iLBC的語音質(zhì)量都優(yōu)于目前流行的G.723.1, G.729A等標準編解碼；而且丟包率越大，使用iLBC的語音質(zhì)量優(yōu)勢越明顯。通常情況下，為了衡量IP網(wǎng)絡語音質(zhì)量，將≥5％丟包率的網(wǎng)絡情況定義為VoIP的極限網(wǎng)絡條件。經(jīng)過語音質(zhì)量測試，即使在5％丟包率的情況下，iLBC仍然能夠提供相當于GSM手機的語音質(zhì)量。

Internet話音分組傳輸技術

在IP網(wǎng)中傳輸層有兩個并列的協(xié)議：TCP和UDP。

TCP是面向連接的，它提供高可靠性服務；UCP是無連接的，它提供高效率的服務。

高可靠性的TCP用于一次傳輸要交換大量報文的情況，高效率的UDP用于一次交換少量的報文或?qū)崟r性要求較高的信息。

實時傳輸協(xié)議RTP提供具有實時特征的、端到端的數(shù)據(jù)傳輸業(yè)務，可以用來傳送聲音和活動圖像數(shù)據(jù)，在這項數(shù)據(jù)傳輸業(yè)務中包含了裝載數(shù)據(jù)的標識符、序列號、時戳以及傳送監(jiān)視。通常RTP的協(xié)議數(shù)據(jù)單元是用UDP分組來承載的。而且為了盡量減少時延，話音凈荷通常都很短。圖3表示一個IP話音分組的結(jié)構(gòu)，圖中 IP，UDP和RTP的控制頭都按最小長度計算。 這種IP話音分組的開銷很大，約為66％～80％。于是有人提出了組合RTP分組的概念

采用這種組合復用方法的確可以大大提高傳輸效率，但是目前尚無標準。

如果支持RTP的網(wǎng)絡能提供組播功能，則它也可用組播方式將數(shù)據(jù)送給多個目的用戶。

RTP 本身沒有提供任何確保及時傳送的機制，也沒有提供任何傳輸質(zhì)量保證的機制，因而業(yè)務質(zhì)量完全由下層網(wǎng)絡的質(zhì)量來決定。同時，RTP不保證數(shù)據(jù)包按序號傳送，即使下層網(wǎng)絡提供可靠性傳送，也不能保證數(shù)據(jù)包的順序到達。包含在RTP中的序列號就是供接收方重新對數(shù)據(jù)包排序之用。

與RTP相配套的另一個協(xié)議是RTCP協(xié)議。RTCP是RTP的控制協(xié)議，它用于監(jiān)視業(yè)務質(zhì)量并與正在進行的會話者傳送信息。

因此，我們可以根據(jù)這個圖３計算出每路G.729編碼的帶寬占用量：

帶寬占用＝傳輸?shù)目傋止?jié)數(shù) / 傳輸?shù)目倳r間

帶寬＝(20byte（IP頭）+8byte（UDP頭）+12byte（RTP頭）+20byte(數(shù)據(jù)))/２０ms

=60byte/20ms

以上計算公式含義為：每20ms，需要傳輸?shù)淖止?jié)數(shù)包括20個字節(jié)的IP包頭，8個字節(jié)的UDP包頭，12各字節(jié)的RTP包頭，20字節(jié)的語音數(shù)據(jù)共60字節(jié)，結(jié)果為：3 byte/ms=3000 byte/s=24000bit/s＝24kbit/s。

因此，理論上G.729中每個數(shù)據(jù)包包含兩幀語音的編碼方式，占用帶寬24kbit/s，而又有封裝效率的估算公式為：

封裝效率=[（壓縮后的語音包× n × 幀長/ 8）] / [（壓縮后的語音包×n× 幀長/ 8 ）＋40] 。

n表示打進n個語音包。

以G.729信源編碼為例，如一個RTP包打進一個語音包，則實際傳送碼流為40kbit/s，時延約為 10 ms；

如打兩個語音包，則實際傳送碼流為24kbit/s，時延約為 20ms；

如打四個語音包，實際傳送碼流為16kbit/s，時延為40ms。

為保證編碼打包的時延，若將缺省語音包的數(shù)量定為兩個，實際傳送碼流即為24kbit/s，而不是8kbit/s。

因此對于語音業(yè)務這類實時性要求非常高的業(yè)務，要保證語音的質(zhì)量，根據(jù)ITU-T標準語音的全程往返時延應當控制在450ms為宜，編碼打包后形成的單位碼流通常是在20kbit/s。

由以上論述我們知道，每路G.729編碼的IP語音占用約20Kbit/s的帶寬，實際占用的總帶寬數(shù)＝語音總路數(shù)*20Kbit/s。

語音編解碼方式及其所占用的帶寬的關系

語音編碼的帶寬和實際所占用的帶寬是不同的，語音編碼的帶寬是實際語音包的帶寬，而語音包在IP網(wǎng)絡上傳輸時，還需要增加各種包頭，如RTP包頭、UDP包頭、IP包頭。由于語音包本身很小，所以相對而言這些額外的帶寬是很可觀的。在下表中列出了各種編碼方式下的打包時長以及所對應的實際帶寬。

實際帶寬與語音編碼和打包時長的關系：
語音編解碼打包時長 語音數(shù)據(jù)帶寬 實際所占帶寬
G.723.1(5.3K)30ms5.3K5.3*(20+40)/20 = 16.2K
G.723.1(5.3K)60ms5.3K5.3*(40+40)/40 = 10.6K
G.723.1(6.3K)30ms6.3K6.3*(24+40)/24 = 16.8K
G.723.1(6.3K)60ms6.3K6.3*(48+40)/48 = 11.6K
G.72920ms8K8*(20+40)/20 = 24K
G.72960ms8K8*(60+40)/60 = 13.3K
由上表可以很明顯的看出，打包時間越長，所占用的實際帶寬越小，但時延越大。

說明
1、RTP包頭：12bytesUDP包頭：8bytes IP包頭：20bytes。
2、表中的帶寬計算中沒有包含物理幀頭，需根據(jù)具體網(wǎng)絡而定。
3、表中的帶寬計算中，沒有考慮靜音檢測。靜音檢測的效率按60％計算。

音頻：

名稱采樣率采樣精度占用帶寬(kbps)

G.723.1	8k	16bit	5.3 ~ 6.3kbps
ILBC	8k	16bit	13.33 ~ 15.2kbps
CCITT A-LAW	8k	16bit	64 ~ 128kbps

視頻：

圖像分辨率 —— 幀數(shù)

占用帶寬(kbps)

160 × 120 —— 5 ~ 30fps	20 ~ 100kbps
176 × 144 —— 5 ~ 25fps	20 ~ 110kbps
320 × 240 —— 5 ~ 30fps	40 ~ 200kbps
352 × 288 —— 5 ~ 25fps	40 ~ 220kbps
640 × 480 —— 5 ~ 30fps	120 ~ 1000kbps
720 × 576 —— 5 ~ 25fps	120 ~ 1500kbps

國際電信聯(lián)盟 G 系列典型語音壓縮標準的參數(shù)比較

算法	類型	碼率 (kbit/s)	算法延時 (ms)
G.711	A-Law / μ -Law	64	0
G.722	SB-ADPCM	64/56/48	0
G.723.1	MP-MLQ/ACELP	6.3/5.3	37.5
G.726	ADPCM	16/24/32/40	0
G.727	Embedded ADPCM	16/24/32/40	0
G.728	LD-CELP	16	< 2
G.729	CS-ACELP	8	15

PCM的8K采樣率的由來：Nyquist(那奎斯特)定理認為如果以最高頻率2倍的速率采樣，就可以將信號完整地恢復到模擬形式——大多數(shù)聲音都低于4KHz；
A-law與u-law，都使用壓縮算法在8位中得到12-13位的PCM質(zhì)量，某些情況下u-law的聲音質(zhì)量稍好于A-law；如果需要u-law到a-law的轉(zhuǎn)換，則由u-law國家負責；
編碼器分類：波形編碼器——PCM、ADPCM，利用波形冗余特性編碼的壓縮技術；源編碼器——利用聲音產(chǎn)生的源特性，只發(fā)送原始語音的簡化特征信息，包括LPC（linear predictive coding），CELP（code excited linear prediction compression），MP-MLQ（multipulse, multilevel quantization）等
G.7xx系列與PCM等的關系，前者是標準，后者是算法；
衡量編碼優(yōu)劣的標準：bit率，時延，復雜度，質(zhì)量；
語音質(zhì)量的評測：主觀評測MOS（mean opinion score，平均意見得分），由人根據(jù)主觀感受給出；客觀評測PSQM（Perceptual Speech Quality Measurement，知覺語音質(zhì)量測量），由計算機根據(jù)某些客觀數(shù)據(jù)給出。

總結(jié)

以上是生活随笔為你收集整理的各种语音编码总结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。