使用反向音訊時，真正重要的細節可歸納成四個可預期的群組:輸入檔案的容器、編解碼器與大小;解碼後音訊的時長、通道數、取樣率，以及取樣預算;輸出格式(永遠是新編碼的 16 位元 PCM WAV);以及純本機的處理模型(所有位元組都留在瀏覽器分頁內)。事先掌握這些細節，能把憑感覺的工作流程變成可預測的工作流程，因為當任何數值超出範圍時，工具會回報一則明確的限額訊息，而不是產出部分結果。反向本身是一項乾淨、以取樣為單位的操作:每個可接受的通道會被完整讀取、獨立反轉，再以交錯的 WAV 幀順序、在原始取樣率下寫回，浮點取樣會被裁剪到 -1 到 1 的範圍，並對應到有號 16 位元 PCM。音高、節奏、響度與容器中繼資料不會被標準化、修改或複製。下列章節會逐一說明各細節群組，接著展示精確的三步驟工作流程，然後說明在最終 WAV 中應驗證哪些項目。
決定解碼是否開始的輸入檔案細節
檔案選擇器接受常見的 MP3、WAV、M4A、AAC、Ogg 與 WebM 音訊 MIME 類型，但選擇器與實際的解碼器是兩道不同的檢查。選擇器只看容器;而該容器內部的編解碼器是否能實際解碼，則由瀏覽器的 Web Audio 實作決定。例如一個熟悉的副檔名(像 M4A 或 Ogg 檔案)，仍可能在特定瀏覽器或作業系統上解碼失敗，因為底層缺少對應的編解碼器。當解碼失敗時，反向音訊工具會回報解碼錯誤，而不會產生部分或靜音的檔案。
壓縮後的來源檔案也必須不超過 50 MB。此限制適用於你交給選擇器的檔案位元組數，而不是解碼後的長度，因此一個檔案大小小、執行時間卻極長的壓縮檔，仍可能在稍後的解碼後音訊檢查中被拒絕。任何超出輸入限制的檔案都不會被部分處理;它會以一則明確訊息被拒絕，並清除先前的下載(若有的話)，以免舊的成功結果被誤認為新的結果。
在按下「反向」之前，值得檢查的解碼後音訊限制
檔案解碼成原始取樣後，四項相互作用的限制會決定反向是否能執行。當這些數值中任何一項超出範圍時，工具會拒絕處理解碼後的音訊，而不是將它截斷。
| 限制 | 允許範圍 | 為何重要 |
|---|---|---|
| 解碼後時長 | 5 分鐘以內 | 避免分頁執行長時間的解碼工作 |
| 通道數 | 1 到 8 個通道 | 涵蓋從單聲道到 7.1 環繞的常見配置 |
| 取樣率 | 8,000 到 192,000 Hz | 涵蓋電話語音到高解析度音訊 |
| 通道取樣預算 | 30,000,000 個總取樣數(幀數 × 通道數) | 防止即使是小型壓縮檔也產生意外龐大的解碼陣列 |
通道取樣預算是最容易忽略的細節。它是幀數乘以通道數的結果，因此一個執行 5 分鐘的 48 kHz 立體聲片段會使用大約 28.8 million 個通道取樣，並維持在上限之內;而相同長度、96 kHz 八聲道的片段則會超過上限。請同時檢查這四項限制，而不只是選擇器中的檔案大小，因為一旦解碼完成，執行時間與通道配置才是決定性的因素。
如何在瀏覽器中反向音訊
- 選擇一個支援的音訊檔案(最多 50 MB)，並可選擇性地在內建播放器中預覽原始音訊，讓你知道來源的實際聲音。當同一個資料夾中存在多個相似檔名時，特別建議用原始預覽來確認選對了檔案。
- 選擇反向音訊，並等待所有解碼後的通道取樣在目前分頁中以本機方式完成反向。正式版本與測試套件都執行同一個反向函式，因此奇數長度、偶數長度與多聲道片段都會以一致的方式處理。
- 預覽結果、驗證其時長與音訊屬性，然後下載 PCM16 WAV。這個下載是新編碼的檔案，不是原始串流反向播放後的結果，因此請在將它視為最終版本之前，同時聆聽結果的開頭與結尾。
輸出檔案細節:WAV 下載實際包含的內容
下載的檔案永遠是新編碼的 PCM16 WAV，絕對不是原始 MP3、M4A、AAC、Ogg、WebM 或壓縮 WAV 反向播放後的版本。每個由瀏覽器解碼的浮點取樣會被裁剪到 -1 到 1 的範圍、對應到有號 16 位元 PCM，並以小端序寫入:負的滿刻度對應到 -32768，正的滿刻度對應到 32767，任何超出範圍的浮點數值會在量化前先被箝制。因為輸出未經壓縮，最終的 WAV 通常遠比來源檔案大，而將 32 位元浮點取樣縮減為 16 位元整數時，可能會改變最低有效位元上的數值精度。
反向處理會保留解碼後的時長、取樣率與通道數，並將每個事件移至從結尾往回測量的位置。在立體聲檔案中，左聲道與右聲道會各自獨立反轉，然後再以正確的 WAV 幀順序重新交錯，因此立體聲輸入會保持立體聲。本工具不會標準化響度、移除靜音、主動改變音高、拉伸時間或修復削波，結果是全新的音訊檔案而非帶標籤的容器，因此專輯封面、ID3 標籤、章節、循環標記、編碼器設定、壓縮位元率以及其他容器專屬欄位都不會被複製。當你還需要淡入淡出、修剪、編解碼器選擇、中繼資料保留或母帶處理控制時，請在完整的音訊編輯器中完成這些工作。
本機處理與 URL 處理細節
每個步驟都在目前的瀏覽器分頁中執行。檔案會被讀入 ArrayBuffer，由 Web Audio 解碼，逐通道反轉，編碼為 PCM16 WAV，並透過一個暫時的本機物件 URL 回傳，瀏覽器會用該 URL 提供內建預覽與下載連結。原始檔案與最終 WAV 各自會取得獨立的短效期物件 URL，而選擇另一個檔案、再次執行作業或離開頁面時，這些 URL 就會被釋放，避免過時的資料繼續留存。用於解碼的 Web Audio context，同樣會在作業結束或被新作業取代時關閉。
由於解碼、反向與編碼都在本機進行，檔案位元組、解碼後的取樣、檔名與結果都不會上傳到 Lizely。這項本機工作流程是進行音效設計實驗、反向語音檢查、轉場效果、取樣檢查與錄音結尾檢查時值得記住的細節之一;若想進一步了解同一工具在隱私面的細節，請參閱使用反向音訊時檔案是否會被上傳的指南。至於底層的解碼步驟，Web Audio 的 decodeAudioData 方法定義了瀏覽器在判斷特定檔案究竟能否轉換成取樣時所遵循的契約。
下載後的結果驗證細節
驗證是最後一組重要細節，也是最容易抓到靜默錯誤的環節。請將工具回報的時長、通道數、取樣率與檔案大小，與你預期的數值比對，然後在實際會用到的編輯器或播放器中開啟下載的 WAV。瀏覽器預覽成功，並不代表每台較舊的裝置或 DAW 都支援相同的 WAV 通道配置或高取樣率，因此請在實際使用的環境中測試，而不只在瀏覽器中測試。請聆聽反向檔案的開頭與結尾:原本的結尾現在會變成下載檔案的開頭，任何位於來源結尾的雜訊、喀嗒聲或削波，都會出現在結果的開頭。當數值相符、檔案能順利開啟，且兩端聽起來都正確時，反向後的 WAV 就準備就緒可供使用。
若你正在權衡各種選項，使用音訊等化器時，真正重要的細節有哪些對此有詳細說明。