A narrated software demonstration may need some computer sounds and none of the others. An application confirmation can help explain a completed action, while an unrelated message alert can interrupt the narration or imply the wrong event. Decide which sounds belong in the demonstration before recording the screen and voice.
The useful commission is an intentional audio source plan. It should identify the application's meaningful cues, the narrator's contribution and any other sound the recording system might capture. A general instruction to include system audio leaves too much interpretation to the operator and editor.
Give each sound an explanatory job
List the cues the viewer needs to hear and the action each one represents. If a sound carries essential information, decide how that information is also explained for viewers who cannot or do not listen. If the cue is merely incidental, consider whether it needs to appear at all.
Avoid adding a familiar confirmation sound in postproduction when the application did not produce it, unless the film clearly uses it as an illustrative treatment. Otherwise the soundtrack can suggest a successful state that the recorded interface has not established.
Ask what can be separated
The proposed workflow may capture all computer audio as one source or allow selected applications to be handled independently. RØDE's virtual-device guidance describes application-source separation with operating-system and application dependencies. It is a product-specific example, not a guarantee that every screen recorder can isolate every source.
Ask the producer to demonstrate the actual arrangement. If independent control is needed for editing, confirm that separation survives into the recorded files rather than existing only in the operator's headphones or live mix.
Test an action and its narration together
Record a short sequence containing the intended application cue and the spoken explanation. Check that the sound matches the visible state and arrives at the right moment. The narrator should not have to compete with an unnecessarily prominent cue, but the editor should retain enough information to represent the interaction accurately.
A hypothetical project-management software demonstration shows a document moving into an approved workflow state. The application produces a useful confirmation, while a separate communication app generates an unrelated alert. A source test identifies both. The production captures the intended cue deliberately and excludes the irrelevant application from the authorised recording path.
Define the treatment of later changes
If the application changes its sounds or the demonstration is rerecorded, review the audio relationship again. Reusing an old cue may be inappropriate if it now represents a different action. Keep the selected audio tied to the demonstrated software version and approved sequence.
At handover, identify whether the editor receives separate narration and application sources or a combined recording. If they are combined, make the limitation explicit before promising extensive later control.
Acceptance questions include which sounds are intentional, whether they correspond to the actual interface state and whether the editor has the control required by the brief. This turns computer audio from an accidental by-product into a considered part of the explanation, while keeping the narration and demonstrated behaviour clear.
Discuss the production
Contact Live Images to discuss the proposed film, intended audience and audio requirements. Confirm suitability, scope and availability for your particular brief.
Editorial note
Original commissioning guidance prepared with AI assistance. Examples are hypothetical, not completed Live Images projects. Search intent is an editorial hypothesis, not measured demand. This draft remains unpublished.