Help

Troubleshooting audio, projects, playback, and drum-score export

Start with the named stage that failed: opening the source, separating drums, detecting hits, reviewing playback, reopening a project, or exporting. Preserve the original file and .bforge project while you investigate.

The source will not open

Confirm that the file is local and uses WAV, MP3, FLAC, OGG, M4A, or AAC. Try a short PCM WAV copy when a damaged container or unusual codec profile is suspected. For percussion MIDI, use Import MIDI with a .mid or .midi file rather than one of the audio commands.

Full-mix separation fails

Install a complete release package rather than copying only the executable. The Linux and Windows bundles include the HTDemucs drum model and the matching ONNX Runtime files. If those resources are missing, the app may fall back to analyzing the full mix with a warning; that result needs extra review because other instruments remain in the evidence.

The score is empty or noisy

For an empty score, raise Detection sensitivity gradually or try an isolated drum stem. For too many false hits, lower sensitivity and check whether bass, guitar, clicks, or mastering transients remain in the source. Do not solve a dense full mix by deleting hundreds of events before checking whether the source command and separation stage were appropriate.

Playback is silent

Confirm that the project has connected source audio, the operating system has an available output device, master gain is audible, and no unintended mute/solo combination is active. A project opened without its original audio can still show the saved score while playback evidence remains unavailable.

A project opens with a source warning

The source may have moved, disappeared, or changed since the project was saved. Backbeat Forge uses a fingerprint to prevent a different recording from being attached silently. Keep reviewing the saved score, restore the matching audio, or intentionally open a replacement and save a new project after checking the relationship. See Projects and source recovery.

Export is unavailable

Community Edition is free for detection and score review. Editing, quantization, PDF export, and MIDI export require an optional licensed edition. If a valid license is installed and export still fails, verify the destination is writable and retry with a short local path.

Isolate the failing stage before changing settings

Use one short, known source and record the last stage that completed. Do not lower sensitivity, reinstall the application, move the project, and change the audio device in one attempt; that destroys the evidence needed to identify the cause.

Last successful stage	Next boundary to test	Useful evidence
File selected	Decoder opens and plays it	Format, duration, short PCM WAV comparison
Full mix opened	Separation resources load	Complete package, warning text, same time range
Score generated	Events match audible hits	Sensitivity, source type, expected kit piece
Project saved	Reopen restores source identity	Project path, source path, fingerprint warning
Playback started	Mixer and output stay audible	Device, master gain, mute and solo state
Export dialog opened	Destination accepts the file	Local writable path and target format

Preserve the original source and .bforge file before testing. Use a copy for container conversion or intentional source replacement. When a warning appears, record its exact stage and wording instead of summarizing it as “transcription failed.”

Why does changing sensitivity not fix a source-opening error?

Sensitivity is used after decoding and, for a full mix, after separation. If the file cannot open, first test its container, codec, permissions, and a short PCM WAV copy. Analysis controls cannot repair an earlier boundary.

Why can the score open while playback is silent?

The project stores notation separately from the connected audio evidence. A moved or changed source can leave the score recoverable while playback remains unavailable. Restore the fingerprint-matching recording and verify output-device and mixer state.

What belongs in a reproducible support report?

Include platform, application version, input type, file format, failing stage, time range, selected sensitivity and grid, exact warning, and whether a short local test file behaves differently. Do not publish private recordings merely to prove that a local stage failed.

For the normal sequence, return to Quick start and Transcription workflow. Download the current complete package from Backbeat Forge downloads.

Direct answer and acceptance boundary

For “Troubleshooting audio, projects, playback, and drum-score export”, the short answer is: Start with the named stage that failed: opening the source, separating drums, detecting hits, reviewing playback, reopening a project, or exporting. Preserve the original file and .bforge project while you investigate. 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: Troubleshooting audio, projects, playback, and drum-score export

Treat “Troubleshooting audio, projects, playback, and drum-score export” as a separate acceptance gate for “Troubleshooting audio, projects, playback, and drum-score export”. 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: Start with the named stage that failed: opening the source, separating drums, detecting hi

Verify “Start with the named stage that failed: opening the source, separating drums, detecting hits, reviewing playback, reopening a project, or exporting. P” 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: The source will not open

For “The source will not open”, 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 separation fails

Use “Full-mix separation fails” 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: The score is empty or noisy

When “The score is empty or noisy” 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: Playback is silent

Close “Playback is silent” 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: A project opens with a source warning

Treat “A project opens with a source warning” as a separate acceptance gate for “Troubleshooting audio, projects, playback, and drum-score export”. 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: Export is unavailable

Verify “Export is unavailable” 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: Isolate the failing stage before changing settings

For “Isolate the failing stage before changing settings”, 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: Why does changing sensitivity not fix a source-opening error?

Use “Why does changing sensitivity not fix a source-opening error?” 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
Troubleshooting audio, projects, playback, and drum-score export	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Start with the named stage that failed: opening the source, separating drums, detecting hits, reviewing playback, reopen	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
The source will not open	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Full-mix separation fails	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
The score is empty or noisy	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Playback is silent	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: