時碼裡的分號到底說明什麼

時碼末段從冒號變成分號，通常是在提示「這串時碼按掉幀記號顯示」。它解決的是某些分數幀率下，幀計數與人類時鐘長期偏離的問題。但接收交付檔案時，分號只能當提示，不能單獨證明幀位已經按掉幀規則換算。顯示記號和計數演算法必須分開核對。

分號告訴你「這串字想表達掉幀寫法」，不自動告訴你「這串幀位已經按掉幀規則算過」。

為什麼會有掉幀計數寫法

像 29.97 這樣的分數幀率，每秒實際推進的幀數和用整數 30 做時碼編號時的節奏並不完全相同。如果一直按連續整數幀號顯示而不做補償，時碼讀數會逐漸落後於牆上時鐘。

按公式推算，29.97 這種連續計數每天會累計到約一分半的量級。因此，掉幀計數的做法不是把影片幀真的扔掉，而是在時碼編號裡按規則跳過某些編號，讓顯示時鐘與實際經過時間重新靠攏。

常見文字約定會把末段分隔符寫成分號，例如 01:00:00;00。這個符號很有用，因為接收方一眼就能知道檔案正在表達一種掉幀記號。但符號仍然只是字串的一部分。

顯示記號和幀位換算是兩件事

真正的掉幀計算需要在幀編號與時分秒幀之間轉換時執行跳號規則。單純把最後一個 : 換成 ;，只改變了外觀，沒有改變原來那一串數字代表的幀位置。

SlateX 的交付檔案裡，這兩種寫法各佔一格。已經記著的入點或出點字串分兩路：錄製鏈在停機那一下現採的讀數，會按丟幀規則重渲成一枚合法的 DF 位址——只把末段分隔符改成分號會造出 ;00、;01 這種 SMPTE 裡沒有的號；場記照機器螢幕或面板手抄的讀數逐字不動，只把末段分隔符改成分號。來源位缺失時不猜，數字一律不動，缺的宣告由收工差異表以 TC_SOURCE_UNDECLARED 點名。Duration 是起止兩枚讀數之間的幀精確跨度（不含尾幀），聲明過 DF 的行裡那一格寫成分號形。

這就是本篇的硬邊界：看到 ;，可以知道交付層把這條字串標成了掉幀寫法；但僅靠這個符號，不能判斷這串數字此前是不是用掉幀規則得到的。

接近 29.97 不等於宣告掉幀

一個接近 29.97 的幀率值，不能僅憑數值就認定整條鏈路採用同一種計數規則。處在邊界上的值尤其如此：螢幕上的顯示與交付檔案裡的寫法可能落到不同分類。你能核對的是檔案裡那一格最後寫了什麼，以及這一行的實際 FPS、時碼字串和素材能否互相對上。

接收方要驗證的是一條真實素材如何對上時碼，而不是只驗證分隔符長什麼樣。

App 即時顯示與交付檔案不是同一套表示

螢幕上顯示的即時時碼是全冒號字串，不帶分號。因此，App 裡現場看到的內容，與之後可能出現在交付檔案裡的內容，來自兩套不同的表示規則。

不能因為交付檔案後來出現分號，就倒推現場螢幕當時也按相同規則顯示。

接收時應把這兩層分開：現場螢幕上讀到的是哪一種字串，交付檔案裡寫的是哪一種，分隔符是否只是被替換，最終素材對點是否成立。缺一項，都不應把分號當成驗收結論。

怎麼實際核對一條帶分號的時碼

先看該行 FPS 是否與素材和現場記錄一致，再選一條可定位的素材，對照實際入點和經過時長。出點是抄進來的讀數，那一格要核的是「有沒有被抄過」；Duration 才是算出來的跨度，核它要回到起止兩枚讀數和它們被讀時所用的計數規則。

如果入點或出點是既有字串，就不要只看它是否帶分號。接收方應驗證幀位本身能不能對上素材。只換符號的字串，在外觀上可以很像正確的掉幀時碼，但它的數字仍可能來自另一種計數方式。

因此，分號適合當做「這裡需要檢查掉幀口徑」的提示，不適合當做「這條已經驗證完」的標籤。

FAQ

時碼末段是分號，就能確認它按掉幀規則算過嗎？

不能。分號可以只是顯示層的記號。目前交付路徑對既有時碼字串可能只替換末段分隔符，不重新計算幀位。

掉幀是不是把實際影片幀刪掉了？

不是這裡討論的含義。掉幀計數調整的是時碼編號規則，用來補償分數幀率下連續編號與牆上時鐘的長期偏差。

為什麼同一個幀率值可能落到不同結果？

螢幕上的顯示與交付檔案裡的寫法分屬兩個階段，處在邊緣的數值可能落到不同結果。接收方應核對實際檔案與素材，並讀那一格最後寫了什麼。

App 螢幕上的即時時碼也會用分號嗎？

目前即時鏈輸出全冒號字串，不產生分號表示。交付檔案裡的分號屬於另一階段的表示，不能反推即時鏈也採用了同樣的掉幀計數。

Axiom One LLC — SlateX