Local browser workflow

Correct a Tap Card and Audit Its Time Basis

Transcribe one completed tap card and check its method basis.

A tap orbit changing pace around a constant source pulse lantern.

YouTube tap playback speed BPM corrector

Enter a value. The result updates while you type.

values stay in ephemeral browser memory; no URL, player read, API, media access, microphone, upload, account, database, analytics-value event, or persistent history No sign-in or ads.

Result

Start entering values to see the result.

Correct the evidence on a completed tap card

This YouTube tap playback speed BPM corrector is not a two-number converter. It begins with a completed card from the local tap surface and keeps four pieces of provenance beside the speed correction: the selected summary recipe, its BPM, the total interval count, and the wall-time coverage. That evidence lets the page check whether a copied value behaves like the recipe named on the card.

Transcribe the card rather than reconstructing it from memory. Choose Overall elapsed, Median interval, Trimmed mean interval, or Recent window exactly as shown. Then enter the tap-card interval count, total wall-time coverage in seconds, and the stable external playback speed. The tool does not capture taps, inspect another tab, or infer a missing field.

Two rate paths expose the method basis

The selected-summary path corrects the chosen rate. If observed BPM is O and external speed is S, selected source BPM is O ÷ S. The reciprocal intervals are 60,000 ÷ O milliseconds in observed wall time and 60,000 ÷ selected source BPM milliseconds in source time.

The evidence path starts from count and coverage. If N intervals span W wall seconds, coverage-implied observed BPM is N × 60 ÷ W. The same wall window covers W × S seconds of source material, so coverage-implied source BPM is N × 60 ÷ (W × S). These formulas reach the same result as division by speed when the selected recipe is Overall elapsed and the card was transcribed consistently.

The panel shows the absolute difference between selected observed BPM and coverage-implied observed BPM, plus that difference as a percentage of the coverage-implied rate. It never hides the two inputs behind a single corrected badge.

Worked overall-card example

Suppose a card reports Overall elapsed, 90 observed BPM, 12 intervals, 8.000 seconds of wall-time coverage, and 0.75× playback. The selected source result is 90 ÷ 0.75 = 120 BPM. The observed interval is about 666.67 ms, and the source interval is 500 ms.

The evidence path gives 12 × 60 ÷ 8 = 90 observed BPM. Source-time coverage is 8 × 0.75 = 6 seconds, and 12 × 60 ÷ 6 = 120 source BPM. The method delta is zero, so the deterministic audit reads Aligned. This is an arithmetic consistency result, not proof that the observer chose the intended musical pulse.

For an Overall elapsed card, the page displays Aligned only when the absolute difference is at most 0.01 BPM. A larger difference displays Review transcription while preserving every entered value. Likely causes include copying tap count instead of interval count, converting milliseconds incorrectly, rounding too early, or pairing one card’s BPM with another card’s coverage.

A recipe difference can be legitimate

Median, trimmed, and recent summaries do not use the entire coverage in the same way as Overall elapsed. Their selected rate may therefore differ from the evidence path without being wrong. The tool labels that situation Different recipe—delta is descriptive, not an error.

Consider a card with Median interval at 121.21 BPM, 12 total intervals over 6.060 wall seconds, and 0.8× playback. Count and coverage imply about 118.81 observed BPM. The observed method delta is about 2.40 BPM, or 2.02 percent. The selected median-based source result is about 151.51 BPM, while the whole-coverage source result is about 148.51 BPM. Both are displayed with their recipes. The difference says the median interval was shorter than the session-wide average; it does not select a winner.

That distinction is why the recipe field is required. A generic correction that accepts only BPM and speed cannot tell whether a discrepancy is a transcription error or an expected difference between summaries.

Why source-time coverage is multiplied by speed

At 0.75×, eight wall seconds advance through six source seconds. At 1.25×, eight wall seconds advance through ten source seconds. Multiplying wall coverage by speed expresses how much source timeline the observation crossed. Dividing an interval count by that source duration gives the source-time rate directly.

This direction check can catch an inverted factor. Slower playback creates fewer experienced events per wall minute, so correcting back to source time raises BPM. Faster playback creates more, so correction lowers BPM. At 1×, wall and source coverage are identical.

Use only a coherent card

External speed must remain stable through the recorded coverage. If playback pauses, buffers, seeks, or changes speed during the run, one factor cannot describe the session. Start a new tap card beside a stable passage. Do not enter a value that has already been corrected to source time; dividing it again applies the factor twice.

The interval count must be the number of gaps, not the number of taps. Thirteen taps normally create twelve adjacent intervals. Coverage must be the elapsed time from the first included tap to the last included tap. A trimmed or recent summary still uses the card’s declared full coverage for the evidence comparison; the recipe label explains why its selected rate may differ.

What this audit cannot establish

Alignment cannot verify player speed, media identity, section stability, event latency, pulse level, meter, or tap quality. A perfectly transcribed card can consistently describe half-time or double-time tapping. Use the separate pulse-level checker for that listening question and keep warnings from the original card.

No URL, player, audio, video, microphone, API, upload, account, database, analytics-value event, or catalog enters this calculation. The five inputs and derived panel live only in current-page memory until Reset, reload, or closure. Copying creates a local clipboard record under browser and device controls.

Frequently asked questions

Why does the tool need count and coverage?

They create an independent whole-session rate that can expose a copied-field or recipe mismatch.

Is a nonzero delta an error?

Only an Overall elapsed difference above 0.01 BPM triggers a transcription warning. Other recipes are expected to differ sometimes.

Why not show half and double candidates here?

Those candidates answer a pulse-level question. This tool audits time basis and method provenance, so the separate checker owns that workflow.

Can the page read playback speed?

No. Read the stable setting in external playback and enter it manually.

## Copy the correction with its basis

Audit one completed card, inspect both calculation paths, and copy the recipe, count, wall coverage, speed, selected correction, coverage-implied correction, and method delta together.

Continue on this site