Every result should say what was measured—and what was not.

Result vocabulary

Pass means the observed value met the stated practical range. Needs attention means a measurement or user observation crossed a disclosed threshold. Failed means the browser could not complete a required operation. Not tested and Unavailable remain unknown; they are never silently converted to passes.

Calculations and display conventions

For N normalized time-domain samples, RMS = √(Σx² / N). MeterSee converts RMS to dBFS using 20 × log₁₀(RMS). An RMS value of 0.1 gives −20 dBFS. A full-scale sine wave has approximately −3.01 dBFS RMS; sample peak and RMS are different quantities.

Mathematical silence has no finite logarithmic level. The interface clamps its display to −96 dBFS; that is a display floor, not a claim that digital silence equals a particular bit-depth noise level.

The standalone microphone tool estimates a background floor from a low percentile of valid collected levels. Speech, automatic gain, noise suppression, and the duration of pauses influence that estimate. It cannot isolate room reflections or provide calibrated sound pressure. The pre-meeting tool instead separates quiet and speech intervals as described below.

Microphone method

The pre-call test separates an initial quiet interval from a speech interval. RMS amplitude is converted to dBFS. The quiet interval median estimates background level, while the speech interval supplies peak level. MeterSee warns for no usable speech signal at or below −75 dBFS, speech peak below −35 dBFS, clipping above −1 dBFS or clipped buffers, and estimated background above −38 dBFS. These are practical call-screening thresholds, not calibrated sound-pressure measurements.

Camera method

Resolution and capture settings come from the active MediaStreamTrack. Where supported, frame rate is measured from video-frame presentation callbacks over a short visible sample; otherwise the browser-reported track value is labeled as reported. A stream below 640×360 or below 15 frames per second receives a warning. Focus, lighting, framing, color, and lens quality require visual confirmation.

Connection and video-call screening

The Call Quality tool sends twelve small cache-bypassed HTTPS requests to a same-origin MeterSee asset. It reports nearest-rank p50 (the lower of the two middle ordered samples when the count is even), nearest-rank p90, nearest-rank p50 of absolute changes between consecutive successful requests, and failed-request count. “Ready” requires no failed request, p50 below 250 ms, and timing variation below 50 ms. A p50 of 500 ms, timing variation of 100 ms, or failure rate of 20% produces the strongest warning. These are MeterSee screening bands, not a claim about a meeting provider's thresholds.

The requests use HTTPS to MeterSee's delivery edge. They do not reproduce a Zoom, Teams, or Meet media path and cannot directly measure UDP packet loss, RTP jitter, upload bandwidth, Wi-Fi signal strength, router load, or another participant. When exposed, the Network Information API downlink value is shown as a rounded browser hint only; it is not a speed test and never changes the grade. The Pre-Meeting Check uses eight of the same probes as one evidence group. For endpoint-specific diagnosis, use the meeting application's in-call statistics.

Monitor timing and visual fields

Refresh timing uses visible-tab animation callback intervals. The displayed estimate is derived from the median frame interval; jitter is the median absolute deviation, and long frames exceed 1.5 times the median. Variable refresh, compositing, power saving, background tabs, and system load can affect the result. Pixel defects, banding, black level, ghosting, sharpness, and uniformity are user observations against generated patterns, not automatic panel measurements.

Headphones, speakers, and gamepads

Audio tests generate defined local signals at a conservative generator level. The site cannot know physical sound pressure or hear a transducer, so routing, phase, bass, sweep, and channel conclusions require the listener. Gamepad buttons and axes are raw browser API values. Neutral-stick calibration uses a disclosed practical warning threshold of ±0.12; games may apply different dead zones and response curves.

Computer slowdown check

The quick screen samples visible-tab timer delay, long tasks where the browser exposes them, a fixed-duration Web Worker calculation, WebGL 2 availability, and three small same-site requests. Timer delay warnings begin at a 95th-percentile delay of 100 ms and become strong at 250 ms. Same-site request times are labeled as the path to MeterSee, not broadband speed. The W3C Long Tasks specification defines a long task as work exceeding 50 ms. MeterSee uses disclosed 100 / 250 ms timer-delay screening bands and never turns an unavailable Long Tasks API into a pass.

The optional deep mode starts only after three explicit acknowledgements, including a physical-safety confirmation. It can briefly use up to four Web Workers, one 32 MiB JavaScript memory buffer, 16 MiB of temporary IndexedDB origin storage, and a seven-second WebGL 2 workload. The user can stop it; switching tabs makes the run incomplete. The test database is uniquely named, closed, and deleted after the storage phase. Browser calculation, memory-buffer, storage, and graphics rates are recorded only as repeat-comparison baselines for the same computer. They are not graded across different browsers or hardware classes.

System CPU, memory, disk-active-time, free-space, startup-item, and symptom data are user-reported from the operating system. Screening attention thresholds are 60% / 90% for a stable CPU sample, 80% / 90% for memory, 60% / 90% for disk active time, and 20% / 10% free system-drive space. macOS Memory Pressure uses the operating system's green, yellow, and red state described by Apple Activity Monitor. Windows readings follow Microsoft's description of Task Manager as the CPU, memory, disk, and startup monitor; High-impact startup labels come from Windows rather than a MeterSee estimate. Chromebook memory results are accepted only when copied from Google's built-in ChromeOS Diagnostics app. These rules support triage; they do not identify a process, certify unrelated hardware, or scan malware.

Approximate device memory and available logical processors are context only. Browser documentation notes that device memory is rounded and not widely exposed, while the browser may report fewer logical processors than the physical system. Those values never create a failure result on their own.

Reports and privacy

Diagnostic PDFs are generated locally and distinguish measured values from manual confirmations. Device labels can be hidden. Media, control events, and report contents are not submitted to MeterSee; normal hosting, advertising, and analytics requests are described separately in the Privacy Policy.

Public verification record

Traceable release-scoped checks; PASS never extends beyond the named inputs and boundary.

Historical test snapshot (not current release status) · 2026-09-15 · 258 HTML routes · 6 languages × 43 pages.

Recorded browser environment: Chromium 151.0.7922.34 · macOS 26.5.1 arm64.

UNVERIFIED remains explicit for real hardware, external accounts, search-engine decisions, field performance, and current deployment status.

Open the sanitized machine-readable record.