專業分軌路由 (Routing) 與 Stem 輸出命名規範
 與 Stem 輸出命名規範.png)
Send（送訊）分為 Pre-Fader 與 Post-Fader 兩種。Pre-Fader 指的是訊號在經過該軌音量推桿（Fader）之前就被送出，因此推桿拉到最低時，Send 出去的訊號依然存在；Post-Fader 則是經過推桿之後才送出，推桿歸零就等於 Send 歸零。這兩者在實務上的用途不同：殘響（Reverb）與延遲（Delay）通常使用 Post-Fader，這樣當你把某軌拉小聲時，它的空間殘響也會跟著變小，聽起來才自然；而用於側鏈觸發（例如讓低音跟著大鼓閃避）的訊號，通常使用 Pre-Fader，避免因為推桿調整而影響觸發穩定度。
Return 則是 Aux 通道的另一種稱呼，特別是在 Ableton Live 與 FL Studio 這類帶有「Return Track」概念的 DAW 中。Return 上的處理器是「共享」的，這代表十個軌道可以共用同一台殘響，大幅節省 CPU。但共享也意味著彈性降低——你無法對個別軌道單獨調整殘響的參數。因此專業流程中常見的做法是「分層」：主殘響放 Return 共享，特殊殘響（例如只有主唱才有的長尾巴）則用 Insert 直接掛在該軌上。
群組路由（Group／Submix）與 Summing 的實務
群組路由是 Stem 製作的骨幹。它的概念很簡單：把同性質的軌道先匯集到一個群組，再從群組送往主輸出。以一首流行歌為例，常見的群組劃分會是「鼓組」「低音」「吉他」「鍵盤」「主唱」「和聲」「效果」。這個劃分不只是整理上的方便，它同時定義了你的 Stem 輸出單位——因為絕大多數情況下，一條群組就是一條 Stem。
群組的另一個好處是「匯流排處理」（Bus Processing）。你可以在鼓組群組上掛一台 SSL 風格匯流排壓縮器，讓所有鼓件一起被「黏」起來，這種效果是逐軌壓縮做不到的。同樣地，主唱群組上可以掛輕微的匯流排 EQ 與飽和器，讓主唱與和聲形成一個完整的主體。這些處理會在輸出 Stem 時一併被渲染進去，也就是說，你的 Stem 不只是「音量平衡後的集合」，而是「帶著群組處理的完整成果」。
Summing 指的是訊號在匯流排上的相加過程。數位環境下的 Summing 理論上是完美的，但問題往往出在「增益結構」（Gain Staging）。當你把十幾軌訊號同時灌進一個群組，群組的峰值很容易突破 0 dBFS，於是你被迫把群組推桿拉低，卻又發現群組壓縮器的觸發量因此改變了。專業的做法是在每一軌進入群組前就先做好增益控制，讓群組的輸入維持在合理範圍（例如峰值 -6 dBFS 左右），這樣群組處理器的行為才會穩定、可預測。
側鏈、平行處理與多軌輸出的路由設計
側鏈（Sidechain）是路由中相對進階但極常見的技巧。它的原理是把某一軌的訊號「繞道」送到另一軌的處理器作為觸發來源。最經典的應用就是「大鼓觸發低音的壓縮器」，讓低音在大鼓出現時瞬間讓路，避免低頻打架。要做到這件事，你需要一條從大鼓通往低音軌側鏈輸入的路由；而這條路由的來源如果設定為 Pre-Fader，就不會因為大鼓推桿的調整而影響觸發的穩定度。
平行處理（Parallel Processing）則是另一種路由思維：把同一個來源訊號分成兩路，一路保持乾淨，另一路重度處理，最後再混回一起。最常見的就是平行壓縮（Parallel Compression，又稱紐約壓縮），用來在保住原始動態的同時增加厚度。在 DAW 中實現平行處理有兩種方式：一種是複製軌道，另一種是使用 Send／Return。前者對於 Stem 輸出比較友善，因為兩條軌道可以一起被收進同一個群組；後者則比較省資源，但輸出時要確保 Return 的訊號有被正確匯入對應的 Stem。
多軌輸出（Multi-Output）則是虛擬樂器層級的路由。例如一套鼓取樣器（如 Superior Drummer、Kontakt）可以輸出 8 到 16 軌，讓你分別對大鼓、小鼓、Hi-Hat、Tom、Overhead、Room 做個別處理。這個設定必須在樂器內部就先做好，否則你後面的混音會被綁死。專業的模板通常會預先把這類多軌輸出接好，讓每一次開新專案時都省下大量設定時間。
路由常見錯誤與除錯思路
最常見的路由錯誤可以歸納為幾類。第一是「雙重監聽」（Double Monitoring），也就是同一軌訊號同時經由兩條路徑抵達主輸出，造成音量異常變大或相位問題。這通常發生在你不小心同時開啟了 Direct Monitoring 與 DAW 的軟體監聽。第二是「幽靈送訊」，也就是 Send 送到一個你忘記存在的 Return 軌，導致 Stem 輸出時多出莫名的殘響。第三是「群組漏接」，某軌忘了指定到群組，結果它只出現在主輸出，卻沒有出現在任何 Stem 裡。
除錯的順序建議由外而內：先確認主輸出的內容是否正確，再逐一 Solo 各群組，檢查每個群組的聲音是否與預期相符，最後逐一 Solo 個別軌道，確認沒有軌道脫隊。另一個好習慣是「命名先行」——在開始混音之前就把所有軌道、群組、Send／Return 全部命名完成。當你的路由名稱清楚時，大腦在除錯時的認知負擔會大幅降低。
三、Stem 輸出的定義、類型與實務規範
Stem 這個詞在業界經常有誤用。有人把所有分軌都叫 Stem，也有人把 Stem 當成「比較少的軌道」。為了溝通精準，我們需要先定義清楚。
Stem 與 Multi-track 的差別
Multi-track（多軌）通常指的是「原始錄音軌」的集合，例如 24 軌的鼓、貝斯、吉他、人聲，每一軌都是未經（或僅輕度）處理的素材。Stem 則是「經過處理與平衡後的群組輸出」，例如「鼓組 Stem」「音樂 Stem」「人聲 Stem」。關鍵差異有三個：第一，Stem 通常是群組而非單軌；第二，Stem 帶有該群組的處理（EQ、壓縮、空間效果）；第三，Stem 全部相加起來，應該要等於（或極接近）最終的立體聲混音。
這個「相加等於混音」的特性，是 Stem 最重要的品質檢核點。如果你交付的 Stem 全部匯入後，聽起來和原混音差很多，那表示你的路由有問題：可能是某軌漏掉、某個 Return 沒被匯入、群組處理被重複計算，或是主輸出上的母帶處理沒有被排除。實務上，專業交付會同時附上「Stereo Mix（含母帶處理）」與「Stems（不含母帶處理）」，並在文件裡說明差異。
常見 Stem 分類與分類邏輯
Stem 的分類沒有唯一標準，取決於交付對象與用途。以下列出幾種常見情境的分類方式，供你作為模板參考。
選擇分類邏輯時，請優先考慮「接收方會怎麼用」。如果對方是遊戲引擎，音樂與音效一定要分開，因為它們走不同的混音匯流排；如果對方是影視剪輯，對白與音樂必須分開，因為對白需要動態控制；如果對方是另一位混音師，軌道可以分得細一點，因為他有能力處理細節。分得太粗，對方沒有彈性；分得太細，對方要自己做群組，反而增加工作量。一般來說，6 到 12 軌是音樂類 Stem 的舒適區間。
交付格式、取樣率、位元深度與響度標準
格式選擇上，WAV 是業界通用標準，幾乎沒有例外。若對方有特別要求，才考慮 AIFF（macOS 生態較常見）。壓縮格式（MP3、AAC）原則上不用於 Stem 交付，因為它是有損壓縮，會在後續處理中放大失真。若必須傳送大檔，建議使用無損壓縮如 FLAC，並在交付說明中註明。
取樣率（Sample Rate）與位元深度（Bit Depth）的選擇，取決於專案類型。影視、遊戲、廣播類專案通常使用 48 kHz 或 96 kHz，因為要與影片格數、系統時脈對齊；純音樂專案則常見 44.1 kHz 或 48 kHz。位元深度建議一律使用 24-bit，理由是它提供約 144 dB 的動態範圍，足以容納混音過程中的所有峰值，並且在多次匯入匯出時不會累積量化誤差。32-bit float 則適合「中間過程」的交換，因為它不會削頂（Clipping），但檔案較大，且部分舊系統不支援。
響度（Loudness）方面，Stem 交付有一個重要原則：Stem 不加母帶限制器，也不做最終響度提升。Stem 的任務是「忠實呈現混音中的各元素」，響度處理應該發生在最終的母帶階段。因此在輸出 Stem 時，請確認主輸出上的 Limiter、Maximizer 已被繞過（Bypass），否則每個 Stem 都會被獨立限縮，把它們加起來就會產生嚴重的失真。至於 Stem 的目標響度，一般建議峰值維持在 -6 dBFS 到 -3 dBFS 之間，保留足夠的餘裕（Headroom）。若對方有指定標準，例如 -23 LUFS（EBU R128 廣播標準）或 -14 LUFS（串流參考），則依對方要求處理，但仍建議在母帶階段才做。
Stem 與 Mix、Master 的關係
三者之間的關係可以用一句話概括：「Mix 是答案，Stem 是算式，Master 是最終印刷。」Mix 是混音師的最終立體聲成果；Stem 是這個成果的組成部分；Master 則是針對發行媒介（串流、CD、黑膠、廣播）所做的響度與音色最佳化。理想狀態下，Stems 相加會得到「未母帶處理的 Mix」，而這個 Mix 經過母帶處理後，會得到最終的 Master。
交付時，專業的做法是提供一個完整的資料夾結構，內含：Stereo Mix（可含與不含母帶處理兩個版本）、Stems、Instrumental（去人聲版，若適用）、TV Mix（無人聲主唱的伴奏版，常見於廣告與 KTV 用途）、以及一份交付說明文件（Read Me）。這份文件會載明取樣率、位元深度、響度、版本日期、軌道清單與任何特殊注意事項。這看似繁瑣，但正是這些細節讓你的交付具備「可被信賴」的品質。
四、Stem 輸出命名規範：可讀、可排序、可自動化
命名規範是所有交付細節中最容易被忽略、卻也最容易造成災難的一環。一個好的命名規範必須同時滿足三個條件：人看得懂、電腦排得對、跨平台不出錯。
命名結構的基本欄位
建議的命名結構採用「由大到小」的順序，讓檔案在資料夾中自然排序。一個通用的模板如下：
專案代號_集數或場景_類別_描述_編號_版本_取樣率位元深度.wav
舉例來說：
ABL_EP03_SC12_MX_Theme_01_v04_48k24.wav
ABL_EP03_SC12_DX_Main_01_v04_48k24.wav
ABL_EP03_SC12_FX_Ambience_01_v04_48k24.wav
各個欄位的意義如下：專案代號（ABL）用於識別專案，避免不同專案混在一起；集數或場景（EP03_SC12）用於定位內容；類別（MX／DX／FX 或 Drums／Bass／Vocal）用於分類；描述（Theme／Main／Ambience）用於補充說明；編號（01、02）用於同一類別下的多個檔案排序；版本（v04）用於版本控制；取樣率與位元深度（48k24）用於技術標示，避免對方匯入時搞錯設定。若專案較單純，可以省略集數與場景，只保留專案代號、類別、描述、編號與版本。
編號與排序策略
編號的目的不只是識別，更是「控制排序」。因為大多數作業系統與 DAW 在匯入檔案時，會依照檔名的字母順序排列，所以編號的設計會直接影響匯入後的軌道順序。建議一律使用兩位數以上的補零（01、02、03），不要用 1、2、3，因為 10 會排在 2 的前面，這在匯入時會造成混亂。
若同一類別下有子群組，可以使用階層式編號，例如：
PRJ_Drums_01_Kick.wav
PRJ_Drums_02_Snare.wav
PRJ_Drums_03_Hat.wav
PRJ_Drums_04_Tom.wav
PRJ_Drums_05_Overhead.wav
PRJ_Drums_06_Room.wav
這樣匯入時就會依照 Kick、Snare、Hat、Tom、Overhead、Room 的順序排列，符合鼓組在混音台上的傳統位置，方便對方快速對照。若是版本編號，建議使用 v01、v02 這種補零格式，並在專案結束時保留最新版本即可，歷史版本則移到 Archive 資料夾。
字元限制、跨平台相容與常見地雷
命名時最容易踩到的地雷，就是使用了跨平台不支援的字元。以下是幾個基本原則：
版本控制與交付清單（Manifest）
版本控制是專業交付的關鍵。沒有版本控制的專案，最後一定會出現「Final」「Final_v2」「Final_v2_真的最終」這種災難性命名。正確的做法是：每一次交付都有一個明確的版本號，並在交付說明文件中記錄每個版本的變更內容。例如：
v01 - 初版交付
v02 - 調整低音音量、修正第三段殘響過長
v03 - 依導演要求刪除 00:42 的銅管
v04 - 最終定版，響度確認 -16 LUFS
交付時，建議附上一份 Manifest（交付清單），以純文字或表格形式列出所有檔案與其內容說明。這份清單可以讓接收方在不開啟 DAW 的情況下，快速掌握交付內容。一個實用的 Manifest 範本如下：
檔名
內容說明
取樣率
位元深度
峰值
PRJ_Mix_Stereo_v04.wav
完整立體聲混音（未母帶）
48 kHz
24-bit
-3 dBFS
PRJ_Stem_Drums_v04.wav
鼓組（含群組壓縮與空間）
48 kHz
24-bit
-6 dBFS
PRJ_Stem_Bass_v04.wav
低音（含側鏈處理）
48 kHz
24-bit
-6 dBFS
PRJ_Stem_Music_v04.wav
和聲樂器與合成器
48 kHz
24-bit
-6 dBFS
PRJ_Stem_Vocal_v04.wav
主唱與和聲
48 kHz
24-bit
-6 dBFS
這份清單同時也是你自己的檢查表。在按下「匯出」之前，逐項確認每個檔案的峰值、長度、起始點是否一致。特別是起始點，所有 Stem 的檔案長度必須完全相同，且時間碼對齊（從同一小節、同一影格開始），否則對方在拼合時會出現對不上的災難。
五、實戰工作流程：從 Session 建置到交付
以下把前面的概念整合成一套可執行的流程，適用於專案製作、配樂、Podcast 等各類工作。
開場前的路由模板建置
專業混音師通常會建立自己的 DAW 模板（Template），把常用的路由與命名一次設定好。這個模板至少應包含：一組標準群組（Drums／Bass／Instruments／Vocal／FX）、一組標準 Return（Reverb Short／Reverb Long／Delay／Parallel Compression）、以及完成命名的空軌道。更進一步的做法，是把多軌輸出的虛擬樂器、常用的匯流排處理鏈（Channel Strip）都預先掛好，並做好旁通（Bypass）與取樣率設定。
模板的另一個重點是色彩管理（Color Coding）。為每個群組指定固定的顏色，例如鼓組用紅色、低音用橘色、和聲用藍色、人聲用黃色、效果用紫色。這樣在長時間工作時，視覺辨識速度會大幅提升，也降低把軌道拖錯群組的機率。這件事看似只是美觀，但在幾十軌的專案裡，它就是效率。
混音中的 Stem 管理
在混音過程中，要隨時想著「這些軌道最後會變成哪些 Stem」。建議在專案一開始就在筆記或文字檔中列出 Stem 清單，並在每次新增軌道時確認它被分配到正確的群組。若某軌臨時不確定該歸哪一類，寧可先放在一個「暫存」群組，也不要隨便丟到主輸出。
另一項實務技巧是「階段性匯出」。每隔一段時間就匯出一次 Stem，並實際把它們匯入一個空的專案，確認相加後與 Mix 一致。這個動作可以在問題還小的時候就發現路由漏洞，避免到了截止日前才發現某軌漏掉。這個檢查流程大約只需要十分鐘，卻能省下數小時的補救時間。
交付前的檢查清單
交付前的檢查可以分為技術面與內容面。技術面包含：取樣率與位元深度是否正確、檔案長度是否一致、峰值是否留有餘裕、母帶處理器是否已繞過、是否有任何軌道被靜音（Mute）或獨奏（Solo）忘記取消。內容面則包含：Stem 相加是否等於 Mix、命名是否符合規範、Manifest 是否完整、版本號是否正確、是否有附上 Read Me 說明。
建議把這份清單寫成一個實體檔案放在專案資料夾裡，每次交付前逐項打勾。這不只是為了別人，也是為了未來的自己。當你在半年後被要求「再出一版」時，一份清楚的清單可以讓你在一小時內完成，而不是重新打開專案摸索半天。
六、常見問題與疑難排解
Stem 相加不等於 Mix 怎麼辦？
首先檢查是否有軌道沒有被分配到任何群組。接著檢查 Return 軌是否被正確地收進對應的 Stem。若你使用了母帶處理器（如 Limiter），請確認它在輸出 Stem 時已被繞過。最後檢查群組處理是否被重複計算——例如你在個別軌與群組上都掛了同一台壓縮器，導致聲音被壓縮兩次。逐步 Solo 各群組與各軌道，通常十分鐘內就能找到問題。
對方要求「無效果的 Stem」該怎麼處理？
有些後期流程希望拿到「乾淨」的素材，再由他們自己加上空間效果。這時你需要額外輸出一組「Dry Stem」，也就是把 Send 到 Return 的訊號全部關閉後匯出的版本。建議在交付時同時提供 Dry 與 Wet（含效果）兩組，並在命名上明確標示，例如 PRJ_Stem_Vocal_Dry_v04.wav 與 PRJ_Stem_Vocal_Wet_v04.wav。這樣對方可以依需求選用，省下來回往返的時間。
Stem 要幾軌才夠？
沒有標準答案，但可以依用途判斷：遊戲引擎通常需要 3 到 6 軌（Music、SFX、VO、Ambience 等）；影視剪輯通常需要 3 到 8 軌（DX、MX、FX 及其細分）；給其他混音師的素材則可能需要 12 到 24 軌。若不確定，建議在交付前直接詢問對方，或提供兩種版本（粗略版與詳細版）讓對方選擇。多問一句話，勝過多做三小時。
檔案太大傳不出去怎麼辦？
首先確認是否使用了 32-bit float 或 96 kHz 以上設定，這些都會讓檔案倍增。若確實需要高規格，可以考慮提供 FLAC 無損壓縮，通常可減少 30% 到 50% 的體積。另一種做法是分批傳送，並在 Manifest 中標明批次與順序。千萬不要為了傳送方便而改用 MP3，因為有損壓縮會在對方的後製流程中被放大，最終影響成品品質。
七、結語：規範不是限制，而是專業的通行證
分軌路由與 Stem 命名規範，說到底是一種「為別人著想」的工程習慣。它不會讓你的音樂變得更好聽，但它會讓你的作品更容易被使用、被信任、被再次邀請。在影音創作這個高度協作的產業裡，能夠穩定交付高品質素材的人，往往比只有才華的人走得更遠。
從今天開始，你可以先做一件小事：打開你最近的一個專案，把所有的軌道、群組、Send／Return 全部命名完成，然後依照本文的結構重新整理一次路由。下一次交付時，附上一份清楚的 Manifest 與 Read Me。你會發現，客戶的回信變短了，問題變少了，而你能夠把更多時間花在真正重要的事情上——創作本身。
當你的交付流程變得標準化，你就不再只是「一個做音樂的人」，而是一個可以被依賴的專業製作夥伴。這，就是規範真正的價值。