音檔壓縮上載指南：mp3 轉文字 廣東話，16kHz mono Opus 點揀先唔會被拒

一句答你：廣東話錄音上載轉寫「失敗」，九成唔係你嘅錄音有問題，而係你撞咗兩道門 — 一道計體積（單檔 4.5 MB），一道計時長（同步交付 8 分鐘）。壓縮只解決第一道，第二道要靠切件或者改用非同步任務。

好多人第一次上載自己嘅廣東話錄音去轉文字，撞到「檔案太大」或者「音檔超過同步轉寫上限」，第一個反應係「部機壞咗」。其實兩個提示都係契約，唔係故障：一部 48 kHz 雙聲道 WAV 錄咗兩個鐘，單靠壓縮都可能仲係塞唔入同步通道；而一段 9 分鐘嘅 MP3，就算得 3 MB 一樣要行非同步。

呢篇會拆三樣嘢：門檻究竟係幾多、每種格式壓縮完實際有幾大（我哋自己量過）、同埋點解網上成日有人話「16k mono Opus 可以載 60 分鐘」但你點做都唔啱。

想先了解引擎能力同點測準確度，可以睇廣東話語音轉文字實測方法；新手上載嘅完整操作流程，睇上載錄音轉文字教學。想知呢個功能嘅規格一覽同幾時應該用實時定檔案轉寫，可以睇廣東話語音轉文字功能頁。

重點摘要

• 同步上載有兩道獨立的門：單檔 4.5 MB（體積）＋ 同步交付 8 分鐘（時長）。壓縮只拆第一道，唔會拆第二道。
• 支援嘅音檔容器有八款：wav、mp3、m4a／mp4、webm、ogg、flac（連同對應嘅 mime）。
• 【實測數據】11 分鐘粵語語音壓成 16 kHz mono Opus 16k，得 1,241,280 bytes（約 1.24 MB）；同一段錄音壓成 WAV 16k 就要 21,473,258 bytes（約 21.5 MB）— 差 17 倍。
• 【獨家觀察】公開文件寫「16kHz mono Opus 16k ≈ 1.15 KB/s、4.2 MB 可載約 60 分鐘」；我哋實測 16 kbit/s 得 1.85 KB/s，4.5 MB 只載到約 40.5 分鐘。要真正做到 60 分鐘，需要嘅係約 1.25 KB/s — 即 10 kbit/s 左右，唔係 16 kbit/s。
• 長錄音（4 分鐘以上、想一次過交）應該用非同步任務：audio_url 上限 200 MB／4 小時，唔使同 4.5 MB 搏鬥。
• 即時聽寫（WebSocket）唔需要壓縮檔案，反而要 raw PCM16LE 單聲 16 kHz；送錯格式會被即時拒絕而且零計費。
• 壓縮唔係完全免費：低 bitrate 會影響辨識率，壓完之後一定要用你自己嘅音檔跑一次對比。

上載被拒，通常唔係格式錯 — 係兩道門

大部分人只知第一道門（檔案太大），但第二道門更隱蔽，亦更常見。逐個拆。

體積門係指單次上載嘅 request body 唔可以超過 4.5 MB。呢個係平台層嘅硬上限，超咗直接由平台擋返，唔會行到你個應用程式嘅驗證邏輯，所以你見到嘅係一個冇乜解釋嘅錯誤。同一個檔案壓縮完如果仲係超，就係真係唔得。

時長門係指同步交付窗口 480 秒（8 分鐘）。伺服器會先 probe 音檔實際時長，超過就回 400 audio_too_long，附返 duration_seconds 同埋指路去非同步 endpoint。呢個門有一個好嘅設計：喺處理之前就拒，零扣費。即係話你唔會因為檔案太長而俾人扣錢，但你要自己改流程。

格式門就簡單：容器格式要係引擎食得嗰啲。搞掂三道門之後，檔案先會真正開始計費。

睇清楚最右一欄：如果你嘅錄音長過 8 分鐘，正路唔係死命壓細，而係改用非同步任務。想知呢個功能幾時上新、支援咩場景，可以睇廣東話語音轉文字上架公告。 壓到 8 分鐘以內先至係「同步」嘅適用範圍。

支援邊啲音檔格式？八款容器，唔係全部都食

引擎實際支援嘅 audio mime 有以下幾款（呢個係 server 端白名單，唔係「見到個 extension 就試下」嗰種）：

幾個實務提醒：

第一，M4A 唔好以為一定得。同一個 .m4a 檔，meta 標成 audio/mp4 就收，application/octet-stream 就未必。喺手機上轉檔最穩陣係轉 WAV 或者 MP3。

第二，WebM 係最容易踩坑嘅一個。Android 同 Chrome 錄出嚟嘅 WebM 啱啱好就係白名單入面，但如果你中途用其他工具改過檔、變成唔同嘅 mime，就會被拒。

第三，Ogg/Opus 本身已經壓縮過。你唔需要「再壓一次」，只需要確保佢係合法單聲 16 kHz 就可以直接交。

第四，FLAC 係無損保存嘅首選，但唔係上載嘅首選。想留底就留 FLAC，想上載就另外轉一份。

實測：11 分鐘粵語語音，壓完究竟有幾大

呢部分係我哋自己量嘅，唔係抄文件。

測試方法：用 18 段粵語語音樣本（用港嘢自家粵語聲線合成，合共 74.56 秒）合併再循環到 11 分 11 秒（671.04 秒），48 kHz 單聲 PCM 為來源。用 ffmpeg 6.1.1 逐個格式轉碼，記錄輸出檔案實際位元組，再除以實際時長換算每秒體積。最後用 4.5 MB 反推可以載幾長錄音。原始 WAV 係 64,419,918 bytes。

三個結論好直接：

一、格式之間嘅差距係數量級，唔係幾個百分比。 WAV 16k 同 Opus 16k 相差 17 倍（21,473,258 bytes vs 1,241,280 bytes）。如果你啱啱錄咗一個鐘 WAV，壓縮一輪就由「上唔到」變「上到」。

二、48 kHz 對語音轉寫係浪費。 語音嘅有效頻譜去到 8 kHz 左右已經夠用，48 kHz 單聲 PCM 嘅每秒 96 KB 入面有一大半係你唔會用到嘅高頻。降采样到 16 kHz 唔會令辨識度變差，但會令檔案細一大截。

三、Opus 嘅 bitrate 係你嘅旋鈕。 8 kbit/s 換 76.8 分鐘，16 kbit/s 換 40.5 分鐘 — 同一個格式，差近一倍。呢個位要你自己揀，因為質素同容量要你哋自己 trade-off。順帶一提，Opus 本身嘅設計目標就係覆蓋由 6 kbit/s 到 500 kbit/s 嘅闊範圍低延遲語音，標準同封裝格式可以喺Opus 官方文件頁搵到（編碼器 RFC 6716、容器 RFC 7845、RTP 傳輸 RFC 7587）。

點解網上成日有人話「16k mono Opus 可以載 60 分鐘」？

呢度要老實講一件事。

港嘢公開文件寫住壓縮建議係 16 kHz mono Opus 16k，並且寫明「單檔 4.2 MB 可載約 60 分鐘」，換算出嚟約 1.15 KB/s。呢個數字喺網上好多人引用，但佢對唔上實測。 我哋同一段 11 分鐘粵語語音，用 -b:a 16k 轉出嚟係 1.85 KB/s，4.5 MB 只載得約 40.5 分鐘 — 差咗成三成。而家假設你要喺 4.5 MB 塞 60 分鐘，反推需要嘅速率係 1.25 KB/s；實測之下，12 kbit/s 有 1.43 KB/s（約 52.6 分鐘），8 kbit/s 有 0.98 KB/s（約 76.8 分鐘）— 1.15 KB/s 呢個數，就落喺呢兩個級別之間。而 8 kbit/s 對粵語嚟講已經偏緊，中英夾雜同專有名詞會開始受損。

點解會有呢個落差？最可能係用緊「16 kHz 採樣率」去推算「16 kbit/s 碼率」，將兩者當咗同一件事。採樣率 16 kHz 同碼率 16 kbit/s 係完全唔同嘅參數，混用就會差 8 倍左右。

所以正確嘅結論係：如果你要一個鐘以內嘅錄音，用 16 kbit/s Opus 已經好夠（實測 4.5 MB 載 40.5 分鐘）；如果你真係要一個鐘，都要落到 12 kbit/s 左右，或者用非同步任務 — 唔係靠 16k 呢個標籤。 呢個唔係話文件寫錯咗好多，係一個推算口徑嘅落差，值得知道。

ffmpeg 一條指令：把錄音正規化

如果你手頭有 WAV／MP3／M4A，想交去同步通道，最穩陣係轉成 16 kHz 單聲 Opus。指令係（ffmpeg 嘅參數語法可以喺官方文件查；-b:a 係目標碼率、-ac 係聲道數、-ar 係採樣率）：

ffmpeg -i input.m4a -vn -ac 1 -ar 16000 -c:a libopus -b:a 16k output.ogg

逐個參數解釋：

• -i input.m4a — 來源檔，任何支援嘅格式都得。
• -vn — 唔要影片轨。有啲 M4A／WebM 其實帶住 video track，唔加 -vn 有時會出奇。
• -ac 1 — 轉成單聲。正規化 係指把音訊統一成引擎期望嘅格式（單聲、16 kHz、特定編碼），令同一段內容唔論來源機都變成同一種形狀。
• -ar 16000 — 重採樣到 16 kHz。
• -c:a libopus -b:a 16k — 用 Opus 編碼，目標碼率 16 kbit/s。

轉完記得用 ffprobe 睇一眼實際時長同體積：

ffprobe -v error -show_entries format=duration,size -of default=nw=1 output.ogg

如果你要交非同步任務（長錄音），咁就唔使理 4.5 MB 呢個上限，你可以直接交原始檔案。指令可以簡單啲，甚至唔使轉碼：

ffmpeg -i input.m4a -vn -ac 1 -ar 16000 -c:a libmp3lame -b:a 64k output.mp3

咁做嘅唯一理由係加快你上載到雲端嘅速度（你部機同伺服器之間嘅瓶頸），同埋令成批檔案體積一致好管理。真要慳時間，Opus 16k 仍然係最細嘅選擇。

壓縮會唔會整差轉寫？答案係「會，程度要你自己量」

壓縮唔係免費嘅。呢個係 codec 領域一直有研究嘅課題：bitrate 跌落去，語音嘅可辨識度就會開始受影響，專有名詞同中英夾雜嘅詞尤其先出事。

一項 2024 年嘅神經音訊編碼器評測（Codec-SUPERB 輕量基準，2024-09）就專門用 ASR 嘅字錯率做指標去評分唔同 codec 同 bitrate — 佢哋嘅結論係，喺低 bitrate 之下，揀錯 codec 會直接反映成辨識錯字上面。另一篇 2024 年嘅研究（CBRC 編碼器研究，2024-02）比較咗 Opus 喺 6／9／12 kbit/s 嘅客觀質素分數，同時指出 3 kbit/s 級別嘅新一代編碼器已經可以喺主觀測試贏過 Opus 12 kbit/s — 即係話 bitrate 嘅選擇同 codec 嘅選擇同樣影響結果。仲有研究顯示（Opus SILK 頻寬擴展，2024-12），Opus 嘅低碼率語音分支本身已經係為咗極低 bitrate 嘅語音而設計，用頻寬擴展技術可以將 6 kbit/s 嘅質素推到 12 kbit/s 水平 — 換句話講，碼率愈低，愈依賴編碼器自身嘅設計同後期處理。

對你嘅實際意義：壓縮參數唔應該跟住網上抄。 正確做法係揀定一組參數之後，用你自己嘅真實錄音跑一次對比。方法好簡單：

1. 揀 3 段 5 分鐘以內嘅真實粵話錄音（要有中英夾雜同專有名詞）。
2. 原檔轉寫一次，壓縮版再轉寫一次，兩份稿逐句對。
3. 記低專名錯幾多個、數字錯幾多個。
4. 揀返質素夠用、体積又細嗰組。

呢個流程我哋寫成完整測試協議嘅一部分，喺《廣東話語音轉文字實測方法》嗰篇有完整版本（8 類難點、WER／CER 計法、評分表）。你亦可以先睇《廣東話字庫與自訂詞彙實戰》嗰篇，因為壓縮最易出事嗰批詞（人名、品牌、術語）通常就係詞庫要補嗰批。 至於「同一段粵語錄音，16 kbit/s Opus 壓縮前後嘅 WER 差幾多」，我哋仲未有可公開重複嘅測試集數字，所以呢度唔會俾一個數出嚟；上面引用嘅係 codec 領域嘅客觀評測，唔等於港嘢引擎嘅實測結果，讀者要用自己嘅音檔驗。

即時聽寫唔使壓縮檔案：直接送 raw PCM

呢度有個好多人搞混嘅位：即時聽寫（WebSocket）同檔案轉寫係兩套完全唔同嘅輸入協議。

檔案轉寫：你交一個完整容器檔（wav／mp3／m4a…），伺服器自己拆。 即時聽寫：你交一串 base64 編碼嘅 PCM16LE 單聲 16 kHz raw 音訊幀。

細節同 32,000 bytes 等於 1 秒，單一 frame 唔可以超過 640 KB。送錯（例如直接將一個 wav 檔 base64 咗就推上去）會即刻收到 4010 invalid_audio_format，而且係零計費 — 因為 gateway 喺計費之前就拒咗。

所以如果你想「壓縮住上傳」落去即時通道，方向係錯嘅：即時通道要嘅係未壓縮嘅 raw PCM（因為要逐段即時解碼），壓縮只適用於檔案轉寫。兩條通道嘅完整做法分別見即時語音轉文字 WebSocket 教學。

由手機錄音到出稿：一個完整流程

假設你有一段 45 分鐘嘅廣東話會議錄音，喺手機錄低咗（M4A）。

第一步：先睇時長，唔好睇體積。 45 分鐘 > 8 分鐘，呢個已經決定咗你要行非同步任務，壓縮縮到 4.5 MB 都冇用（因為同步通道另外有時長門）。

第二步：需要傳統統上載嘅話，先轉碼。

ffmpeg -i meeting.m4a -vn -ac 1 -ar 16000 -c:a libopus -b:a 16k meeting.ogg

第三步：走非同步任務。 將檔案放喺一個 https 位置（要係 https，唔可以係 http），然後交 audio_url：

curl -X POST https://api.canto-gen.com/v1/asr/jobs \
  -H "Authorization: Bearer $CANTAGEN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"cantogen-asr","audio_url":"https://your-storage/meeting.ogg"}'

提交即回 202，附返 job 編號同輪詢路徑，之後用 GET /v1/asr/transcriptions/{id} 輪詢。

第四步：睇返 audio_url 嘅權限。 呢個 endpoint 係伺服器端去抓你個 URL，所以個檔案要有時效限制（例如 24 小時後失效），唔好放喺永久公開嘅位置。呢個亦係私隱考量：錄音檔案唔應該長期公開。

第五步：收工前刪檔。 逐字稿出咗之後，音檔就冇需要留低，刪咗佢。

如果你唔想自己搞 https 連結，或者你嘅錄音短過 8 分鐘，直接用語音轉錄頁嘅檔案轉寫入面嘅流程就得。

常見問題

mp3 轉文字廣東話，MP3 檔可以直接上載嗎？

可以，MP3 係支援清單入面嘅格式（audio/mpeg）。留意兩件事：MP3 嘅碼率同質素差距可以好大（由 32 kbps 到 320 kbps），低碼率嘅 MP3 本身就已經係有損，再加一層轉碼會再跌質素；另外 MP3 唔支援逐段時間戳，所以淨係要文字，唔好期望有 SRT。

4.5 MB 到底係 4,500,000 定 4.5×1024×1024？

以平台層為準。實務上當成略少於 4.5 MB 就最安全，唔好卡住個位數。

壓到 8 kbit/s 得唔得？慳唔慳到時間？

慳到體積，但未必慳到時間，亦未必慳到質素。實測 8 kbit/s 可以載 76.8 分鐘，但低 bitrate 對粵語嘅聲母同入聲韻尾（-p／-t／-k）影響最直接，專有名詞會最先出事。建議 16 kbit/s 起步，唔夠先降到 12。

我用緊嘅格式唔喺清單入面，點算？

轉。WAV 係最唔會出事嘅目標格式（audio/wav 一定食得）。Windows 錄音機、macOS 語音備忘錄、手機內置錄音 App 出嚟嘅檔，全部可以轉。

壓縮會唔會影響計費？

唔會。計費係按實際音頻時長計，唔係按檔案大小。壓細啲只係令上載快啲、令同步通道有可能收得下，單價一樣。

長錄音非同步提交，等幾耐有結果？

提交即回 202，之後自己輪詢結果。實際等候時間受排隊同音檔長度影響；我哋內部實測嘅處理速度大約係實時嘅十分之一量級（RTF 約 0.096），即係 10 分鐘音檔大約需要 1 分鐘處理時間，再加上排隊。

錄音本身有雜聲，壓縮前定壓縮後處理雜聲好？

壓縮之前。雜聲係錄音品質問題，唔係編碼問題；先做降噪、切除靜音、正規化，最後先壓縮。順序反咗，會將雜聲一齊編碼入去，之後想救都救唔返。

想試下自己嘅錄音壓完會唔會好啲？

拎你最頭痛嗰段會議錄音，用上面嗰條 ffmpeg 指令壓一版，再喺語音轉錄頁上載同原檔各跑一次，兩份稿對一對。API 層嘅限額、錯誤碼同計費方式，睇語音轉寫 API 文件。

---

本文由港嘢內容團隊編輯審閱（editorial review，2026-10-25）。壓縮實測由我哋用 ffmpeg 6.1.1 喺粵語語音樣本上跑，數據表已經附上測試方法同原始位元組。想了解我哋嘅背景，可以睇關於港嘢；有技術問題或者想申請功能開通，聯絡我哋。