Help

Audio inputs, supported formats, and local drum separation

The source determines how much evidence Backbeat Forge can recover. Start with the cleanest file available, but do not postpone a useful draft just because the only source is a full mix.

Supported input paths

The Full mix and Drum stem commands accept WAV, MP3, FLAC, OGG, M4A, and AAC audio. Import MIDI accepts .mid and .midi percussion files. All three paths end in the same score workspace, but only audio paths run onset detection.

Full mix

Use Full mix for a mastered song, rehearsal bounce, or multitrack export that still contains other instruments. Backbeat Forge uses its bundled HTDemucs drum model locally, then analyzes the separated drum evidence. Separation can reduce bass, guitar, and vocal interference, but it cannot reconstruct information that mastering or source quality has already hidden.

Listen critically when the arrangement contains distorted guitars, strong bass attacks, claps layered with snare, brushed drums, or cymbals masked by broadband material. If a separated hit is uncertain, the score keeps confidence evidence visible so you can correct the draft rather than accepting an invented certainty.

Drum stem

Use Drum stem when the file already contains drums alone. This command skips separation and goes directly to onset and kit-piece analysis, making it faster and reducing separation artifacts. A drum stem can still contain room bleed, effects returns, click spill, or limiting, so it remains a source to review rather than a ground-truth label file.

MIDI performance

Use Import MIDI when note events already exist. Backbeat Forge maps General MIDI percussion into its kit and notation model, then lets you inspect the written rhythm in the same workbench. MIDI import does not prove that the original audio was transcribed correctly; it is a separate route for arranging or reviewing an existing drum performance.

Local processing and bundled resources

Audio decoding, separation, detection, score generation, and project saving run on the desktop. The release packages include the drum-separation model and ONNX Runtime required for the supported platform, so the normal transcription path does not upload the recording.

Compare source paths with the same evidence window

When two source files are available, do not judge them from different parts of the song. Mark one stable groove, one transition, and one cymbal-heavy passage. Run those same windows through Full mix and Drum stem, then compare onset timing, kit assignment, false positives, and missing quiet hits. The stem should usually reduce competition from bass and guitar, but a poorly processed stem can still be less informative than a clean full mix.

Source condition	Best first path	Evidence to inspect
Mastered song only	Full mix	Separation bleed, masked kick, layered snare
Isolated drums available	Drum stem	Room bleed, clipping, effects returns
Existing percussion events	Import MIDI	Channel mapping, note assignment, written grid
Damaged or unusual container	PCM WAV test copy	Decoder success before changing detection

Keep the original recording unchanged. A transcoded test copy can isolate a decoder problem, but it cannot restore transients removed by clipping, lossy encoding, or mastering. Record the exact source type and time range when reporting a problem so the same evidence window can be reproduced.

For a fair comparison, keep the written grid and detection sensitivity unchanged between source paths. If the stem clearly needs different settings, record that as a second test rather than replacing the baseline. The purpose is to learn whether the source, separation stage, or detector caused the difference.

Does Full mix send the song to a cloud separator?

No. The normal supported workflow runs the bundled separation model and onset analysis on the desktop. Network access may still be used by unrelated update or licensing flows, but it is not required to upload the recording for transcription.

Should I normalize or compress the source first?

Only when a copy is being used for a controlled comparison. Heavy normalization, limiting, or transient shaping can change the evidence and create a different detection problem. Preserve the original and change one preprocessing choice at a time.

Next, follow the transcription workflow. If analysis fails or produces an empty draft, use Troubleshooting. You can get the current installers from the download page.

Direct answer and acceptance boundary

For “Audio inputs, supported formats, and local drum separation”, the short answer is: The source determines how much evidence Backbeat Forge can recover. Start with the cleanest file available, but do not postpone a useful draft just because the only source is a full mix. Treat that statement as a result to verify, not as a promise that every input, device, project, or environment behaves identically. A complete result records the starting state, the exact action, the visible output, and the condition that proves the task is finished in Backbeat Forge.

Evidence-first operating procedure

Work from a small, repeatable case before changing a full project. Record the application version, operating system, input or device identity, relevant settings, and the expected result. Perform one deliberate action, preserve the first unexpected transition, and compare it with a known-good run whenever one is available. Changing several controls at once may hide which condition fixed or created the problem.

Checkpoint 1: Audio inputs, supported formats, and local drum separation

Treat “Audio inputs, supported formats, and local drum separation” as a separate acceptance gate for “Audio inputs, supported formats, and local drum separation”. Record its initial state before acting, then capture the first visible change and the final state. If the result differs from the page’s stated outcome, return to the last confirmed checkpoint instead of continuing with assumptions.

Checkpoint 2: The source determines how much evidence Backbeat Forge can recover. Start with the cleanes

Verify “The source determines how much evidence Backbeat Forge can recover. Start with the cleanest file available, but do not postpone a useful draft just be” with the smallest representative input. Keep unrelated settings unchanged, repeat the same action once, and note whether the result is stable after reopening or reconnecting. A screenshot alone is weaker than a record that includes the input, setting, action, output, and time.

Checkpoint 3: Supported input paths

For “Supported input paths”, distinguish a product decision from an operating-system, hardware, source-file, permission, or workflow boundary. Confirm which layer supplied the evidence before assigning a cause. This prevents a nearby symptom from being reported as a proven root cause.

Checkpoint 4: Full mix

Use “Full mix” to define a pass/fail statement that another operator can repeat. Include what should be present, what must be absent, and what recovery action is safe if the check fails. Keep the original project or capture unchanged until the repaired copy has passed the same check.

Checkpoint 5: Drum stem

When “Drum stem” is ambiguous, compare one known-good case with one failing case under matching conditions. Mark the first meaningful difference rather than listing every later symptom. That first boundary usually produces a clearer support request and a safer next experiment.

Checkpoint 6: MIDI performance

Close “MIDI performance” only after the saved, exported, or reopened result still matches the observed state. Temporary UI feedback is useful, but durable evidence is stronger. Record any limitation that remains so the next reader does not interpret an incomplete path as a successful one.

Checkpoint 7: Local processing and bundled resources

Treat “Local processing and bundled resources” as a separate acceptance gate for “Audio inputs, supported formats, and local drum separation”. Record its initial state before acting, then capture the first visible change and the final state. If the result differs from the page’s stated outcome, return to the last confirmed checkpoint instead of continuing with assumptions.

Checkpoint 8: Compare source paths with the same evidence window

Verify “Compare source paths with the same evidence window” with the smallest representative input. Keep unrelated settings unchanged, repeat the same action once, and note whether the result is stable after reopening or reconnecting. A screenshot alone is weaker than a record that includes the input, setting, action, output, and time.

Checkpoint 9: Does Full mix send the song to a cloud separator?

For “Does Full mix send the song to a cloud separator?”, distinguish a product decision from an operating-system, hardware, source-file, permission, or workflow boundary. Confirm which layer supplied the evidence before assigning a cause. This prevents a nearby symptom from being reported as a proven root cause.

Checkpoint 10: Should I normalize or compress the source first?

Use “Should I normalize or compress the source first?” to define a pass/fail statement that another operator can repeat. Include what should be present, what must be absent, and what recovery action is safe if the check fails. Keep the original project or capture unchanged until the repaired copy has passed the same check.

Acceptance matrix

Checkpoint	Evidence to retain	Pass condition
Audio inputs, supported formats, and local drum separation	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
The source determines how much evidence Backbeat Forge can recover. Start with the cleanest file available, but do not p	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Supported input paths	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Full mix	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Drum stem	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
MIDI performance	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome

Failure isolation, recovery, and handoff

If a check fails, stop at the first failed boundary. Preserve the source, project, session, or capture; duplicate it before destructive editing; and change one variable per experiment. Repeating a broad workflow after several simultaneous changes may produce a different result without explaining why.

Separate absence of evidence from evidence of absence. A blank view may mean the wrong input, scope, filter, permission, device, time range, or project state rather than “nothing happened.” Verify the acquisition or import path before interpreting a decoder, editor, report, or export.

Before handoff, reopen the durable artifact and inspect its beginning, the decision point, and its end. Record version, platform, relevant configuration, expected behavior, observed behavior, and the smallest reproduction. Remove or redact sensitive material and confirm the recipient is authorized to receive it.

Questions and answers

What is the fastest reliable way to start?

Use the smallest representative case, write down the expected result, and change one variable. Confirm the basic path before adding filters, effects, edits, automation, or a larger source. This creates a baseline that can be compared after every later decision.

What evidence should be saved?

Keep the input identity, application version, platform, relevant settings, exact action, first unexpected transition, and final output. If the workflow creates a project, session, report, or export, close and reopen it before treating it as durable evidence.

When should the procedure be repeated?

Repeat it after an application, operating-system, driver, firmware, model, source, or workflow change that can alter the result. Preserve the earlier accepted case so the comparison uses the same acceptance boundary rather than memory.

When is the task ready for handoff?

It is ready when another authorized person can identify the input, repeat the action, see the same result, understand any remaining limitation, and open the saved artifact without relying on undocumented local state.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: