“Send me the stems”: clarify the need before exporting
The client asks for “the stems so another engineer can change the kick.” Do they want the drums mixed into one file or each track separately? Naming the folder is not enough: clarify which elements the recipient needs to control and which processing each delivery should retain.
This guide proposes a text AI trial to turn an ambiguous request into a worksheet and draft questions. It includes a fictional case, a manually written reference and a measurable pilot. The trial has not been run and no results are attributed to the assistant. Listening, exporting and approval remain the studio’s responsibility.
Individual tracks, groups and effects are separate fields
iZotope distinguishes stems, groups of tracks mixed into one file, from individual tracks used for mixing. It also describes group deliveries with effects included or with reverbs and delays separate. Define the contents and processing as well as the term used.
Bunker Estudio’s public mixing instructions request instruments in separate files with a common start. Ryan Summer requests processed and unprocessed versions; his vocal version labelled dry retains pitch and timing correction. These are those professionals’ requirements: do not turn “dry” into a universal instruction to remove everything or copy their settings into every job.
On the proposed sheet, record what each file contains, what must remain separate, the reference version and which effects or corrections to retain. Ask the receiving engineer for specifications; do not assume format, channels, sample rate, bit depth or export range have been agreed.
- Recipient’s need: changing a group’s balance and editing a single element are requests to distinguish before settling the delivery.
- Contents: preserve literal names and the explicit element list; do not infer actual audio contents from a filename.
- Processing: record pitch/timing correction, effects and group or output processing separately. Unagreed details remain open.
- Final control: identify the reference version and who will check exported files. A complete sheet does not establish that the audio is correct.
Fictional case: grouped drums and a “dry” vocal with exceptions
All names, documents and files below are invented. No audio is attached. P1 is the request: “Send the stems for Faro_v3 so the new engineer can change just the kick. The vocal dry, but keep tuning and timing correction. Reverb separate.” It does not clarify whether “the vocal” means only the lead or also backing vocals.
I1 is an inventory authored by the studio engineer, not assistant analysis. It lists files existing within this fiction; it does not establish they are ready to deliver or complete exports. There are no recipient specifications or approved exports.
| Reference | File | Engineer-declared contents | Record limitation |
|---|---|---|---|
| A1 | Faro_v3_DRUMS.wav | Kick, snare and cymbals mixed into one file | No separate kick track documented |
| A2 | Faro_v3_LEAD_DRY.wav | Lead vocal; tuning and timing retained; no reverb | No backing vocals or other processing documented |
| A3 | Faro_v2_VOX_REV.wav | Vocal reverb return from version v2 | No equivalent v3 return documented |
The manual reference: what to ask, retain and leave open
For A1, ask whether the recipient needs an individual kick track and which other elements should remain separate. P1 requests control over the kick; I1 documents only a drum group. An independent track’s existence is not established. Do not rename DRUMS to KICK or promise to recover an original take from the group.
For A2, retain P1’s two exceptions: tuning and timing. Its DRY label does not authorise removing those corrections. I1 declares lead vocal, whereas P1 says “the vocal” without specifying backing vocals. Ask about vocal scope and confirm any other processing to retain; do not claim A2 satisfies the whole request.
For A3, flag v2 versus v3 and request the return corresponding to the agreed version, or express confirmation of the intended file. Do not present v2 as v3, discard it automatically or claim that a return absent from I1 does not exist.
A draft query could read: “For Faro_v3, do you need the kick individually, and which other tracks separately? Does the vocal include backing vocals? We would retain tuning and timing as P1 requests; other processing needs clarification. The inventory identifies only v2 reverb, so we need to confirm the version before preparing delivery.” This is manually written example text, not observed output or a sent message.
A trial instruction that does not touch the session
Copy only fictional P1 and I1 into a text assistant. If you choose Claude, its documentation recommends allowing uncertainty and checking claims against sources. That does not guarantee instruction compliance or conflict detection.
“Prepare a provisional delivery sheet from P1 and I1. For each request include quote and document, related file, declared contents, processing to retain, discrepancy and open question. Distinguish requested, inventoried and approved items. Do not infer audio from names, invent tracks or returns, remove corrections because of the dry label or change versions. Do not select export settings, separate audio, modify files, send links or mark delivery accepted. Identify precisely what information is missing.”
Check its output against the manual reference above. Reject statements such as “DRUMS provides an individual kick,” “dry vocal means no tuning,” or “v3 reverb is attached.” The engineer must check the session and listen to actual exports; this trial works only with text.
A pilot with reproducible failures and an option without AI
First complete a manual sheet with request, version, file, contents, processing, source and approval. If that handles your jobs, keep it. The trial’s hypothesis is that an assistant may help organise differently worded requests, not determine mix quality.
Compare its draft with the reference. In a fictional copy, change only P1’s drum request to “we want grouped drums, not separate kick editing”, keeping its vocal and reverb instructions: the individual-kick question should disappear while the reverb version question remains. In another, add a documented v3 return to I1: it should recognise it without deleting v2 or approving the complete package. These are proposed tests, not observed results.
- Count omitted requirements, invented tracks, removed exceptions, confused versions and unauthorised approvals.
- Record the full preparation, checking and correction effort against the manual sheet; do not measure only text generation speed.
- Retain inputs and failures. An error involving contents, version or processing requires correction before using the draft.
- Before sending real audio, the responsible engineer checks files against the confirmed sheet and recipient specifications. Text approval does not replace that review.
When to assess a development project for your studio
The manual trial involves copying fictional data and reviewing a response. Connected automation would require checking permissions, inventory formats, project identifiers, versions and responsibilities. This guide establishes no compatibility with your audio software, storage or management tool.
Adaris can assess a defined internal tool combining authorised requests and a delivery inventory, linking each question to its source and preparing a sheet for review. Scope, feasibility, acceptance criteria and a quote are agreed case by case. This is a custom software and AI integration proposal, not an existing Adaris studio product.
Use only this fiction for the trial. Do not upload voices, unreleased sessions, private links, contracts or real personal or commercial data without permission and appropriate access, use and retention conditions. You can describe the workflow to Adaris without sharing client material. Commercial support is in Spanish.
Related services
Sources
Does each delivery need several clarification messages?
Describe how you record requests, versions and approval. We can assess a defined development scope for your studio; commercial support is in Spanish.