從影片中擷取音訊作為快速的線上測試，意思是執行一個本機瀏覽器工具，它只從您的檔案抽取音軌，並將其儲存為可下載的 Opus WebM 檔案，全程不需上傳，也沒有伺服器端處理介入。影片轉音訊轉換器就是圍繞這個流程打造的：您從裝置中挑選支援的 MP4、WebM、MOV、M4V 或 Ogg 檔案，按下「Extract audio」，讓瀏覽器播放影片的同時即時錄下所公開的音軌。播放結束後，產生的 WebM 音訊檔案會連同量測到的長度與檔案大小一起顯示，讓您判斷結果是否符合測試目標。當您想對一個簡單問題快速得到答案——這個剪輯是否有可重複使用的音訊、這段音軌實際聽起來如何、或我的瀏覽器是否能處理容器內的編解碼器——而又不想投入更重的工具、安裝軟體，或將影片送到遠端服務時，這個設定就很實用。因為資料完全不會離開這個分頁，同一個瀏覽器分頁可以反覆用來比較不同的剪輯或同一來源的版本，卻不會在別人的基礎設施上留下任何副本。
為何本機測試通常是較佳的選擇
公開網路上大多數的音訊擷取頁面都遵循一個熟悉的模式：挑選檔案、等待上傳、觀看伺服器處理串流，然後下載結果。這個模式對於一次性處理您不在意分享的剪輯沒什麼問題，但並不符合大多數人說想測試音訊取時的真正需求。測試執行通常是一個快速的檢查，往往針對敏感或尚未發布的剪輯，使用者希望在決定是否花更多時間投入專案之前先得到答案。將檔案送到遠端服務會帶來三個問題：隨檔案大小增加的上傳與下載時間、一份放在您無法控制之基礎設施上的檔案副本，以及一個取決於伺服器為編解碼器、位元率與容器所選預設值的結果。
基於瀏覽器的測試消除了上述三個疑慮。檔案在您當前的分頁中解碼，音軌由瀏器自身的媒體 API 取，最終的 WebM 檔案透過瀏覽器在您離開頁面時撤銷的暫存物件 URL 提供。若結果不如預期，您關閉分頁，原始剪輯仍留在原處。對於單純想在投入完整工作流程之前確認擷取是否可行的使用者來說，這樣的來回過程遠短於需要上傳的替代方案，隱私方面也更加清晰，因為這個頁面絕不會留存您檔案的副本。
影響測試的檔案與編解碼器限制
在執行測試之前，先確切了解本機工具會接受與拒絕哪些項目會很有幫助，因為這些限制是實際的，並且在頁面試載入您的檔案時立即可見。產品規格刻意訂得嚴格，以保持工具輕量化，並避免瀏覽器在處理較長的剪輯時耗盡記憶體。事先了解限制，能讓測試從一場猜測遊戲變成快速的「是或否」檢查。
| 限制 | 數值 | 其控管的項目 |
|---|---|---|
| 來源檔案大小 | 上限 500 MiB | 限制單次執行的記憶體與解碼工作量 |
| 解碼後長度 | 上限 5 分鐘 | 限制每次測試的播放擷取時間 |
| 最大尺寸 | 每邊 4096 像素 | 避免解碼過大的影格 |
| 最大像素面積 | 總計 3840 × 2160 像素 | 限制播放期間的瀏覽器資源使用 |
| 輸出容器 | WebM 音訊 | 測試完成時您實際下載的內容 |
| 輸出編解碼器與位元率 | Opus 128 kbps | 重新編碼的音軌，非原始壓縮封包 |
另一個經常讓初次使用者感到意外的限制是編解碼器支援。檔名或 MIME 類型只能識別容器，而非其中的編解碼器。MP4 可能封裝 H.264 影像搭配 AAC 音訊，在現代瀏覽器中順利解碼；也可能封裝較少見的編解碼器組合，導致覽器無法播放。本機測試會明確拒絕這些剪輯，而不是產生一個無聲的檔案——這對於一個旨在首次使用即可信任的工具來說，是更安全的行為。
如何逐步執行測試取
這個程序很短，因為這個工具的設計初衷就是讓您在投入更重的方案前先試一試。您挑選一個檔案，讓瀏覽器播放的同時僅錄製音軌，然後下載產生的 Opus WebM。頁面本身會引導您完成每個階段，若發生任何狀況會以清楚的訊息停止，您可以對不同的剪輯重新執行測試，而不必從頭來過。
- 挑選一個有音軌的支援本機影片。MP4、WebM、MOV、M4V 與 Ogg 檔案若低於 500 MiB 且長度不超過五分鐘，是快速測試的最佳候選。剪輯必須有實際的音軌；沒有聲音的影片會明確失敗，而不會產生無聲輸出——這正是您在驗證檔案是否包含音訊時所期望的行為。
- 選擇 Extract audio，並在影片即時處理期間保持分頁開啟。瀏覽器會在您當前的分頁中解碼檔案、播放底層媒體串流，並使用 MediaRecorder 僅以 128 kbps Opus 在 WebM 容器中擷取音軌。進度標會跟隨播放時間，前景預覽在取進行時保持靜音。關閉或重新整理分頁會取消測試，因此請保持視窗聚焦，且在播放結束前不要離開。
- 檢查長度與檔案大小，然後下載 Opus WebM 音訊檔案。處理完成時，頁面會顯示量測到的長度與產生的檔案大小，讓您能將測試輸出與來源進行比對。產生的 WebM 會以已知的媒體長度進行修補，讓相容的播放器能回報有限的時間軸，下載本身則使用覽器在您離開頁面時撤銷的暫存物件 URL。
這個三步驟圈就是整個測試的全貌。如果輸出聽起來符合預期，您就擁有了一個可用的基準；若不符合，失敗模式會告訴您接下來該嘗試什麼，而您的來源檔案完全沒有移動過。
輸出聽起來如何，以及為何採用 WebM
成功測試的結果是一個包含 Opus 音軌的 WebM 容器。兩項設計選擇動了這個輸出，兩者從錄製過程中皆可見到。首先，這個工具仰賴瀏器內建的 MediaRecorder API，它會即時錄製所指派的串流。其次，WebM 中的 Opus 是錄製器會接受的第一個廣泛支援的純音訊 MIME 類型，這讓頁面得以脫對重型第三方編解碼器相依性的需求。其權衡在於，您取得的檔案不是 MP3、WAV、AAC、FLAC，也不是原始壓縮音訊封包的無損複製；它是一段以 128 kbps 重新編碼的 Opus 音軌，這對語音與一般音樂而言已有足夠餘裕，但無法取代製作母帶。
即時取也說明了測試的耗時。一段一分鐘的影片通常需要約一分鐘來處理，因為瀏覽器基本上是在播放剪輯的同時進行錄製。例如，一段三分鐘的測試剪輯會執行 3 分鐘 × 60 秒每分鐘 = 180 秒的處理時間，幾乎完全對應其播放時間；五分鐘的剪輯則會逼近上限，並產生明顯較大的 Opus WebM 檔案。這個線性關係是最容易記住的一點：測試時間對應來源時間，因為工作是發生在播放過程中，而非另一次的快速處理。若您需要比播放更快的音訊處理速度，本機瀏覽器的路徑並不合適，桌機編碼器才是正確的選擇。
若想進一步了解編解碼器選擇與限制之間的交互作用，準確度、編解碼器與限制指南會從略為不同的角度說明同樣的限制。
測試執行失敗時該怎麼辦以及下一步該嘗試什麼
由於這個工具會將多數失敗模式以可見的訊息呈現，失敗的測試通常並不神祕。常見的原因可歸納為四大類，每一類各自指向不同的下一步。
第一類是容器支援。MP4、WebM、MOV、M4V 或 Ogg 格式的檔案會被接受，但清單之外的任何格式——MKV、AVI、WMV、FLV——會在一開始就被拒絕。重新命名副檔名並不會改變底層的容器，因此正確的下一步是將來源重新封裝到支援的容器，而不是用不同的檔名重試。
第二類是已接受容器內部的編解碼器支援。MP4 可能封裝瀏覽器無法解碼的影像與音訊編解碼器，這是最常見的「支援的副檔名」卻仍在首次嘗試時失敗的原因。將來源重新編碼為廣泛支援的編解碼器組合，或從不同的匯出預設重新取得原始剪輯，通常能解決問題。
第三類是尺寸或長度限制。超過 500 MiB、解碼後超過五分鐘、或任一邊寬度超過 4096 像素的檔案，會在播放開始前就被擋下。對於快速測試，最簡單的解決方法是先用本機影片工具將來源剪輯或縮小，然後在較小的檔案上重新執行擷取。
第四類是瀏覽器對底層 API 的支援。某些瀏覽器並未在媒體元素上公開 captureStream，或未公開工具可使用的 MediaRecorder MIME 類型，特別是 Safari 在這個特定工作流程上表現可能不穩。改用現行基於 Chromium 或 Firefox 的瀏器，通常足以解決這個問題。
若上述類別皆不符合您所遇到的情況，頁面會顯示具體的錯誤——解碼錯誤、不支援的錄製器、空的輸出、無效的長度、過大的尺寸，或已取消的工作——而最可靠的下一步是在同一瀏覽器中使用一支已知良好的短剪輯再試一次。這第二次執行本身也是一項有用的測試，因為它能在您花時間排查原始來源之前，先確認工具在您的機器上是否能正常運作。
延伸閱讀：從影片擷取音訊：訣竅與常見錯誤。