MOUSE SENSITIVITY CONVERTER / AUDIT GUIDE
Check a sensitivity conversion with a round trip
Convert A to B, then convert the full result back from B to A, swapping both presets and both DPI values. Compare the returned value with the original. This checks consistency of the calculation; even a perfect return cannot prove the model matches a real game.
Published October 19, 2026 · AimConvert · an independent developer
Open the converter and use Swap ↗Record the labels before testing
Write down source and target presets, both DPI values, the input mode and aim mode. Start from an in-game sensitivity value for this check. A round trip changes the direction of conversion, so the target setup becomes the new source setup. Swapping names while leaving the DPI fields in their old positions is not the inverse operation.
Use the full copied number rather than manually shortening it. If the target game's retained setting is what you are checking, record that separately. A mathematical round trip and a game read-back test examine different parts of the process.
An exact example with deliberately simple inputs
Construct two hypothetical presets: A has yaw 0.01 and B has yaw 0.025. Use A at 600 DPI and sensitivity 1.5, and B at 1200 DPI. These coefficients were chosen for this controlled calculation; they are not attributed to any real game. The simple values make every intermediate step terminating, so rounding cannot explain the injected errors below.
B sensitivity = 1.5 × 0.2 = 0.3
Reverse factor = (0.025 × 1200) ÷ (0.01 × 600) = 5
Returned A sensitivity = 0.3 × 5 = 1.5
The forward and reverse factors multiply to one. More generally, let k be source yaw times source DPI divided by target yaw times target DPI. The forward result is the original setting times k; the inverse multiplies by one divided by k. The unchanged labels cancel algebraically. This establishes a test of the selected input mapping, not an independent measurement of either yaw coefficient.
Inject a mistake and see what changes
Keep the same constructed example, but deliberately alter one part of the input mapping. In the second row, reverse the presets but leave the DPI fields at 600 then 1200. In the third, reverse the DPI values but leave the presets in forward order. In the fourth, use 960 as the target DPI during the forward step but 1200 as the source DPI during the return step.
| Controlled case | Forward | Returned | Difference |
|---|---|---|---|
| Correct inverse | 0.3 | 1.5 | +0.00% |
| Reverse DPI not swapped | 0.3 | 0.375 | -75.00% |
| Reverse games not swapped | 0.3 | 0.24 | -84.00% |
| Forward uses 960 target DPI | 0.375 | 1.875 | +25.00% |
For the unswapped-DPI case, the reverse factor is (0.025 × 600)/(0.01 × 1200) = 1.25. Therefore 0.3 returns as 0.375, rather than 1.5. Its difference is (0.375/1.5 − 1) × 100 = −75 percent. This percentage describes the returned setting, not a turn-distance error or a player's performance.
The mismatched forward DPI produces 0.375, then the correctly labelled return factor of five produces 1.875. The returned value is 25 percent higher than the original. These are demonstrations of known injected mistakes. If an actual converter gives the same output, that alone does not identify its cause: other input changes could produce the same discrepancy. Compare the labels and retained values before making a diagnosis.
A false pass: consistent wrong coefficients cancel
Now deliberately substitute B yaw 0.02 for the reference value 0.025 in both directions. The forward factor becomes 0.25, so A sensitivity 1.5 converts to B sensitivity 0.375. The reverse factor becomes four, returning exactly 1.5. The round trip appears perfect because the same mistaken coefficient cancels out.
Evaluate both settings using the constructed reference model instead. Source rotation per inch is 1.5 × 0.01 × 600 = 9. Target rotation per inch is 0.375 × 0.025 × 1200 = 11.25. Full-turn distances are 914.4/9 = 101.6 cm and 914.4/11.25 = 81.28 cm. Their distance difference is (81.28/101.6 − 1) × 100 = −20 percent, despite a zero round-trip sensitivity difference.
Run the check in AimConvert
- Select your actual supported presets, sensitivity and both DPI values.
- Record or copy the precise result. Note whether you are testing the calculator value or the setting the game retained.
- Use Swap, which makes the target preset and DPI the new source and puts the converted sensitivity into the input field.
- Compare the return with the original. If it differs, compare the recorded labels and precision. If it matches, separately verify the model's assumptions and any physical turn test.
The example above uses fictional presets to isolate mistakes; those presets are not options in the live tool. For rounding effects, use the precision guide. For cross-game scale differences, see why equal eDPI is insufficient.
Direct answers
Must a displayed round trip be identical character for character?
No. Display precision and retained settings can differ. Compare the values at the precision you actually supplied; there is no universal tolerance established by this example.
Does a pass certify a game's current coefficient?
No. A consistent wrong coefficient can pass, as the constructed false-pass case shows.
Is this a physical sensitivity test?
No. It is a reproducible calculation audit. A physical test needs independently recorded observations.
Reproduction method
All constructed cases were calculated with exact rational arithmetic using Python's Fraction type, initialized from decimal strings. The supplied numbers define the synthetic model, rather than claiming a particular current game coefficient. No physical tests or player outcomes are reported.