使用反向音訊時最常見的五個錯誤都源自同一個根本原因：把來源檔案與你實際下載的檔案混為一談。每個被接受的 MP3、WAV、M4A、AAC、Ogg 或 WebM 片段都會被解碼為原始取樣，跨每個聲道獨立反轉，然後重新編碼成一個全新的 PCM16 WAV 檔。原始編解碼器、位元率、標籤、專輯封面與章節標記都不會被複製。輸出是一個全新的音訊檔，而不是原始壓縮串流倒著播放。錯誤通常始於看起來原始編解碼器似乎被保留下來時、熟悉的副檔名仍然無法解碼時、硬性限制毫無預警地中斷工作時，或是預期中繼資料應該會保留下來時。事先了解這些陷阱可以讓你免於重做整個流程、怪錯工具，或是把錯誤格式的檔案交付給你的 DAW。本指南將逐一說明每個錯誤、其背後的確切限制或行為，以及當你在瀏覽器中本地端反向音訊時能避開它們的工作流程。
最耗時間的那些錯誤
大多數反向音訊的失敗可以歸入五類。第一是假設輸出仍保有你原本的編碼。第二是把檔案選擇器視為一種保證，以為任何被接受的容器就一定能解碼。第三是忘記明確的數值限制是為了保護瀏覽器分頁，會拒絕超出限制的檔案。第四是預期中繼資料、封面或章節資料會原封不動地通過反向處理。第五是把成功的瀏覽器預覽當成證據，認為所有下游的播放器、編輯器或裝置都會接受這個結果。每一項之所以會出現，是因為反轉取樣在本質上是一個與「以原始格式把檔案倒著播放」截然不同的操作，而環繞反向音訊的說法常常模糊了這項差異。
預期輸出會保留你原本的編解碼器
最常見的單一錯誤是打開輸出檔，看見它能播放，然後就假設它仍然是 MP3、M4A、AAC、Ogg 或 WebM 串流。事實並非如此。反向音訊工具會把被接受的檔案解碼為原始取樣，反轉每個聲道，然後寫入一個新編碼的 PCM16 WAV。每個由瀏覽器解碼的浮點取樣會被裁剪到 -1 到 1 的範圍，再對應到有號 16 位元 PCM，並以 little-endian 位元組儲存。負滿刻度對應到 -32768，正滿刻度對應到 32767。這代表你下載的 WAV 可能比壓縮來源大上許多，而且把浮點取樣降到 16 位元會改變數值精度。原始編解碼器、位元率、標籤與容器專屬欄位都不會被刻意複製。
| 你上傳的來源 | 你實際下載到的東西 |
|---|---|
| MP3(已壓縮) | 一個新的 PCM16 WAV 檔，而不是倒著播放的 MP3 串流 |
| WAV(已壓縮或 PCM) | 一個重新編碼的 PCM16 WAV，帶有新的 RIFF 標頭，而不是原始位元組 |
| M4A 或 AAC | 一個新的 PCM16 WAV 檔;原始 AAC 訊框在解碼後會被丟棄 |
| Ogg 或 WebM | 一個新的 PCM16 WAV 檔;原始 Vorbis 或 Opus 訊框在解碼後會被丟棄 |
當你需要一個壓縮檔案用於交付時，請在反向處理後，將反轉後的 WAV 單獨跑過一次編碼器，並在實際會使用的播放器中確認這個新檔。
假設每個檔案副檔名都會被解碼
檔案選擇器接受常見的 MP3、WAV、M4A、AAC、Ogg 與 WebM 音訊 MIME 類型，但「接受輸入」與「成功解碼」是兩件分開的檢查。編解碼器的支援與否取決於訪客的瀏覽器與作業系統，而且容器內也可能裝著某個瀏覽器無法解碼的編解碼器。當 Web Audio context 拒絕資料時，工具會回報解碼錯誤，而不是聲稱每個有熟悉副檔名的檔案都一定能用。根據 BaseAudioContext.decodeAudioData 的 MDN 文件，解碼可能在 API 內部靜默失敗，然後以擲回錯誤的形式浮現在外層程式碼中，這正是為什麼本工具會顯示清楚的解碼錯誤訊息，而不是猜測。修正方法是改用其他瀏覽器測試同一個檔案、從來源編輯器以更廣泛支援的編解碼器重新匯出，或是修剪檔案，使其必須在所述限制內通過。
在不知情的情況下撞上限制
瀏覽器會強制執行明確的數值限制，以保護分頁不會因為意外過大的解碼陣列而當機。任何超出限制的檔案會收到一則明確訊息，並且不會被部分處理。如果你更換檔案或在錯誤後重試，先前下載的結果會被清除，這樣舊的成功結果就不會被誤認為是新的結果。
| 限制 | 數值 |
|---|---|
| 壓縮輸入檔大小 | 上限 50 MB |
| 解碼後長度 | 5 分鐘以內 |
| 聲道數 | 1 到 8 個聲道 |
| 取樣率 | 8,000 到 192,000 Hz |
| 總聲道取樣數 | 不超過 3,000 萬(幀數 × 聲道數) |
聲道取樣預算是指幀數乘以聲道數。即使壓縮來源檔在磁碟上看起來很小，卻可能在解碼後展開成非常龐大的陣列，這項限制就是用來保護分頁。以 192,000 Hz 播放五分鐘的立體聲檔會達到 192,000 × 300 × 2 = 115,200,000 個聲道取樣，遠超過 3,000 萬的上限，所以同一個來源在 44,100 Hz 能順利解碼，在 192,000 Hz 就會被拒絕。請根據這些數字規劃你的輸入，而不是根據壓縮檔大小。
相信原始中繼資料會保留下來
反轉取樣會保留解碼後的長度、取樣率與聲道數，但輸出是一個全新的音訊檔，因此並不保證原始中繼資料會留下。專輯封面、ID3 標籤、章節、循環標記、編碼器設定、壓縮位元率與容器專屬欄位都不會被複製。這個工具反轉的是解碼後的可聽取樣資料，而不是編輯或保留來源容器。它也不會做音量標準化、移除靜音、刻意改變音高、拉伸時間，或修復爆音。如果你需要上述任何處理，請把反轉後的 WAV 送進一款提供淡入淡出、修剪、編解碼器選擇、中繼資料欄位與母帶控制選項的音訊編輯器。把 WAV 當成一塊乾淨的原始畫布，而非帶有額外功能的原檔拷貝。
把瀏覽器預覽當成最終答案
成功的瀏覽器預覽只能證明目前的瀏覽器能解碼來源並寫出有效的 PCM16 WAV。它並不保證每台較舊的裝置、NLE 時間軸或硬體取樣器都會接受同一個 WAV 的聲道配置或高取樣率。請確認工具顯示的長度、聲道數、取樣率與檔案大小，接著在實際會用到的編輯器或播放器中打開下載的檔案。立體聲輸入會保持立體聲，因為左聲道被獨立反轉、右聲道也被獨立反轉，兩個聲道會以正確的 WAV 幀順序再次交錯排列，但下游軟體在匯入時仍可能重新對應或下混這些聲道。在結果的開頭與結尾各做兩分鐘的抽樣檢查，就能在檔案送交客戶前抓到大多數聲道順序錯誤與取樣遺失的 bug。
使用反向音訊時跳過這些錯誤
- 選擇一個支援的音訊檔，大小上限為 50 MB;如果想做健全性檢查，可以用內建預覽播放原始檔，確認它就是你打算載入的片段。
- 依據上方表格的限制檢查檔案:檔案大小、長度、聲道數、取樣率，以及 3,000 萬聲道取樣預算。
- 選擇反向音訊，然後等待每個解碼後的聲道取樣在瀏覽器分頁中本地完成反向。
- 預覽結果，然後讀取工具顯示的長度、聲道數、取樣率與檔案大小，並與原始檔進行比對。
- 播放結果的第一秒與最後一秒，確認事件現在看起來是從結尾往回量測，而且沒有任何聲道掉出。
- 下載 PCM16 WAV，在實際會用到的編輯器或播放器中打開它，只有在交付格式需要時才重新匯出為壓縮編解碼器。
由於整個工作流程都在本地端執行，檔案位元組、解碼後的取樣、檔名與結果都不會被上傳。原始檔會取得一個暫時的本地 object URL 供內建預覽使用，完成的 WAV 則會取得另一個獨立的暫時下載 URL。選擇其他檔案、再次執行操作，或離開頁面都會釋放這些過期的 URL，而用於解碼的 Web Audio context 會在操作結束或工作被取代時關閉。
反向處理前的預檢清單
- 確認來源副檔名符合你目前瀏覽器實際能解碼的編解碼器。
- 依據明確的限制檢查長度、聲道數、取樣率與檔案大小。
- 聆聽原始預覽，讓自己在反向處理前先知道來源實際聽起來的樣子。
- 預期 WAV 會比壓縮來源大，而且 16 位元編碼會改變數值精度。
- 決定你是否需要中繼資料、封面、淡入淡出、修剪或音量調整，並把反轉後的 WAV 送進音訊編輯器處理這些步驟。
- 在實際會用到的編輯器、DAW 或播放器中打開最終 WAV，而不是假設瀏覽器成功就等於全面成功。
如果你想在反向處理後做更深入的驗證，請參考 《確認你正確使用反向音訊》 指南，它會以更程序化的順序帶你跑過同樣的檢查。遵循這份清單，就能把反向音訊從一個靠猜測的步驟，變成一項可預測、可重複的本地操作。
延伸閱讀: 合併音訊檔案時的常見錯誤。