VoxMap-Studio: Dual-System Overview

• VoxMap-Studio is a homonymous term for two distinct research systems: one for scalable voxel mapping in robotics and another for speaker diarization annotation.
• The voxel mapping system employs hash table-based occupancy and inflation maps with efficient map-sharing protocols, achieving up to 97% data bandwidth reduction.
• The speaker diarization tool integrates pyannote pipelines for automatic initialization, detailed cost instrumentation, and streamlined annotation workflows.

Searching arXiv for the two cited VoxMap-Studio papers to ground the article and resolve the naming ambiguity. VoxMap-Studio is a name currently used for two distinct research systems on a voxel mapping system for autonomous navigation in large-scale environments, introduced in "A Robust, Task-Agnostic and Fully-Scalable Voxel Mapping System for Large Scale Environments" (La et al., 2024), and an open-source speaker diarization annotation tool, introduced in "voxmap-studio: An open-source speaker diarization annotation tool with built-in cost instrumentation" (Yamaguchi, 25 Jun 2026). The first system addresses task-agnostic spatial mapping, voxel management, and decentralized map sharing for aerial robotics; the second addresses diarization annotation, automatic initialization, and annotation-cost measurement. This suggests that the term denotes a homonymous pair of systems rather than a single research lineage.

1. Scope and nomenclature

In current arXiv usage, VoxMap-Studio refers to two unrelated technical artifacts with different problem domains, system architectures, and evaluation protocols (La et al., 2024, Yamaguchi, 25 Jun 2026). One is a robotics mapping framework centered on hash table–based voxel maps, spatial and temporal priorities, and multi-agent map sharing. The other is a React-based annotation environment for speaker diarization with built-in instrumentation of edit operations and time.

System	Domain	Core description
VoxMap-Studio (La et al., 2024)	Autonomous navigation	A voxel mapping system that can build an adaptable map for multiple tasks
voxmap-studio (Yamaguchi, 25 Jun 2026)	Speaker diarization annotation	An open-source, React-based diarization annotation tool integrated with the pyannote-based diarization ecosystem

The shared name can obscure the fact that the two systems solve different classes of problems. A plausible implication is that citations and implementation discussions benefit from explicit reference to the corresponding arXiv identifier.

2. VoxMap-Studio as a voxel mapping system

In La La et al. 2024, VoxMap-Studio is presented as a voxel mapping system for autonomous navigation in unknown environment, especially for aerial vehicles (La et al., 2024). The system takes as input a stream of range measurements, such as LiDAR point-clouds, together with pose estimates, for example from FAST-LIO. For each incoming scan $P=\{p_1 \ldots p_n\}$ at rate $f_{upd}$, points beyond a configurable input radius $d_{in}$ are discarded, and each surviving point $p_k$ is converted to an integer $3D$ voxel index

$i_k = \lfloor (p_k - o)/res \rfloor$

where $o$ is the map origin and $res$ the chosen voxel resolution.

The front-end organizes updates through two task buffers, $B_{new}$ and $B_{keep}$. If an index does not already appear in one of these buffers, the system either creates a new Voxel object and inserts its pointer into the occupancy map $f_{upd}$0 and inflation map $f_{upd}$1, and into $f_{upd}$2, or—if $f_{upd}$3 already contains it—copies the pointer into $f_{upd}$4. If it is already in $f_{upd}$5, the pointer is moved into $f_{upd}$6.

Occupancy is updated through ray-casting. For each $f_{upd}$7, the system ray-casts along the beam and increments miss counts for traversed voxels and hit counts in the endpoint voxel. The log-odds update is

$f_{upd}$8

with

$f_{upd}$9

The resulting log-odds $d_{in}$0 are clamped between $d_{in}$1, and voxels are reclassified into Occ / Free / Unknown via thresholds $d_{in}$2. Voxels whose occupancy flips to or from Occ are flagged "Occ-changed" (La et al., 2024).

Inflation is handled per voxel through a small inflation look-up table $d_{in}$3 of precomputed neighbor offsets. When a voxel’s Occ-changed flag is set and its center is within $d_{in}$4 of the robot, the system walks $d_{in}$5 to increment or decrement an inflation count $d_{in}$6 in each neighbor voxel; if $d_{in}$7 the neighbor is considered inflated obstacle. The architecture is explicitly designed to be adaptable across local mapping, global mapping, cooperative multi-agent navigation, and high-speed navigation.

3. Data structures, voxel management, and map sharing

The robotics VoxMap-Studio uses both occupancy and inflation maps as chained or open-addressing hash tables of key→Voxel pointer (La et al., 2024). Each Voxel stores its integer key $d_{in}$8, log-odds $d_{in}$9, hit/miss counts, a small vector of neighbor-pointers $p_k$0, and a DLL iterator into the history buffer. Total memory is $p_k$1 for $p_k$2 currently stored voxels, in contrast to an array map of fixed volume $p_k$3, which would be $p_k$4. Hash lookup, insertion, and deletion are $p_k$5 on average; occupancy update per voxel is $p_k$6; inflation per Occ-changed voxel touches $p_k$7 neighbors, where $p_k$8 is precomputed; and history buffer append or remove by iterator is $p_k$9 because the history buffer is implemented as a doubly-linked list.

Voxel retention is governed by spatial and temporal priorities. Spatial priority is controlled through $3D$0 and $3D$1, which limit the distance at which new inputs create voxels and the distance over which obstacles are inflated. Temporal priority is controlled through a user-settable cap $3D$2, which ensures that only the $3D$3 most recently observed or updated voxels are kept. Newly occupied voxels are appended to a global history buffer in insertion order, while voxels in $3D$4 are re-moved and re-appended so that the history buffer remains sorted by most-recently used. Once $3D$5, the oldest voxel is removed from $3D$6 and $3D$7 and freed. Free or unknown voxels may also be immediately placed into a delete-buffer $3D$8 and removed.

A central component for cooperative operation is the map-sharing protocol (La et al., 2024). Because exchanging raw point-cloud streams at 1–7 Mbps across a wireless ad-hoc link is prohibitive, each agent retains a small circular buffer of recently occupied voxel pointers and, at a lower rate such as 5 Hz, broadcasts only the delta of newly Occ voxels since the last transmission. Upon reception, another agent inserts the remote voxel pointers into its own $3D$9 and $i_k = \lfloor (p_k - o)/res \rfloor$0, skipping ray-cast and transmit re-export. In Park/Forest/Urban tests, shared-voxel bandwidth was approximately $i_k = \lfloor (p_k - o)/res \rfloor$1 kbps, compared with raw-sensor bandwidth of approximately $i_k = \lfloor (p_k - o)/res \rfloor$2 Mbps, corresponding to approximately $i_k = \lfloor (p_k - o)/res \rfloor$3 reduction on average; even conservatively, the system reports $i_k = \lfloor (p_k - o)/res \rfloor$4 bandwidth reduction with zero loss in voxel resolution.

4. Performance characteristics and demonstrated robotic use-cases

The mapping system was tested in real world and simulation environment by applying it to local mapping, global mapping, cooperative multi-agent navigation, and high-speed navigation (La et al., 2024). In Park and Forest experiments with 10 Hz LiDAR, total map-update time was approximately $i_k = \lfloor (p_k - o)/res \rfloor$5 ms per frame, including occupancy update of approximately $i_k = \lfloor (p_k - o)/res \rfloor$6 ms, inflation of approximately $i_k = \lfloor (p_k - o)/res \rfloor$7 ms, and memory management of approximately $i_k = \lfloor (p_k - o)/res \rfloor$8 ms. In Urban experiments with 40 Hz solid-state LiDAR, total map-update time was approximately $i_k = \lfloor (p_k - o)/res \rfloor$9–$o$0 ms per frame. Real-world LiDAR logs from three sensors were used, odometry came from FAST-LIO, and mapping ran on a Ryzen 5900HS laptop.

For map resolution and coverage, Park/Forest experiments used $o$1 m and produced full-scene occupancy voxels of approximately $o$2, compared with an array-map count of $o$3. Urban experiments used $o$4 m and produced approximately $o$5 voxels, compared with $o$6 for an array map. Peak memory $o$7 ranged from $o$8–$o$9 MB for local+global maps under voxel-limit tests and $res$0–$res$1 MB for unconstrained full-scene scans.

In local mapping, tuning $res$2 and $res$3 to local field of view yields a non-sliding, non-centered local map whose footprint adapts to where points actually arrive: circular sectors for narrow FOV sensing and full circles for $res$4 LiDAR. In global mapping, removing $res$5 allows the collection of a persistent global map spanning hundreds of meters with full resolution of $res$6–$res$7 m in real time.

The cooperative multi-agent navigation demonstration uses two spotter drones at altitude that scan at 5 Hz with limited FOV but long range and broadcast VoxMap deltas to four traveler drones without onboard LiDAR (La et al., 2024). Reported planning success was $res$8 no-collision in 10 trials, with average flying distance/time of approximately $res$9 m / $B_{new}$0 s and planning call time of approximately $B_{new}$1 ms. The baseline, using onboard $B_{new}$2 LiDAR at 10 Hz and 10 m range, showed approximately $B_{new}$3 collision rate, higher planning CPU of $B_{new}$4 ms, and raw data stream of approximately $B_{new}$5 Mbps versus shared approximately $B_{new}$6 Mbps combined.

In high-speed navigation, a single drone operated at up to $B_{new}$7 m/s with planning horizon $B_{new}$8 m and long-range $B_{new}$9 m narrow FOV (La et al., 2024). Using VoxMap-Studio with $B_{keep}$0 and $B_{keep}$1, the system achieved $B_{keep}$2 success rate, average flight speed $B_{keep}$3 m/s, $B_{keep}$4 s to traverse $B_{keep}$5 m, memory of approximately $B_{keep}$6 MB, and planner call time of approximately $B_{keep}$7 ms. The baseline robocentric sliding grid with $B_{keep}$8 boundary achieved $B_{keep}$9 success, average speed $f_{upd}$00 m/s, planner call time approximately $f_{upd}$01 ms, and memory approximately $f_{upd}$02 MB.

5. voxmap-studio as a speaker diarization annotation tool

In the 2026 paper, voxmap-studio is an open-source speaker diarization annotation tool with built-in cost instrumentation, implemented as a hand-written React single-page application optimized for low-level editing and integrated with the pyannote-based diarization ecosystem (Yamaguchi, 25 Jun 2026). Its interface includes mouse-wheel zoom on waveforms, batch relabel, extensive keyboard shortcuts, and user-selectable color themes. The annotation canvas overlays speaker turns on top of a scrollable waveform, and each turn is a draggable or resizable segment. The tool can load any pyannote-compatible diarization pipeline via a simple REST or local Python bridge.

Automatic initialization is provided by the author’s stride-accelerated diarization engine built on top of the pyannote segmentation model (Yamaguchi, 25 Jun 2026). The engine has real-time factor $f_{upd}$03 on a consumer-grade GPU or MPS Mac, remains usable on CPU, and produces time-stamped speaker embeddings, cluster centroids, and turn boundaries in a single pass. On the Initialize action, the engine’s hypothesized turns are rendered immediately on the canvas, so the annotator edits an existing hypothesis instead of drawing turns from scratch.

The annotation workflow includes confirmation-gated export and phantom attention checks. Every segment carries a boolean human_confirmed flag, and the Export RTTM+JSON buttons remain disabled until all segments have human_confirmed = true and all injected phantoms have been explicitly deleted or marked. By default, approximately one fake segment per 5 min audio, with a maximum of 8, is injected into silent gaps. If the annotator deletes it, the phantom is counted as caught; if it is left untouched, it is missed; if it is listened to and judged real, it is kept. Any missed phantom blocks final export.

The tool provides three configurable assistance modes per session (Yamaguchi, 25 Jun 2026). Manual (C1) starts with an empty canvas and requires drawing every turn. Engine + uncertainty highlighting (C2) initializes with diarization output and highlights intrusions in red and borderline segments in amber. Engine + gallery + recommendation (C3) includes everything in C2 and adds a cluster gallery for batch confirm or relabel and an R-key recommendation panel that averages overlapping embeddings, compares them to existing centroids, generates ranked speaker suggestions, and allows reassignment by click.

6. Cost instrumentation, evaluation, implementation, and limitations

The diarization tool treats annotation cost as a first-class output (Yamaguchi, 25 Jun 2026). It tracks editOps, defined as the total number of edit operations where each user gesture is one operation; active_edit_time, defined as wall-clock seconds spent in editing mode with pauses and idle periods excluded; and audio_listen_fraction, defined as total audio seconds listened at normal speed divided by audio length. The tool emits raw $f_{upd}$04 and $f_{upd}$05 rather than a hard-wired combined cost formula, while noting that downstream analyses may compute, for example, $f_{upd}$06 if desired. A representative JSON sidecar includes editOps, active_edit_time, audio_listen_fraction, per_segment, and phantom_checks.

The preliminary AMI study used nine AMI recordings from three meetings, one gallery reference per meeting, and a Latin-square across conditions C1, C2, and C3 so that each meeting appeared once under each condition; there was a single annotator. Diarization accuracy was measured with pyannote.metrics using a 0.25s collar and skip overlap. The primary cost metric was editOps; the secondary metric was active editing seconds per audio minute.

Condition	editOps	sec/aud-min
C1 manual	761	115
C2 +uncertainty	278	101
C3 +gallery+rec.	418	105

Under the same protocol, reported diarization error metrics were DER_mac and DER_mic, with values of 0.177 and 0.176 for C1, 0.079 and 0.078 for C2, and 0.093 and 0.094 for C3; the corresponding miss and conf. values were 0.123 and 0.030 for C1, 0.037 and 0.008 for C2, and 0.062 and 0.009 for C3 (Yamaguchi, 25 Jun 2026). The breakdown of edit operations showed that C1 was dominated by create operations, approximately 81% of 761, whereas C2 and C3 had almost no create operations and shifted effort to resize, split, delete, and reassign. The authors’ stated observations are that manual annotation is both costliest and least accurate, engine initialization shifts cost from creation to correction, and more sophisticated assistance is not strictly cheaper than highlighting alone because C3 saw extra resize operations.

Implementation details identify the repository as https://github.com/panchorange/voxmap, the license as MIT, frontend dependencies as Node \>14, React, and Webpack, and backend dependencies as Python 3.8+, PyTorch with CUDA or MPS, pyannote-pipeline, and pyannote-metrics (Yamaguchi, 25 Jun 2026). Optional GPU acceleration is recommended for sub-real-time initialization, though CPU fallback is supported. The discussion section frames cost instrumentation as a design compass for A/B testing new UI aids, model improvements, or cross-session assets. Reported limitations are a single-annotator pilot, a current gallery that is single-file only, and slow CPU-only fallback, with future work directed toward portable fast inference on CPUs, AMD, and NPUs, richer cross-session speaker assets, and extensions beyond pure diarization such as speaker-attributed ASR.

Both systems therefore exemplify a shared naming pattern but diverge in technical substance: one centers on hash-table voxel maps, $f_{upd}$07-average updates, dynamic spatial and temporal filtering, and decentralized map sharing for navigation (La et al., 2024); the other centers on pyannote-integrated annotation, edit/time instrumentation, and confirmation-gated export for diarization workflows (Yamaguchi, 25 Jun 2026).