Problem
TURN_INDICATORS_SHAPE is defined as (1, INPUT_T), but generated NPZ data and several converter paths store turn indicators with INPUT_T + 1 values, matching the history window with current frame included.
The model currently works around this by using:
turn_indicator = inputs["turn_indicators"][:, :-1]
inside the encoder, while the turn-indicator target uses the last two values.
Impact
The training path can still run because the model slices the input internally, but the shape constant is misleading and can cause problems for:
- dummy input generation;
- benchmark tools;
- ONNX export/testing;
- schema validation;
- future refactors that rely on the declared shape.
This is a schema consistency issue rather than a direct training-target corruption bug.
Expected behavior
The constants should distinguish between:
- the raw NPZ/history shape:
INPUT_T + 1 turn-indicator values including current frame;
- the encoder conditioning shape:
INPUT_T values after dropping the current frame;
- the target computation, which needs the last two raw values.
The code should use explicit names for these shapes instead of relying on an implicit [:, :-1] workaround.
Problem
TURN_INDICATORS_SHAPEis defined as(1, INPUT_T), but generated NPZ data and several converter paths store turn indicators withINPUT_T + 1values, matching the history window with current frame included.The model currently works around this by using:
inside the encoder, while the turn-indicator target uses the last two values.
Impact
The training path can still run because the model slices the input internally, but the shape constant is misleading and can cause problems for:
This is a schema consistency issue rather than a direct training-target corruption bug.
Expected behavior
The constants should distinguish between:
INPUT_T + 1turn-indicator values including current frame;INPUT_Tvalues after dropping the current frame;The code should use explicit names for these shapes instead of relying on an implicit
[:, :-1]workaround.