現場混音器上的 Solo Safe 與 Mute Safe 差在哪裡？

快速結論 — solo safe 通常會讓某一路徑在其他路徑被 solo 時仍然可聽見；mute safe 則通常用來保護某一路徑，避免它受到間接的 mute 指令影響，例如 mute group、DCA、automation 或 scene。不同 console 的名稱與作用範圍可能不同。請在每個輸出目的地都啟用的情況下，實際測試特定機型；並區分暫時性的操作例外與已儲存的 show 需求，同時記錄受保護路徑、指令來源、預期狀態、scene 行為、負責人與重置條件。

目錄

1. 定義這兩種保護
2. 選對正確的 safe
3. 了解作用範圍與路由
4. 測試 console 狀態
5. 記錄交接內容
6. FAQ

定義這兩種保護

Solo safe，在某些系統上也叫 solo isolate，通常是避免某一路徑在其他 channel 或 bus 被 solo 時，因為隱含邏輯而被靜音。常見例子是 effects return：當你 solo 一個 vocal input 時，若 reverb return 仍可聽見，就更容易保持聽感上的上下文。

Mute safe 通常是保護某一路徑不受一種或多種間接 mute 指令影響。依照 console 不同，這些指令可能來自 mute groups、DCA 或 VCA mute、automation、scene，或 macros。channel 自己的 mute key 可能仍然可用，或者目前的 mute 狀態會被鎖定；這必須依照原廠行為確認。

這些保護解決的是不同的控制問題。它們不會修好路由、避免削波，也不保證某一路徑一定會到達每個目的地。

選對正確的 safe

讓效果跟著被 solo 的來源一起保留

如果某個 input 在會抑制非 solo 路徑的模式下被 solo，它的 send 可能仍會送進 reverb，但 reverb return 卻因隱含邏輯而被靜音。只有在你需要聽見帶有濕訊號上下文的診斷結果時，才把 return 設成 solo-safe。並確認該 return 不會把其他不相關、同樣送進該效果的來源一併暴露出來。

保護路徑不受群組指令影響

mute safe 可以讓 talkback、announcement、timecode、播放，或緊急通訊路徑排除在大型 mute group 之外。這種例外必須是刻意設定的。因為一個被保護的 channel，可能會讓原本預期「按一顆鍵就能讓舞台安靜」的操作員感到意外。

保護設定不被 scene 叫回覆蓋

當需求是關於 snapshot，而不是 mute group 或 solo 邏輯時，請使用 recall safe、recall scope，或 parameter filters。只保護必要的參數即可。若只需要 head-amp gain 固定，卻把整個 input 都設為 safe，可能會把過期的 EQ、路由或 mute 狀態保留下來。

暫時排障時，避免留下永久 safe

臨時的 line-check override 在檢查完成後應該移除。否則下一個 scene、mute group，或緊急操作的行為，可能就會和排練時不同。每一個暫時性的例外都要指定負責人與重置點。

了解作用範圍與路由

safe 作用在某種控制關係上，不一定等於完整的 audio path。在依賴它之前，先確認：

• solo 是會破壞主混音，還是只送到一條 monitor bus；
• console 使用的是 PFL、AFL、SIP、additive、exclusive，或其他 solo 模式；
• mute safe 會忽略哪些 mute 來源；
• 直接的 mute key 是否仍可用；
• safe 是否套用在 input、bus、matrix、effect return，或 output 路徑；
• pre-fader send、direct output、recording 與 network output 是否也會跟著 mute；
• linked 或 stereo 路徑是否共用 safe 狀態；
• scene 是否會 recall safe 本身，以及哪些使用者權限可以修改它。

若是聆聽模式，請參考 PFL 與 AFL。若是群組行為，請閱讀 DCA 與 subgroup。這兩篇會說明相鄰的訊號與控制概念；但都不能取代 safe 狀態測試。

測試 console 狀態

1. 儲存或記錄已知的起始 show 狀態。
2. 為路徑、每個目的地，以及它必須抵抗的指令命名。
3. 讓一個低電平、容易辨識的測試訊號通過該路徑。
4. 在啟用 safe 之前，先確認一般 solo 或 mute 動作的結果。
5. 只啟用預定的 safe，然後重複那個指令。
6. 檢查 FOH、監聽、effects、matrix、recording、stream，以及通訊 feed。
7. 載入相關的 scenes，並同時驗證受保護的參數與所有未受保護的參數。
8. 針對直接控制、群組控制、DCA/VCA 控制、macros 與 automation，分別測試，若適用皆要驗證。
9. 清除暫時性的 safes，並證明一般 show 控制已恢復正常。
10. 儲存已核准的檔案，並記錄 console 型號、firmware、scene、操作員與結果。

不要在開著 PA 的情況下，沒有控管計畫就去測試破壞性的 solo-in-place 或 output mute 行為。請從靜音或安全的監聽音量開始，並遵循 console manual。

記錄交接內容

在 Techrider.live 中，請讓路徑名稱與輸入列表及路由備註保持一致。邀請負責的工程師編輯並儲存同一份 Rider，然後在 show-file 決策變更後檢視 history。為離線的場館交接輸出一份有日期的 PDF。

Safe-state 檢查清單

• 定義被覆蓋的確切控制指令。
• 確認 console 的術語與 firmware 行為。
• 只保護最小且有用的路徑或參數集合。
• 測試所有受影響的目的地與 scenes。
• 驗證直接 mute 與緊急流程。
• 為暫時性的例外與重置點加上標示。
• 只儲存並記錄已驗證的狀態。

FAQ

混音器上的 solo safe 是什麼？

solo safe 一般是指：當其他路徑被 solo 時，某個 channel、bus 或 return 不會因為隱含邏輯而被靜音。有些原廠把它稱為 solo isolate，但也有些原廠對「solo safe」的定義不同，因此一定要先確認特定 console 的行為。

混音器上的 mute safe 是什麼？

mute safe 一般是保護某一路徑不受間接 mute 指令影響，例如 mute groups、DCA/VCA mutes、automation 或 macros。它對 channel 自己的 mute key 與 scene recall 的影響，會依 console 而不同。

solo safe 和 mute safe 有什麼差別？

solo safe 會改變 solo 監聽時發生的事；mute safe 則會改變 mute 指令到來時發生的事。recall safe 則是第三種功能，用來保護參數不被 scenes 或 snapshots 改寫。

效果 return 要設成 solo safe 嗎？

當工程師需要聽見被 solo 的來源及其效果時，可以這麼做。也要確認是否有其他來源共用同一個 return，因為讓它保持可聽，可能會暴露比預期更多的訊號，或讓故障排除變得混亂。

mute safe 會跟著 console scene 一起 recall 嗎？

這取決於 console 型號、firmware、show-file 結構、recall scope，以及使用者設定。不要假設；請實際測試 safe 狀態是全域的、儲存在 show 裡，還是會隨每個 scene 叫回。

讓每個例外都看得見

在 Techrider.live 建立一份最新的 Rider，為每個受保護路徑與其重置條件命名，並提供給場館一份能說明「為什麼看起來像 mute 或 solo 例外」的交接資料。

---

最後更新：2026-09-21 · 已針對 solo、mute、recall、routing 與 show-file 交接差異完成審閱。