時碼裡的分號到底說明什麼
時碼末段從冒號變成分號，通常是在提示「這串時碼按掉幀記號顯示」。它解決的是某些分數幀率下，幀計數與人類時鐘長期偏離的問題。但接收交付檔案時，分號只能當提示，不能單獨證明幀位已經按掉幀規則換算。顯示記號和計數演算法必須分開核對。
分號告訴你「這串字想表達掉幀寫法」，不自動告訴你「這串幀位已經按掉幀規則算過」。
為什麼會有掉幀計數寫法
像 29.97 這樣的分數幀率，每秒實際推進的幀數和用整數 30 做時碼編號時的節奏並不完全相同。如果一直按連續整數幀號顯示而不做補償，時碼讀數會逐漸落後於牆上時鐘。
按公式推算，29.97 這種連續計數每天會累計到約一分半的量級。因此，掉幀計數的做法不是把影片幀真的扔掉，而是在時碼編號裡按規則跳過某些編號，讓顯示時鐘與實際經過時間重新靠攏。
常見文字約定會把末段分隔符寫成分號，例如 01:00:00;00。這個符號很有用，因為接收方一眼就能知道檔案正在表達一種掉幀記號。但符號仍然只是字串的一部分。
顯示記號和幀位換算是兩件事
真正的掉幀計算需要在幀編號與時分秒幀之間轉換時執行跳號規則。單純把最後一個 : 換成 ;，只改變了外觀，沒有改變原來那一串數字代表的幀位置。
SlateX 目前交付路徑裡，這兩種行為都存在。缺少結束位置、需要軟體根據入點和時長計算出點時，會走實際的掉幀算術。已經存在的入點或出點字串，則只把末段分隔符改成分號，不做任何幀位換算。
這就是本篇的硬邊界：看到 ;，可以知道交付層把這條字串標成了掉幀寫法；但僅靠這個符號，不能判斷這串數字此前是不是用掉幀規則得到的。
兩處判定「接近 29.97」的容差並不相同
即時側把攝影機標稱率折算成基準率時用的容差是 0.013，匯出側按數值判定是否掉幀時用的容差是 0.02 —— 兩處判定的對象不同，容差也不是同一個數。這意味著位於邊緣的幀率值，在兩處邏輯裡可能得到不同分類。
這類差異不應該被包裝成接收方無需關心的實作細節。只要它會改變時碼採用什麼顯示或計算路徑，就應該在驗收時把檔案裡的實際 FPS、時碼字串和素材放到一起核對。
同樣，不能把「數值接近某個常見幀率」直接等同於整條鏈路已經採用相同計數規則。判斷入口不同，結論就可能不同。
接收方要驗證的是一條真實素材如何對上時碼，而不是只驗證分隔符長什麼樣。
App 即時顯示與交付檔案不是同一套表示
SlateX 的即時鏈目前輸出全冒號時碼，不產生分號表示。也就是說，App 螢幕上現場看到的即時字串，與交付檔案裡可能出現的分號，是兩套不同階段的表示規則。
即時鏈在分數幀率下按分數值推進計數，再用整數幀率把幀數換成字串；它本身沒有掉幀跳號表示。因此，不能因為交付檔案後來出現分號，就倒推現場即時顯示已經按相同規則工作。
接收時應把這兩層分開：現場記錄的原始字串來自哪裡，交付時有沒有重新計算，分隔符是否只是被替換，最終素材對點是否成立。缺一項，都不應把分號當成驗收結論。
怎麼實際核對一條帶分號的時碼
先看該行 FPS 是否與素材和現場記錄一致，再選一條可定位的素材，對照實際入點和經過時長。若檔案裡的結束位置是軟體計算出來的，還要單獨確認它是否走了相應的計數規則。
如果入點或出點是既有字串，就不要只看它是否帶分號。接收方應驗證幀位本身能不能對上素材。只換符號的字串，在外觀上可以很像正確的掉幀時碼，但它的數字仍可能來自另一種計數方式。
因此，分號適合當做「這裡需要檢查掉幀口徑」的提示，不適合當做「這條已經驗證完」的標籤。
FAQ
時碼末段是分號，就能確認它按掉幀規則算過嗎？
不能。分號可以只是顯示層的記號。目前交付路徑對既有時碼字串可能只替換末段分隔符，不重新計算幀位。
掉幀是不是把實際影片幀刪掉了？
不是這裡討論的含義。掉幀計數調整的是時碼編號規則，用來補償分數幀率下連續編號與牆上時鐘的長期偏差。
為什麼同一個幀率值在兩處邏輯裡可能判斷不同？
因為目前兩處「接近 29.97」的容差分別是 0.013 和 0.02。處在邊緣的數值可能落入不同分支，因此接收方應核對實際檔案和素材。
App 螢幕上的即時時碼也會用分號嗎？
目前即時鏈輸出全冒號字串，不產生分號表示。交付檔案裡的分號屬於另一階段的表示，不能反推即時鏈也採用了同樣的掉幀計數。
Axiom One LLC — SlateX。以上數字截至 2026-09-24。