dotLab (@dotLab_App) header
dotLab (@dotLab_App) profile picture

Verified media offload for macOS. Every file read back, hashed, and written through to the disk before we say "complete". https://teapawt.net/t.co/LlCli2Sowy

Tokyo, JP
Joined August 2026
Photo by dotLab (@dotLab_App)Photo by dotLab (@dotLab_App)
1
4
23,952
.Lab 1.5.0 — Codex HDE support Following up on my earlier comment that verification can't hold once encoding is involved. I measured it on set, and here's where it landed. What it does Offloads directly from the Codex HDE virtual volume (…_hde). Finder can't — every file reports 0 bytes and the encoder runs as you read, so Finder writes empty files. .Lab reads to EOF and trusts only the bytes it received. Every encoded file is written, read back from the destination, and verified (xxHash64). ASC MHL v2 is written. ALE/BIN sidecars are included even though they only exist on the physical volume. Tested on ALEXA Mini LF (121 GB → 75.7 GB) and ALEXA 35 (251 GB → 149.7 GB). Two independent offloads of the same card gave byte-identical HDE files. What it doesn't do / things to know Verification is against the encoder's output, not the ARRIRAW on the card. It proves the encoded file landed intact. Nothing can compare against the card without a decoder. Source re-read (paranoid mode) is not performed on HDE. A second read of the same virtual file comes back from cache and never touches the card — measured: 4695 MB from disk on the first read, 7 MB on the second. .Lab says so on the job instead of pretending. Sizes shown before the copy are Codex's estimates; they run high (97.5 GB estimated → 75.7 GB actual). If free space is below the estimate you get a confirmation, not a block. Sync and Watch Folder don't accept the HDE volume as a source — sizes aren't known until read, so "unchanged" can't be decided. If you need the stronger guarantee, keep ARRIRAW. That's the honest answer, not a workaround.
1
3,280
.Lab — Part 1: Why copying footage needs its own tool "Isn't it just a copy app?" "Can't I just drag and drop?" Fair questions. Here is the problem. Heat. A marginal cable. A card or drive that has aged. An error the OS reported that nobody was looking at. Any one of these can leave you with a file that is corrupt, or a folder that will not open at all — while the copy itself looked like it finished normally. I have had that moment of dread more than once. When the material cannot be shot again, finishing the copy is not the same as having the copy. What closes that gap is comparing the data before and after it moved. That comparison is what verification is. Those of us who manage data for a living run tools that do this every day. But they tend to be expensive, and built for people who already know the vocabulary. So we built .Lab. It is for videographers and photographers who feel uneasy about handling their own footage — and for the people on a crew whose job is not data management, but who end up doing it anyway. dotlab.kotetsu.work
87
Hello — first post. We built .Lab because we wanted fewer people to lose footage. Media offload for macOS. Safe, fast, and simple — every file read back from the drive, hash-checked, and confirmed written before we call it complete.
73