Metric v6.9 (iOS) and v1.2 (Android): Video processing and accuracy improvements
Metric has had an upgrade with faster video processing and improvements to tracking accuracy in how it measures barbell velocity, with significant improvements in peak velocity. Here is how we did it.
We shipped v6.9 on iOS and v1.2 on Android this week, with two big improvements: how fast Metric processes video frames, and how accurately it measures barbell velocity.
This post covers both with the before and after numbers. We ran a regression and benchmarking suite against these changes, comparing old Metric and new Metric against a GymAware device, so the numbers below are actual measured changes, not estimates.
Faster video processing
Frame processing time is what you feel when you finish a set and Metric has to perform additional processing to ensure accuracy, or the time it takes to import a video from your gallery and wait for results. Before this update, a standard 1080p 60fps 17-second deadlift set would take around 41 seconds to complete analysis on iOS. That is 2.4× the clip length.
Before and after
| Video | Length | iOS before | iOS after | iOS gain | Android before | Android after | Android gain |
|---|---|---|---|---|---|---|---|
| Deadlift set, 1080p60 | 17 s | 41.2 s | 25.5 s | −38% | 55.1 s | 46.0 s | −17% |
| Deadlift set 2, 1080p60 | 20 s | 44.6 s | 28.6 s | −36% | 59.6 s | 52.6 s | −12% |
| Long set, 13 reps, 1080p60 | 43 s | 50.3 s | 34.2 s | −32% | 102.5 s | 87.8 s | −14% |
| 4K low-light set | 20 s | ~unchanged | ~unchanged | — | 36.2 s | 35.4 s | −2% |
In throughput terms, iOS now processes imported videos at 39.5 frames per second on the base deadlift set, up from 23 fps — roughly 1.7× faster. Android moved from 18.3 to 21.9 frames per second, about 1.2× faster.
Note on iOS figures: these were measured on the iOS Simulator on an M-series Mac. The relative improvement (−32–38%) reflects what the code change delivers; absolute seconds on your iPhone will differ by video length, the scene in your video, and by device generation. Android figures are from a real-device Samsung Galaxy S23 Ultra.
On Android, the changes also freed approximately 190MB of GPU memory — previously held by dead allocations that were never being used. That headroom will be most noticeable on mid-range and older devices.
What we actually changed
Profiling every stage of the pipeline on both platforms showed that processing cost was not actually being bottlenecked by video resolution. Instead, the biggest factor was scene complexity; a busy gym frame with lots of background activity produces thousands of objects to track and validate, and the code that confirms plate detections and repetitions was simply taking too long to filter out the objects that were not the target weight plate.
Three fixes to our computer vision pipeline delivered the performance improvements:
1. Made brute-force scans more elegant. One of the biggest issues with old Metric was weight plates with internal circular patterns, giving Metric faux-plate shapes that could confuse tracking. Metric is now much smarter at detecting and quickly filtering this pattern, making plate lock-in 64% faster.
2. Stopped repeating work. The plate detection step does a lot of comparison work, recomputing plate position thousands of times per frame. We found a way to cache each comparison result and compute it once, giving us the same detection result with a fraction of the work. This freed up considerable compute time on the most intensive pipeline stage, by roughly 40%.
3. Deleted legacy work. On Android, some old diagnostic code was still running on every video frame, performing a full-pixel scan just to produce a diagnostic log line. This was especially heavy on imported videos and wasted up to 16ms per video frame, stalling the video processing pipeline for no actual benefit.
The GPU experiment we built and killed
Full of confidence from these improvements, we built and tested a GPU-accelerated plate detection extractor, moving work off the CPU and onto the GPU. It worked, and in simulation it halved CPU load — but on real hardware it made imports 35% slower. For this stage of the pipeline, processing speed is bottlenecked by the GPU, not the CPU, so we were actually putting more strain on the already hard-working GPU.
We reverted this work and called it a day on processing speed wins.
Metric accuracy improvements
Metric is already a very accurate system, with internal and external validations showing performance that matches commercially available linear positional transducers. However, we are always looking to get better, and user feedback was that we needed to improve reliability across more recording angles, environments, and device positions.
Before and after results
The numbers below cover the full 234 Metric recordings in our June 2026 internal validation session (bench, deadlift, squat, cleans, jumps; multiple phone setups per set), compared against a GymAware tether unit as ground truth.
You can read the full Metric vs GymAware validation here → Metric vs GymAware validation.
| Metric | Before | After | Change |
|---|---|---|---|
| Mean velocity CCC | 0.970 | 0.977 | +0.007 |
| Mean velocity MAE | 0.067 m/s | 0.061 m/s | −9% |
| Peak velocity CCC | 0.910 | 0.957 | +0.047 |
| Peak velocity MAE | 0.202 m/s | 0.142 m/s | −30% |
| Peak velocity bias | −0.19 m/s | −0.09 m/s | −53% |
A quick guide to the three measures above:
- CCC (Concordance Correlation Coefficient) — agreement with GymAware across all repetitions on a 0–1 scale; higher is better, with 1.0 being a perfect correlation.
- MAE (Mean Absolute Error) — average size of the difference per rep, in m/s; lower is better, with 0 being an identical result.
- Bias — average direction of the miss (negative = Metric gives velocity that is lower than GymAware); closer to zero is better for validity, while consistently being in the same direction (slightly positive or negative) is a good sign for reliability.
At best-practice recommended recording positioning (directly side-on, 1080p 60fps), peak velocity improvements were even better:
- CCC 0.984 → 0.993
- Bias −0.078 → −0.010 m/s — statistically indistinguishable from the tether unit.
Per-condition improvement: peak velocity
| Condition | n reps | MAE before | MAE after | Change |
|---|---|---|---|---|
| Best practice (side-on, 1080p 60fps) | 63 | 0.080 m/s | 0.052 m/s | −35% |
| 45° camera angle | 48 | 0.189 m/s | 0.156 m/s | −17% |
| Low angle (phone on floor) | 13 | 0.317 m/s | 0.105 m/s | −67% |
| 30fps recordings | 45 | 0.353 m/s | 0.292 m/s | −17% |
| 720p / 4K resolution imports | 39 | 0.350 m/s | 0.242 m/s | −31% |
| Dim / backlit / glare | 30 | 0.147 m/s | 0.111 m/s | −24% |
| Distance extremes + clutter | 22 | 0.045 m/s | 0.043 m/s | −4% |
| Jumps | 30 | 0.149 m/s | 0.124 m/s | −17% |
Per-condition improvement: mean velocity
Mean velocity was already incredibly well correlated to GymAware across most conditions in our “before” tests. The biggest gain was in imported low-angle recorded videos, which had a specific geometric cause for inaccuracy that has now been corrected.
| Condition | n reps | MAE before | MAE after | Change |
|---|---|---|---|---|
| Best practice (side-on, 1080p 60fps) | 63 | 0.045 m/s | 0.041 m/s | −9% |
| 45° camera angle | 48 | 0.042 m/s | 0.045 m/s | +4% |
| Low angle (phone on floor) | 13 | 0.106 m/s | 0.043 m/s | −59% |
| 30fps recordings | 45 | 0.092 m/s | 0.088 m/s | −4% |
| 720p / 4K resolution | 39 | 0.108 m/s | 0.090 m/s | −17% |
| Dim / backlit / glare | 30 | 0.043 m/s | 0.045 m/s | +4% |
| Distance extremes + clutter | 22 | 0.034 m/s | 0.033 m/s | −3% |
What we actually changed
1. Peak velocity recovery. The algorithm that makes bar path stable was cutting the top off velocity peaks — roughly 4% on slow lifts, and up to 25% on explosive movements at 30fps. Peaks are now handled more gently and tuned based on the video’s frame rate for greater sensitivity.
2. 30fps undersampling. Imported 30fps footage (and Android live recordings on 30fps-capped devices) has larger frame gaps, which were being processed in a way that flattened genuine peaks further. This compounds with fix number one to make peaks better again on 30fps. These numbers still aren’t as accurate as 60fps (see the table above), but the gap has been significantly tightened.
3. Camera-tilt correction for imported video. We recommend recording your sets live in the Metric app, because the tracking system uses additional device sensor data, along with focal length and exposure controls, to optimise video capture for object tracking. Imported video has no sensor data, so low-angle imports were under-reading mean velocity by 10–12%. We found a way to correct this under-reading and tune the recording to match. Peak velocity error on low-angle imports dropped from 0.317 m/s MAE to 0.105 m/s, and mean velocity dropped from 0.106 to 0.043 m/s.
4. Pre-set noise fix. Metric would occasionally capture movement artifacts before a set started, leading to a slow, dramatic bar path lead-in that would meet the barbell on the first repetition before behaving normally for the rest of the set. This was rare but seemed most pronounced in lower-light settings and on lifts with a longer setup time before starting, and would lead to extended concentric durations and a slower mean velocity on the first rep. We tuned our pre-set filtering to squash these artifacts and more reliably start the first rep when the bar genuinely starts moving.
What is still a known limitation
30fps explosive peaks. At 0.292 m/s MAE, 30fps remains the weakest condition for peak velocity tracking. The frame rate simply cannot capture the true peak on a fast movement. If peak velocity is important to your training data, use 60fps.
Jump mean velocity. Mean velocity on jump training reads approximately 10% below GymAware across all conditions, and this did not change in v6.9. Our hypothesis is that this is not a tracking accuracy issue but a difference in how GymAware defines the start and end of the concentric phase on jumps. This 10% difference was consistent across reps and conditions. It may simply be a difference in the tether being placed on the inside of the barbell versus Metric using the camera to track weight plates.
Live-recording validation. All accuracy figures above are for videos recorded on the device’s default camera app and processed in the import pipeline. Live recording shares the peak velocity recovery and rep ordering fixes, but the camera-tilt correction is import-only. A live-recording validation session against GymAware is planned.
What is next
We are always looking to keep improving and make Metric the best barbell tracking tool on the market. That means we would love to hear your feedback and bug reports — you can send these to us directly in the Metric app on Android and iOS: just tap the menu and select Send bug report. We read and review every report.
Currently (June 2026) we are in the final stages of testing for our new tracking app, Metric Jump, with the beta starting soon. Keep an eye out for news and public release dates.
If you are running a training study and want to measure alongside the next round of improvements, see the research page.