> For the complete documentation index, see [llms.txt](https://stage-precision.gitbook.io/grid/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stage-precision.gitbook.io/grid/timeline/timeline-recording-and-export-guide/verify-timecode-and-synchronization.md).
# Verify Timecode and Synchronization
Verify Timecode stability, packet synchronization, frame-rate alignment, and dropout behavior before starting time-critical Timeline recordings.
Before starting a time-critical recording, verify that the incoming Timecode is both **stable** and **synchronized correctly with Grid Studio**.
A Timecode source can provide valid values while still arriving with unstable or poorly synchronized timing. For recordings such as Camera Tracking, both aspects are important.
***
## Open the Timecode Monitoring Tools
Select the Timecode Provider that will be used for the recording.
This can be, for example:
* MTC
* LTC
* Media Input Timecode
Open the **Timecode** tab in the Inspector.
In the upper-right corner of the Timecode section, two monitoring tools are available:
* **Timecode Quality Graph**
* **Time Inspector**
Use both before an important recording to verify the incoming timing source.
***
## Timecode Quality Graph
The **Timecode Quality Graph** shows how consistently the incoming Timecode progresses and how well it can be aligned with the Grid Studio Project timing.
The graph can display three different signals:
* **Raw Input**
* **Processed**
* **Interpolated**
Use the checkboxes at the bottom of the graph to show or hide the individual signals.
For recording workflows, the **Interpolated** signal is usually the most important one to inspect.
### Timecode Interpolation
The incoming Timecode frame rate can be lower than the configured **Project FPS**.
For example:
* Project: `60 FPS`
* Timecode: `30 FPS`
In this case, a new Timecode frame is only received for every second Project frame.
Grid Studio interpolates the incoming Timecode to provide timing information for the frames between the received Timecode values.
The default interpolation mode is **Adaptive Interpolation**.
### What to Look For
The goal is a stable and flat **Interpolated** line without unexpected spikes or fluctuations.
A clean line indicates that the interpolated Timecode is consistently aligned with the Project timing.
With **Adaptive Interpolation**, small repeating waves may sometimes be visible.
This can happen when Grid Studio and the external Timecode generator are not synchronized to exactly the same timing reference.
The Timecode itself can still be valid, but the interpolated timing may move slightly relative to the Project frame boundaries.
For time-critical recordings, this can result in recorded Keys not landing exactly on the expected Project frames.
### Full Frame Interpolation
If frame-accurate alignment is required, use **Full Frame Interpolation**.
Full Frame Interpolation aligns the generated Timecode positions to complete Project frames and prevents intermediate or partial-frame timing positions.
This is particularly useful when:
* the Project FPS is higher than the incoming Timecode frame rate
* Grid Studio and the Timecode source do not share the same timing reference
* recorded Keys need to align exactly with Project frames
* recording timing-critical data such as Camera Tracking
After changing the interpolation mode, check the **Interpolated** signal again.
A stable, flat line indicates that the Timecode is cleanly aligned with the Project frame timing.
{% hint style="info" %}
For the most reliable frame-accurate recordings, use matching frame rates where possible and synchronize Grid Studio and the external Timecode source to the same **external clock / Genlock reference**.
{% endhint %}
***
## Time Inspector
The **Time Inspector** shows how incoming Timecode messages are positioned relative to the Grid Studio **Process Tick**.
Each white line represents the timing of an incoming Timecode update.
### What to Look For
Ideally, the white lines remain consistently at the **same horizontal position** over time.
If they stay stable, the Timecode source and Grid Studio are running in a consistent timing relationship.
### Timing Drift
If the white lines slowly move from one side of the Time Inspector to the other and eventually wrap around to the opposite side, the Timecode source and the Grid Studio Process Tick are not running at exactly the same rate.
This means that the frequency of the incoming Timecode updates is slightly faster or slower than the Grid Studio Process Tick.
For example, the Timecode values themselves may still be correct, but their arrival position continuously shifts relative to the Grid Studio processing cycle.
This usually indicates that the **Timecode source and Grid Studio are not synchronized to the same external timing reference**.
{% hint style="warning" %}
For timing-critical recordings such as Camera Tracking, the white timing lines should remain stable instead of continuously drifting across the Time Inspector.
If continuous drift is visible, verify the external synchronization / Genlock configuration of both Grid Studio and the Timecode source before recording.
{% endhint %}
***
## Project FPS and Source Rate
The **Project FPS** defines the maximum temporal resolution of the recording.
Ideally, the Project FPS, incoming data rate, Timecode frame rate, and overall system synchronization should be configured consistently.
If the source updates more slowly than the Project FPS, new recording data is only written when new Parameter data is available.
If the source updates faster than the Project FPS, not every incoming update can be stored.
For reliable time-critical recordings, matching frame rates throughout the signal chain is recommended wherever possible.
{% hint style="info" %}
For Camera Tracking and other timing-critical recordings, Grid Studio should also be synchronized to an **external clock / Genlock source** where available.
See the dedicated **Synchronization / Genlock** documentation for details.
{% endhint %}
***
## Timecode Drop Behaviour
Timecode Providers define how Grid Studio should react if the incoming Timecode source is lost.
This behavior is configured using **Drop Behaviour** in the Timecode Provider settings.
For example:
**Continue with Internal**
allows Grid Studio to continue using its internal timing if the external Timecode signal drops out.
Choose the Drop Behaviour according to the requirements of the recording setup.
{% hint style="warning" %}
A Timecode dropout during an active recording can affect the resulting timing.
Always verify the Timecode source and the configured Drop Behaviour before starting an important Take.
{% endhint %}
