04 — Database

Technicaldocumentation.

What was recorded, how records are organized and how each representation should be interpreted — written for researchers building loaders and baselines.

04.1

Dataset overview

Ampe-DB captures two-person interactions from Ampe, a Ghanaian game involving coordinated jumping, clapping and a leg-position reveal. The benchmark treats each segmented clip as a paired movement configuration rather than a solo action.

The dataset is deliberately compact rather than large-scale. Its contribution is the combination of culturally grounded interaction, explicit participant/pair metadata, aligned RGB and pose representations, and leakage-aware generalization protocols.

637
Canonical records
15
Pseudonymous participants
11
Unordered pairs
14
Ordered pair configurations
557
Unique RGB/audio hashes

Exact-duplicate provenance

637 canonical records
557 unique complete-file hashes80 redundant records

78 exact-duplicate groups involve 158 records, so 80 are redundant beyond one representative per group. They are retained for provenance; official splits keep each group within a single partition.

Movement labels

Each record carries one of four movement classes — left_left, left_right, right_left or right_right — and a binary relation label derived from it. Label spaces →

Outcome caution
Baseline V1 does not use an independently annotated winner label as a separate benchmark target. Gameplay outcome can be derived only when the applicable Ampe rule or player role is defined.
04.2

Database structure

The publication package is organized around eight core folders. The root also holds the release README, citation file, research data use agreement and license.

Ampe-DB_V1/Records├── videos/RGB MP4 with embedded audio637├── pose/Normalized pose CSV637├── skeleton/│ ├── csv/Pixel-space skeleton CSV637│ ├── json/Skeleton JSON mirror637│ └── videos/Rendered skeleton MP4637├── annotations/Canonical clip-level labels├── metadata/Manifest, schema, mappings, statistics├── splits/Locked evaluation partitions├── docs/Release documentation├── paper/Paper materials├── README.mdRelease orientation├── CITATION.cffCitation metadata├── AMPE_DB_RESEARCH_DATA_USE_AGREEMENT.pdfResearch data use agreement└── License.pdfLicense

Canonical 1:1 record representations

Each canonical clip identifier maps to five record-level representations. Across 637 records this produces 3,185 record-level files, before documentation, metadata, split, paper and access files are counted.

Core metadata files

  • metadata/ampe_db_v1_manifest.csv
  • metadata/ampe_db_v1_schema.csv
  • metadata/ampe_db_v1_data_dictionary.csv
  • metadata/participants.csv
  • metadata/participant_pairs.csv
  • metadata/clip_participant_mapping.csv
  • metadata/dataset_statistics.csv
  • metadata/movement_distribution_summary.csv
04.3

Data formats

ComponentFormatMeaning
RGB videoMP4 + embedded audioOriginal segmented gameplay
Normalized poseCSVBody-normalized landmarks and visibility
Skeleton exportsCSV and JSONPixel-coordinate landmark geometry
Skeleton visualizationMP4Derivative inspection videos
Annotations & metadataCSVLabels, pairs, provenance and statistics
Release documentationText / PDF / DOCXAs distributed with the release

RGB video and audio

Canonical media are MP4 clips with synchronized embedded audio. Frame rate and codec vary across canonical media and are documented in metadata.

Important
Do not describe V1 as a uniform 60 FPS dataset. Read frame rate and codec from the release metadata for every clip.

Normalized pose CSV

The canonical pose representation is long-form, with up to 33 MediaPipe landmarks per player per frame:

frame, player_id, landmark_index, x_norm, y_norm, visibility
  • x_norm and y_norm are body-normalized coordinates, not simple [0, 1] image coordinates.
  • Normalization uses the hip midpoint as origin and a shoulder-to-hip torso scale.
  • No rotation or reflection normalization is applied.
  • Missing detections and incomplete player-frame groups are handled explicitly during model preparation using presence indicators.

Skeleton exports

Skeleton CSV and JSON files preserve pixel-space landmark geometry for visualization and reconstruction. Skeleton MP4 files are derivative visualizations for inspection, debugging, demonstration and publication figures — not a separate ground-truth modality.

04.4

File naming rules

The movement token and C### identifier form the canonical record key used across all representations.

RepresentationExample
RGB videovideos/left_right_C003.mp4
Normalized posepose/left_right_C003.csv
Skeleton CSVskeleton/csv/keypoints_left_right_C003.csv
Skeleton JSONskeleton/json/keypoints_left_right_C003.json
Skeleton videoskeleton/videos/skeleton_left_right_C003.mp4
Record key → file paths

Build the paths for any record

Paths follow the naming rule. Confirm the record exists in the manifest before loading.

Canonical record keyleft_right_C003
RGB video
videos/left_right_C003.mp4
Normalized pose
pose/left_right_C003.csv
Skeleton CSV
skeleton/csv/keypoints_left_right_C003.csv
Skeleton JSON
skeleton/json/keypoints_left_right_C003.json
Skeleton video
skeleton/videos/skeleton_left_right_C003.mp4

Movement tokens

left_leftleft_rightright_leftright_right
Interpretation
Files sharing the same movement token and C### identifier correspond to the same canonical record. Obtain participant identity from the mapping files — never from filename token order alone.
04.5

Pose & skeleton format

Ampe-DB V1 uses the standard 33-landmark MediaPipe pose representation for each represented player.

The release preserves the full landmark index rather than the 21-keypoint subset described in an earlier draft.

Pose CSV schema

ColumnMeaning
frameFrame index within the clip
player_idPlayer for the row — resolve participant identity through the mapping files
landmark_indexMediaPipe landmark index, 0–32
x_normBody-normalized horizontal coordinate
y_normBody-normalized vertical coordinate
visibilityLandmark visibility

A complete frame with two detected players can contain up to 66 landmark rows; missing detections mean some frame-player groups may be incomplete.

Normalization

OriginHip midpoint
ScaleShoulder-to-hip Euclidean distance
Not appliedRotation or reflection

Baseline V1 model-ready sequence

2
Players
33
Landmarks
3
x, y, visibility
2
Presence flags
200
Features per step

Pose clips are temporally sampled to 32 steps, giving a 32 × 200 input sequence per clip.

Landmark index

The standard MediaPipe pose landmarks, as stored in landmark_index. Marked: the shoulder and hip landmarks that define the torso used for normalization.

  • 0nose
  • 1left_eye_inner
  • 2left_eye
  • 3left_eye_outer
  • 4right_eye_inner
  • 5right_eye
  • 6right_eye_outer
  • 7left_ear
  • 8right_ear
  • 9mouth_left
  • 10mouth_right
  • 11left_shoulder
  • 12right_shoulder
  • 13left_elbow
  • 14right_elbow
  • 15left_wrist
  • 16right_wrist
  • 17left_pinky
  • 18right_pinky
  • 19left_index
  • 20right_index
  • 21left_thumb
  • 22right_thumb
  • 23left_hip
  • 24right_hip
  • 25left_knee
  • 26right_knee
  • 27left_ankle
  • 28right_ankle
  • 29left_heel
  • 30right_heel
  • 31left_foot_index
  • 32right_foot_index

Skeleton outputs

Skeleton CSV and JSON expose the pixel-coordinate geometry used for rendered skeleton visualization. Skeleton videos are convenient inspection layers, not substitutes for the original RGB clip or the canonical pose CSV.

04.6

Annotation & metadata

annotations/ampe_db_v1_labels.csv stores the V1 clip-level supervised labels: a four-class movement label and a binary movement relation derived from it.

Second token · left
Second token · right
First token · left
left_leftsame_leg_configuration
left_rightdifferent_leg_configuration
First token · right
right_leftdifferent_leg_configuration
right_rightsame_leg_configuration

Four classes (cells) and the binary relation they map to: the diagonal is the same leg configuration, the off-diagonal a different one.

Participant and pair mappings

clip_participant_mapping.csv links each canonical clip to pseudonymous player IDs, ordered and unordered pair identifiers, and movement fields. Participant identity is distributed separately from the movement label.

Manifest and duplicate provenance

The 637-row canonical manifest records media properties and complete-file RGB/audio SHA-256 values used to identify exact-duplicate groups.

Important
Do not silently delete duplicates and then report results as the frozen V1 benchmark. Use the provided protocol, or document any alternative preprocessing clearly.
04.7

Participants & pairs

15
Pseudonymous participants
11
Unordered participant pairs
14
Ordered pair configurations

Files to use

FileContents
metadata/participants.csvPseudonymous participant-level release information
metadata/participant_pairs.csvPair structure used in the corpus
metadata/clip_participant_mapping.csvCanonical clip-to-participant and clip-to-pair mapping

Why pair information matters

Pair identity is essential to the V1 evaluation design. The primary generalization benchmark holds out participant pairs as pairs, while individual participants may still appear with different partners in training for a given fold.

Privacy
Only anonymized information that is part of the approved release is presented. Real names, direct identifiers, consent records and anything that could enable re-identification are never displayed.
04.8

Recording conditions

Capture design

  • Single fixed frontal camera viewpoint.
  • Two players visible together within the frame.
  • Source recordings captured natural Ampe play and were later segmented into canonical interactions.
  • Embedded audio retains clap, step and vocal cues from the source recording.

Camera equipment

Recording documentation identifies Blackmagic and Sony A7 III cameras in the source capture workflow. Rely on per-file media metadata rather than assuming one uniform camera profile for every canonical clip.

Media properties

Frame rate
30 FPS · most clips24 FPS60 FPS
Video codec
H.264HEVC

V1 media properties are not completely uniform. Read the release metadata instead of hard-coding 60 FPS or a single codec.

Why the frontal view matters

The fixed frontal view keeps both players visible, supports consistent 2D pose extraction, and preserves the relative timing and leg-position structure of Ampe without a multi-view motion-capture rig.

04.9

Release manifest & file index

metadata/ampe_db_v1_manifest.csv is the central 637-row record inventory. Use it to join canonical clip identifiers, media properties, duplicate provenance and release-level record information.

Record-level coverage

RepresentationExpected V1 records
RGB video637
Normalized pose CSV637
Skeleton CSV637
Skeleton JSON637
Skeleton video637
Record-level files3,185

Supporting index files

  • ampe_db_v1_schema.csv
  • ampe_db_v1_data_dictionary.csv
  • participants.csv
  • participant_pairs.csv
  • clip_participant_mapping.csv
  • dataset_statistics.csv
  • movement_distribution_summary.csv
Integrity note
The manifest includes the RGB/audio SHA-256 used for exact-duplicate provenance. Use separate archive or package checksum files, when supplied with a download, for transfer-integrity verification. Verify download →