Key takeaways
- Every mix revision should include a labeled bounce, revision number, date, short reference notes, and a stated feedback deadline.
- Use a zero-padded naming convention like SongName_v03_2025-01-14_vocalup.wav and never overwrite an old bounce.
- Send streaming preview links for early rounds and reserve 24-bit WAV delivery for final sign-off.
- Collect timestamped comments in one channel per song instead of assembling notes from texts and emails.
- State the included revision count and the price per extra round in your quote before the first bounce leaves your studio.
Knowing how to share mix revisions with clients comes down to one system: a single branded link that carries both a streaming preview for quick listens and a lossless download for final approval, with every version labeled by date and revision number. That replaces the WeTransfer-and-SoundCloud patchwork, keeps feedback in one thread, and makes each round easy for the client to play back consistently.
What should you include when sending a mix revision to a client?
A mix revision needs five things: the labeled bounce, the revision number, the date, short reference notes on what changed, and a deadline for feedback. Skip any one of them and you invite a second round that exists only because the client was guessing.
The revision bundle checklist
- Labeled bounce in the format your client can actually play, at the quality you agreed on.
- Revision number and date in the filename:
SongName_v03_2025-01-14.wav. - Reference notes: three bullet points on what you changed and what you want their opinion on.
- A feedback deadline, stated plainly, so the round closes instead of drifting.
Host the bundle somewhere the client can stream it without downloading, with a preview-only link if they are early in the process. A portal like RockScience Audio Portal keeps every round in one branded place, so version history lives with the audio instead of in your sent-mail folder.
Why a naked MP3 link creates more rounds
A bare link with no notes forces the client to reconstruct context from memory. They hear one thing, you meant another, and the round produces comments on parts you already fixed. Most streaming apps also normalize loudness, so if your client evaluates on a streaming app, tell them that in the notes. Context in the bundle is cheaper than an extra revision round.
How do you label and version mix revisions so nothing gets confused?
The fix is two things: a naming convention both sides use, and one place where every version lives. When a client texts “the chorus one,” you need to know exactly which bounce they mean.
A naming convention that survives email and text threads
Use this pattern on every export:
SongName_v03_2025-01-14_vocalup.wav
That gives you the song, the revision number (zero-padded so v10 sorts after v9), the date, and a short note on what changed. No spaces, no parentheses, nothing that breaks in a text message or gets mangled by a download manager. When you change something, the number goes up. Never overwrite v02 to make v03; the old bounce is your proof of what the client approved.
Keeping a version history the client can see
Your version history can’t live only in your session folder. If the client has to dig through a WeTransfer email chain to find the latest bounce, they will reference the wrong one. Keep every revision in one folder the client can open, newest at top, so both of you point at the same file. RockScience Audio Portal does this with folder-level access and version history under your own branding, and Filepass and Boombox offer similar client-facing versioning. Where a plain Dropbox link falls short is labeling: it shows filenames, not which revision is current, so say “latest is v04” in the message itself every time.
Which file format and streaming quality should clients use to evaluate a mix?
Match the format to the stage: streaming previews for rounds one and two, lossless WAV only when the client is signing off. A 320 kbps-style stream is fine for judging balance, vocal level, and arrangement notes, but it hides exactly the things a final approval rests on: cymbal decay, low-level reverb tails, and the top end of a master.
Preview-only links for round one
Send a streaming preview link, not a download, for early revisions. Previews stop the client from dragging your mix into their phone’s music library and judging it against commercial masters, and they make it obvious which version is current. Label the link with the revision number so “the one from Tuesday” never enters the conversation.
Lossless for the final pass
For sign-off, send a 24-bit WAV at your session’s native sample rate. Uncompressed formats preserve the full signal chain without codec artifacts, which is why most delivery specs name WAV or another lossless format for masters. The point for your client is simpler: the file they approve should be the file you deliver, bit for bit, so nobody approves one bounce and receives another.
Confirming the client hears the same master you do
The risk in the preview stage is loudness normalization. Phone players and some browser players turn tracks up or down automatically, so your client may hear a different level than you bounced. Ask them to listen on one consistent setup, note which device they used, and if their notes mention a level problem you cannot reproduce, request a screenshot of their player or a quick call. A separate preview-only link keeps this stage contained instead of leaking full files into every revision round.
How do you collect consolidated feedback instead of scattered notes?
Scattered feedback is the fastest way to miss a note. A text at 11pm, a voicemail the next morning, and an email with “also the vocal feels a touch loud in the second chorus” means you’re assembling the revision list yourself, and something always slips. One channel, one song, one list.
Timestamped notes beat paragraph emails
Ask clients to comment at the moment they hear the problem, not after. “2:14 – snare too loud” takes them five seconds and takes you zero interpretation. Paragraph emails force you to scrub the timeline guessing where “that bit” is. A timestamp turns vague notes into an actionable list, and it makes patterns obvious: three comments at the drop means the drop needs work.
One feedback channel per song
Pick a single place for notes per song and say so in your delivery message. If the client insists on texting, you transcribe their notes into the channel yourself so the list stays complete. Tools built for this, like Filepass, Boombox, Samply, Audome, or our own RockScience Audio Portal, let clients comment directly on the waveform, so notes land with timestamps attached instead of in your inbox.
When should you send a bounce versus a full session export?
Bounces for approvals, sessions for handoffs
Send a stereo bounce whenever the goal is approval: revisions, mix checks, mastering previews. The client listens and gives notes; nobody needs the raw material. A full session export is for handoff, when another engineer will keep working on the material. If you are the last set of hands on the project, the client never needs the session.
Stems and dual-mono stems: when they’re actually needed
Stems earn their place when the client’s engineer will re-balance, edit for picture, or print alternate versions. Dual-mono stems matter for live sound and broadcast delivery, where L and R need independent processing. If the deliverable list does not name stems, do not bounce them; they double your render time and invite unauthorized edits.
One honest caveat: most client-facing portals, including our own Audio Portal, are built around bounces and streaming previews, not session handoff. For stem bundles, a transfer tool like WeTransfer or a direct portal such as Filepass still fits the delivery step.
Which sharing method fits which client and revision stage?
The decision framework
Match the method to the client and the stage, not to whatever you used last time.
| Method | Best for | Stage |
|---|---|---|
| Streaming preview link | Clients judging balance and level on their own speakers | Rough mixes, early revisions |
| Branded transfer portal (RockScience, Filepass, Boombox, Samply, Audome) | Stems, lossless masters, version history, consolidated comments | Approved direction, final delivery |
| Generic transfer (WeTransfer) | One-off bounces for a hands-off client | Any stage, no feedback needed |
| Session export | Collaborators with their own DAW | Only when they’ll actually open it |
Run each row through the same test: does playback stay consistent, is feedback in one place, and is the version label unambiguous? Generic transfer fails all three, which is fine for a client who never sends notes and never confuses files.
Where a branded portal fits, and where it doesn’t
Honest take on our own tool: RockScience Audio Portal wins on folder-level access, preview-only links, and dual-mono stem delivery under your own branding, at $9/mo. It does not replace a session export, and a client who just wants an MP3 in their inbox gains nothing from a portal login. For that client, WeTransfer is the right answer, not a compromise.
How do you handle endless revision requests without scope creep?
Endless revisions die the moment your quote says how many are included. State a number, state the price per extra round, and put both in writing before the first bounce leaves your studio. Solo engineers absorb the cost of vague terms, because every “one more tweak” lands on a fixed fee. A written deliverable count is the cheapest insurance you can buy.
Setting the revision count in your quote
Two or three rounds is the common norm for mix and master work, but the number matters less than the boundary. Write it plainly: “Includes two revision rounds. Further rounds billed at $X per round.” Also define what counts as a round, because a client sending ten notes over three days is one round, not ten.
A copy-paste revision request template
Send this with every bounce:
Round 2 notes, please send by Friday:
- Timestamp + what to change
- Timestamp + what to change
This is revision 2 of 3 included in the quote. Additional rounds are $X.
The template does three jobs at once: it forces consolidated feedback, it labels the version, and it shows the remaining count without you having an awkward conversation. Clients who see “2 of 3” self-police.
What does a complete revision round look like, start to finish?
Worked example: one song, three rounds
Round 1: you bounce v1 at 16-bit/44.1 WAV, label it SongTitle_v1_2024-06-03, and send a preview-only link so the client can stream it without downloading. Feedback comes back consolidated in one place: vocals up 1 dB in the choruses, snare too bright. Round 2: you print SongTitle_v2_2024-06-06, note the changes in your version history, and send it with the same link structure; the client approves the vocal level but flags the low end. Round 3: SongTitle_v3_2024-06-09 fixes the low end and the client signs off. You deliver final masters plus dual-mono stems through the same branded portal, so every version of the song lives under one roof instead of scattered across a transfer service and a NAS. Three rounds, three labeled bounces, zero confusion about which mix is current, and the whole exchange fits in one thread your client can reopen a year later.
FAQ
How many mix revisions should I include for free before charging extra?
Two or three rounds is the common norm for mix and master work. The number matters less than writing the boundary into your quote before the first bounce leaves your studio: “Includes two revision rounds. Further rounds billed at $X per round.” Also define what counts as a round, so ten notes over three days is one round, not ten.
Is it okay to send mix revisions over SoundCloud private links?
It works for a quick listen, but you lose control of the details that prevent extra rounds. SoundCloud shows no version history, no revision labeling, and no consolidated feedback thread, so “the one from Tuesday” enters the conversation. A branded portal keeps every round in one place with preview-only links; a private link is fine for a hands-off client who never sends notes.
What bit rate should a client preview a mix at before final approval?
A 320 kbps-style stream is fine for judging balance, vocal level, and arrangement notes during rounds one and two. Final approval should happen on a 24-bit WAV at your session’s native sample rate, because lossy streams hide exactly what sign-off rests on: cymbal decay, low-level reverb tails, and top-end detail. The file they approve should be the file you deliver.
How do I ask a client for feedback on a mix without getting vague notes back?
Ask for timestamped comments at the moment they hear the problem, not a paragraph email afterward. “2:14 – snare too loud” takes five seconds and needs no interpretation. Send a short template with every bounce that lists the revision number, the deadline, and how many rounds remain. Pick one feedback channel per song and transcribe anything that arrives by text.
Should I send stems or a mix bounce when the client wants changes?
Send a stereo bounce. Revisions are an approval process, and the client only needs to listen and give notes. Stems earn their place when the client’s engineer will re-balance, edit for picture, or print alternate versions. If the deliverable list does not name stems, do not bounce them; they double your render time and invite unauthorized edits.
Leave a Reply
You must be logged in to post a comment.