在瀏覽器中將影片轉成音訊，所需的時間剛好等於來源影片的長度，因為瀏覽器是以即時速度播放媒體串流，而 MediaRecorder 只負責擷取其中外露的音軌。這套瀏覽器內部的處理流程並沒有捷徑：每一秒的音訊都必須被播放、由 MediaRecorder 編碼器取樣，再依發生的時間寫入輸出容器。因此，一段 1 分鐘的影片處理起來大約要 1 分鐘，而一段 5 分鐘的剪輯則大約需要 5 分鐘。你所看到的進度標籤是跟隨播放時間，而非 CPU 使用率，這就是為什麼即使你的電腦看起來幾乎沒在忙，進度仍會穩定推進。這個即時的限制同樣適用於錄製現場麥克風、螢幕畫面或遠端串流，這也是這個工具會要求你保持分頁開啟的原因。一旦了解這個機制，你就能預先規劃：選擇較短的剪輯、停留在分頁上，並把經過的計時器視為實際經過的時間，而不是剩餘工作量的指標。
為什麼擷取時間會等同於影片長度
「為什麼轉成音訊會跟影片本身一樣久」最直接的解釋是：瀏覽器內部的路徑是建立在即時播放擷取之上，而非檔案掃描。這個工具會把你選定的影片載入 HTML <video> 元素中，要求瀏覽器透過 HTMLMediaElement.captureStream 外露其媒體串流，再要求 MediaRecorder 只從該串流錄製音軌。播放從時間零開始、跑到結尾，MediaRecorder 則在音訊編碼區塊產生時將其寫入。工作結束的時間點是 video 元素觸發 ended 事件，而非編碼器處理完某些已排隊的封包時。
由於每一秒的輸出音訊都對應到來源播放的 1 秒，執行時間會與長度呈線性關係。一段 30 秒的剪輯大約 30 秒完成；一段 4 分鐘的剪輯則大約 4 分鐘完成。把來源長度加倍，等待時間也大約加倍。並沒有獨立的擷取階段可以跑得比播放更快，而瀏覽器也無法預先讀取並在時間軸外壓縮音訊，因為 MediaRecorder 被綁在驅動 <video> 元素的同一個播放時鐘上。
這也是為什麼靜音預覽雖然無害，但仍值得一提。處理過程中網頁會把 video 元素靜音，避免使用者聽到來源兩次；但只要瀏覽器支援媒體元素擷取，所擷取的 MediaStream 仍會帶有來源音訊。靜音播放只能關閉喇叭，無法讓被錄製的音軌也變成無聲。
瀏覽器內建的音訊擷取實際如何運作
在可見的按鈕背後，是一條小而明確的處理流程。在你挑選本地檔案、瀏覽器完成載入中繼資料後，這個工具會驗證三件事：檔案可以解碼、解碼後的影格尺寸落在公布的上限之內，以及至少存在一條音軌。如果任何一項檢查失敗，工作會以顯示訊息的方式中止，且不會產生任何檔案。這正是為什麼沒有音軌的影片會明確失敗，而不是產生一個無聲的檔案。
一旦通過檢查，實作會呼叫 HTMLMediaElement.captureStream，從產生的 MediaStream 中篩選出音軌，再把這個僅含音訊的串流送入一個 MediaRecorder，該錄製器設定為第一個支援的 Opus WebM MIME 類型，位元率為 128 kbps。錄製器的 ondataavailable 處理常式會把每個區塊收集到一個記憶體陣列中。當 ended 事件觸發時，這個工具會把各區塊串接成單一 WebM 容器，將已知的媒體時長修補進 Segment Info 元素，使檔案回報一個有限的時間軸，並透過一個可撤銷的物件 URL 提供下載。在整個流程中沒有任何東西會離開當前分頁：解碼、擷取、錄製與下載產生全部都在本地端進行。
128 kbps Opus 這個目標是經過深思熟慮的取捨。Opus 的播放相容性廣，該位元率對語音和音樂而言都很充裕，且這個選擇讓編碼器維持在瀏覽器原生支援的範圍內。這也是為什麼輸出容器是 WebM 而非 MP3、WAV、AAC 或 FLAC：MP3 編碼需要額外的編解碼器相依，而這個工具的目標是一條通用且本地的瀏覽器路徑，而不加入額外相依。
擷取速度比即時更快的情況
轉成音訊並不一定要耗費整段影片的時間，但只能透過這個瀏覽器內建工具不採用的路徑。常見從影片中取出音訊的方式有三種，它們的行為差異很大。
| 方法 | 典型速度 | 輸出品質 | 執行位置 |
|---|---|---|---|
| 瀏覽器播放擷取 (MediaRecorder) | 即時，與來源時長 1:1 | 以 128 kbps 重新編碼為 Opus | 當前瀏覽器分頁，無需上傳 |
| 容器 remux (串流複製) | 近乎瞬間，無論長度通常不到 1 分鐘 | 原始壓縮封包的無損複製 | 桌面工具或專用處理流程 |
| 完整解碼並重新編碼 (轉檔) | 對壓縮過的 MP4 來源而言比即時更慢 | 取決於目標編解碼器與位元率 | 桌面音訊編輯器或伺服器端處理流程 |
近乎瞬間的路徑只有在來源音訊編解碼器已經符合目標容器所預期的格式時才適用，因此工具可以直接複製壓縮過的音訊封包而無需重新編碼。大多數 MP4 檔案已經內含 AAC，許多 MKV 檔案內部也使用 Opus 或 AAC，因此懂得 remux 的桌面工具可以瞬間完成。瀏覽器內建的 MediaRecorder 無法走這條捷徑，因為它必須外露即時串流並重新編碼成 Opus WebM；對一個已完成的檔案進行 remux，是和錄製即時媒體串流截然不同的操作。
轉檔路徑是三者中最慢的。先解碼每一個音訊樣本，再以選定位元率重新編碼，比單純播放一次檔案還耗工，這也是為什麼一段 1 小時的 MP4 在轉檔流程上可能要花上數分鐘。Video to Audio Converter 介於兩者之間：比 remux 慢，但比完整轉檔快，且可預測性足以讓你依實際經過時間進行規劃。
在知道處理為即時的情況下如何擷取音訊
把擷取視為一項即時工作，會改變你準備它的方式。下列步驟假設你想從一段短的本地影片取得乾淨的 Opus WebM 檔案，並理解等待時間大致會等於剪輯長度。
- 挑選一支實際帶有音軌的支援本地影片。支援 MP4、WebM、MOV、M4V 與 Ogg 容器，容量上限 500 MiB，但瀏覽器仍需解碼其內部的編解碼器，因此僅有支援的副檔名並不足夠。
- 確認解碼後的長度與尺寸落在公布的上限之內。解碼後的影片長度不得超過 5 分鐘，任一邊不得超過 4096 像素，總像素面積不得超過 3840 × 2160。這些限制約束了記憶體、播放時間與瀏覽器資源的使用。
- 開啟 Video to Audio Converter。Safari 與部分其他瀏覽器可能未提供 captureStream 或相容的 MediaRecorder MIME 類型，在此情況下，工具會以顯示訊息的方式中止，而不會產生損壞的檔案。
- 選擇本地檔案。網頁會讀取中繼資料、驗證尺寸，並確認至少存在一條音軌。如果檔案沒有音軌，你會收到明確的失敗訊息，而非無聲的輸出。
- 選擇 Extract audio 並保持分頁開啟。進度標籤會跟隨播放時間，你可以隨時按下 Cancel 來停止目前的工作。
- 等待 ended 事件。一段 1 分鐘的影片通常大約需要 1 分鐘；一段 5 分鐘的影片大約需要 5 分鐘。預覽是靜音的，但擷取到的串流仍帶有原始音訊。
- 檢查回報的時長與檔案大小，然後下載 Opus WebM 檔案。容器已修補過測量到的時長，相容的播放器會顯示有限的時間軸。
即時限制與需要注意的事項
有少數輸入會破壞播放擷取的約定，這些情況通常會以顯示訊息呈現，而不是悄悄產生損壞的檔案。解碼錯誤、不支援的錄製器、空輸出、無效時長、過大的尺寸，以及被取消的工作，都會以訊息中止。這種明確的行為是有意設計：比起產生一個播放零秒或帶著錯誤時間軸的 WebM 檔案，工具更傾向於清楚的失敗。
實務上有兩個瀏覽器層級的注意事項。首先，Safari 與部分其他瀏覽器可能根本未提供 captureStream 或相容的 MediaRecorder 格式；若錄製器無法建構，工作會在播放開始前中止。其次，容器內的音軌就是被錄製的那一軌。工具不會承諾目前瀏覽器無法提供的格式支援，也不會嘗試退而求其次改用伺服器端編碼器。
對於不符合即時路徑的工作，公布的指引是使用專用的桌面音訊編輯器，並確認其匯出設定。長時間錄音、無損製作工作、多聲道保存、精確裁剪，以及特定的交付編解碼器，這些都落在瀏覽器內建 MediaRecorder 模型之外，強迫它們走即時擷取是錯誤的取捨。Video to Audio Converter 是為以下情境而設計的：你想從一段剪輯中抽出語音、音樂、環境音或參考音軌而不必上傳，且 WebM 音訊是可接受的交付格式。
想深入了解，請參閱 Why Convert Video to Audio: Practical Reasons and Limits。
想深入了解，請參閱 Will Audio and Metadata Be Preserved After a Video Crop?。