There is an issue with the conversion of 9 tasks to lerobot 3.0: misalignment between data frames and video frames.

[Brucexkm]

Hello, I am using your official conversion script link: [Please fill in the link here]. After converting to version 3.0, I encountered an issue where the data frames and video frames are misaligned in 9 specific tasks, which causes an error when loading the LeRobot 3.0 dataset. The problematic tasks are: task_362, task_543, task_392, task_532, task_361, task_570, task_475, task_595, task_620.

[Brucexkm]

Would it be possible to directly provide the data for these 9 tasks that have already been converted to LeRobot 3.0 format? I would greatly appreciate it.

[allenwu-blip]

Frame/video alignment is one of the explicit checks in embodied-data validate (repo). The convert command writes a v3 dataset directly without re-entering the upstream multi-episode cache path that surfaces this class of bug.

v0.1.0 just released — pip install embodied-data to try (release notes).

Would like to run it against tasks 362, 543, 392, 532, 361, 570, 475, 595, 620 to confirm we either avoid the misalignment outright or surface it deterministically — let us know if a small slice can be shared.

[allenwu-blip]

Quick v0.3.0 update — frame/video alignment is now an explicit hard-fail check in embodied-data validate (was SKIP in v0.2 due to no videos). v0.3.0 emits real h264 video files alongside proprio for Beta, and validate cross-checks episode length / fps vs. mp4 duration within ±1 frame on every episode. If you can share a slice from any of tasks 362, 543, 392, 532, 361, 570, 475, 595, 620, we can confirm whether v0.3.0 catches the misalignment deterministically or avoids it outright. pip install --upgrade embodied-data. Release notes: https://github.com/allenwu-blip/embodied-data/releases/tag/v0.3.0

[allenwu-blip]

Per-task frame↔video desync like this is almost always specific episodes where the recorded video has dropped or extra frames relative to the proprio/action stream, so a converter that assumes a 1:1 frame↔video mapping writes a dataset where the data index no longer lines up with the video index — and the v3 loader only discovers it at load time, per task. The 9 task ids you listed are likely the only ones with that upstream drift; the rest convert clean.

The durable fix is to validate frame↔video alignment per episode before training and drop/realign the offending episodes, rather than debugging it at the loader. Checking each task's frame count against its video stream length up front tells you deterministically which of the 9 to exclude.

(disclosure: I maintain embodied-data — its validator has a frame↔video alignment check among its 5 checks that flags exactly which task/episodes are misaligned and exits non-zero, so you get the bad-task list before a training run instead of after. OSS, pip install embodied-data. The pre-validate approach above is the actual fix.)