一個基於本機瀏覽器的影片轉音訊替代方案，會在當前的分頁中解碼所選擇的 MP4、WebM、MOV、M4V 或 Ogg 檔案，並將擷取到的音訊以 128 kbps 的位元率寫入一個 Opus WebM 檔案——來源檔案永遠不會被上傳，而且輸出結果會一直留在你瀏覽器的記憶體中，直到你將它儲存為止。這個單一的差異點，正是這種做法與典型的「上傳到伺服器再轉檔」轉換器之間的區別：瀏覽器並不是把影片串流到遠端的轉碼器，而是透過瀏覽器內建的 HTMLMediaElement 播放該檔案，然後由 captureStream 將其中的音軌提升為一個 MediaStream，再由 MediaRecorder 把已編碼的音訊區塊寫入一個可供下載的 Blob。實作這條路徑的 Lizely 工具就是 Video to Audio Converter，它的設計理念是：只要瀏覽器本身已經能解碼來源，就不需要額外的編解碼器相依或上傳步驟，就能把影片轉成音訊。本文將說明這個替代方案的運作方式、規範它的各項限制、輸出檔案的格式，以及在哪些情況下，桌面型音訊編輯器仍然是更好的選擇。
為什麼讀者會尋找影片轉音訊的替代方案
大多數免費的「MP4 轉 MP3」網站都遵循一套熟悉的流程：上傳檔案、等待遠端伺服器完成轉檔、再下載結果——有時會夾帶廣告，有時需要註冊才能下載，偶爾還會在音訊上加上浮水印。這樣的作業流程在實務上有不少缺點，也因此驅使使用者尋求不同的選項。隱私是第一個考量，因為上傳影片意味著第三方可以看到它的內容、檔名，甚至常常包含其中繼資料，而且你無法確認該檔案在轉檔後是否已被刪除。速度是第二個考量，因為對於短片在慢速網路環境下，上傳本身所花費的時間，往往比實際轉檔還要久。格式涵蓋範圍則是第三個：許多熱門的轉檔工具號稱「任何格式都能轉 MP3」，但實際上會拒絕 MOV、M4V 或 Ogg 的上傳、移除中繼資料，或套用過於激進的預設位元率，導致人聲或音樂的品質明顯下降。
對於碰到上述摩擦點的使用者來說，其實存在著其他的替代途徑。像 FFmpeg 這類的命令列工具可以在不上傳的情況下擷取音訊，但前提是你必須先安裝它、具備可用的編解碼器版本，並熟悉終端機的操作。像 Audacity 或 VLC 這類的桌面編輯器，則能以圖形介面完成相同的工作，但代價是必須安裝數百 MB 的軟體，而且還得花時間學習匯出設定。一個真正在本機瀏覽器中執行的替代方案，則能同時避開這三個問題：檔案不會離開裝置、輸出使用的是瀏覽器本身的編碼器，而唯一的需求就是開啟一個網頁。
本機瀏覽器路徑如何取代上傳步驟
這個替代方案的技術核心，是兩個瀏覽器 API 彼此協作。HTMLMediaElement.captureStream 會把一個即時的 MediaStream 附加到正在播放的影片元素上，而 MediaRecorder 則會把該串流轉換成可儲存為 Blob 的已編碼資料區塊。Video to Audio Converter 同時運用了這兩者：它將使用者選擇的本機檔案載入媒體元素，等待中繼資料載入完成，確認至少有一條音軌，接著衍生出僅含音訊的 MediaStream，再以第一個支援的 Opus WebM MIME 類型、以 128 kbps 的位元率來錄製該串流。由於錄製的內容就只是 MediaRecorder 的資料區塊，因此這個工具完全不需要安裝 MP3、AAC 或 FLAC 的編碼器——這些格式需要額外打包一個獨立的編解碼器函式庫，而這個工具刻意避免這樣的負擔，以維持載入速度與廣泛的可攜性。
輸出的是一個內含 Opus 音軌的 WebM 容器，而不是原始壓縮封包的直接拷貝；而且在許多媒體播放器或播客託管平台眼中，WebM 音訊檔和 MP3 並不相同。重新編碼本身就有可能改變音質與檔案大小，相較於來源檔，因此把結果視為原始檔的「忠實鏡像」是錯誤的心態。想要進一步了解同一條管線的即時行為，可以參考 real-time local extraction guide，其中詳細說明了播放擷取的時序控制，以及錄製區塊是如何被拼接成最終 Blob 的。
使用瀏覽器工具將影片轉為音訊
整個流程刻意設計得很短：開啟頁面、選擇檔案、等待擷取完成、儲存結果。
- 選擇一個受支援的、帶有音軌的本機影片——可以是 MP4、WebM、MOV、M4V 或 Ogg 檔案，檔案大小上限為 500 MiB，解碼後的長度不得超過五分鐘。
- 選擇「Extract audio」並在影片以即時方式處理的過程中保持分頁開啟——瀏器會播放媒體元素，而 MediaRecorder 只擷取音軌；處理期間預覽會被靜音，但只要瀏覽器支援媒體元素取，擷取到的串流中仍然會包含音訊。
- 確認長度與檔案大小，然後在進度標籤結束時下載 Opus WebM 音訊檔，或者使用 Cancel 控制項來捨棄此次作業。
進度標籤是依據播放時間而非處理速度來更新，因此一段一分鐘的影片通常大約會在一分鐘左右完成。下載是透過一個可撤銷的 Object URL 來提供，因此錄製出來的 Blob 只會在分頁持有它的期間存在——若在儲存前就關閉或重新整理頁面，該檔案就會消失。
支援的輸入、輸出格式與檔案的實際樣貌
這個工具強制實施一組嚴格的輸入限制，目的是將記憶體、播放時間與瀏覽器資源的使用量控制在合理範圍內。解碼後的影片長度不得超過五分鐘，任一邊的尺寸不得超過 4096 像素，總面積不得超過 3840 × 2160 像素。檔案本身的大小則必須小於或等於 500 MiB。此外，檔名或 MIME 類型只能標示出一種「可能的容器」——瀏覽器仍須支援容器內部的編解碼器，這也就是為什麼兩個副檔名同為 .mp4 的檔案，行為可能會截然不同。
| 限制項目 | 數值 |
|---|---|
| 可接受的容器 | MP4、WebM、MOV、M4V、Ogg |
| 檔案大小上限 | 500 MiB |
| 解碼後長度上限 | 5 分鐘 |
| 單邊尺寸上限 | 4096 px |
| 總面積上限 | 3840 × 2160 px |
| 輸出容器 | WebM |
| 輸出編解碼器 | Opus，以 128 kbps 錄製 |
如果影片完全沒有音軌，工具會明確地回報錯誤，而不是產生出沒有聲音的檔案。至於解碼錯誤、不受支援的錄製器、空的輸出、無效的長度、超過尺寸限制，或是作業被取消的情況，都會以清楚的訊息中止工作，而不是默默地產生一個損壞的 Blob。錄製完成後，WebM 容器會被修補為已知的媒體長度，讓相容的播放器回報一個明確的時間軸，而不是顯示「長度不明」。這個修補動作是透過一個經過稽核的 duration writer 來執行，因此分段產生的檔案在瀏覽器與桌面播放器中仍能正常播放。
覽器相容性與本機替代方案的極限
這個替代方案非常適合用於短片、且能接受 WebM 音訊檔的情境——例如從一段螢幕錄影中擷取一段人聲、音樂參考片段或環境音。它比較不適合用於長篇錄製、多聲道保存、無損製作、精密的剪輯，或是任何必須以 MP3、AAC、WAV 或 FLAC 作為交付格式的情境。在這些需求下，具備正確匯出設定的專用桌面音訊編輯器仍然是最佳選擇，而這個工具的說明文件也明確地將生產性質的工作導向那些工具。
瀏覽器的支援程度則是另一道界線。這個工具鎖定的是一條通用且實用的本機瀏器路徑，並未為了補足不足而加入龐大的媒體相依元件，也不會承諾目前瀏覽器所無法提供的格式支援。Safari 以及部分其他瀏覽器可能不會開放 captureStream 或相容的 MediaRecorder MIME 類型，在這種情況下，這個工具就無法完成工作，並會顯示明確的錯誤訊息。MDN 的 MediaRecorder 參考文件是查詢這些底層 API 現行瀏覽器支援狀況的最佳起點。
最後，在法律界線上，它與任何音訊擷取流程並無二致：只能在你擁有或有權擷取並再利用的內容上使用。這個工具無法繞過 DRM、平台存取控制、受保護的串流、遠端 URL 或著作權限制，也無法從瀏覽器不被允許解碼的來源中擷取音訊。
若想更深入了解，請參閱 Video to MP3 in Your Browser: What You Actually Get。