Chapter 19 Quiz
Closed book on the first pass — workflow doctrine only protects you when it fires from memory, usually at 1 a.m., usually with someone waiting on the file. Multiple choice, then true/false with justification (the justification carries the points), then short answer, then one applied scenario that is somebody's real week. Answers under each Verify fold; scoring guide at the end.
Section 1 — Multiple Choice (2 points each)
1. The difference between stems and multitracks is:
A) Stems are higher quality; multitracks are rough exports B) Multitracks are one file per individual track with minimal processing baked in; stems are one file per bus family, printed through the bus processing C) Stems are for hip-hop; multitracks are for rock D) There is no difference — the words are interchangeable
Verify
**B.** Multitracks (track-outs) hand over every individual element for someone who will *mix* — maximum control, maximum work. Stems hand over the decided families — bus prints — for someone who will *adjust, perform, license, or rebuild*. The words have drifted into slang synonyms in the wild, which is exactly why professionals confirm which one is meant before exporting anything.2. An outside mix engineer is hired to mix your song. They should receive:
A) Your six stems, so your bus processing guides them B) Your project file, so they can see everything C) Your multitracks plus your rough mix as a reference D) Just the rough mix — they'll ask for more if needed
Verify
**C.** A mixer needs every individual element (multitracks) plus the intent document (your rough). Stems would handcuff them to your bus decisions — you'd be hiring a mixer and pre-mixing for them. Project files don't travel across DAWs, and even same-DAW they import your plugin dependencies and clutter along with the audio.3. Every printed file must start at the project's first sample — even a part that doesn't enter until 2:14 — because:
A) DAWs refuse to import files with different start times B) A bare audio file has no way to store its own timeline position; leading silence encodes the position in the audio itself, the one coordinate system every DAW shares C) The silence improves the sound of the file D) It makes all the files the same size on disk
Verify
**B.** A WAV knows its sample rate, bit depth, and data — nothing else. Position lives in project files, and project files don't travel. Pad the front with silence and the part's location becomes indestructible: drag to zero in any program, any decade, and it lands where it lives.4. The "same length" rule — every printed file runs from project start to project end — exists primarily so that:
A) The recipient can verify at a glance that nothing was trimmed or shifted, and drop any file at zero with certainty B) Reverb tails sound longer C) File sizes stay uniform for uploading D) The DAW can play them faster
Verify
**A.** Identical lengths are the integrity check: matching durations prove no file lost its head or tail, and guarantee that zero-alignment works for every file forever. (Letting effect tails ring out before the end point is the related craft rule — a clipped tail is the classic amateur tell.)5. The chapter bans "final" from file names because:
A) It's unprofessional slang
B) Version numbers are shorter to type
C) "Final" is a prophecy, not a description — and when the inevitable change request arrives, the name system collapses into final2 archaeology or silent overwrites
D) Distributors reject files named final
Verify
**C.** Names must describe present state; "final" makes a claim about the future. When the future disagrees — and it will — your options are breaking the prophecy (`FINAL2`, `ACTUALfinal`) or overwriting a file someone may have approved. `v2.4` is a fact that stays true no matter how many versions follow it.6. The 3-2-1 backup rule means:
A) Back up three times a day, two times a week, once a month B) Three copies, on two different kinds of storage, with one offsite C) Three drives, two computers, one cloud account D) Three projects, two backups each, one master list
Verify
**B.** Each number defeats a different failure flavor: three copies beats single-device death; two media beats common-cause death (surge, malware, one bad bag); one offsite beats failures that take the whole room — fire, theft, the backpack containing laptop *and* backup drive.7. Cloud sync (without version history) is not, by itself, backup because:
A) Cloud storage is too slow for audio B) Sync's job is making every device match — so it propagates deletions and corruptions as faithfully as it propagates songs C) Sync services compress WAV files into MP3s D) Sync only works on project files, not audio
Verify
**B.** A sync service mirrors state; delete or corrupt a file on one device and the mirror dutifully spreads the damage everywhere. What makes a cloud copy *backup* is versioning — the ability to retrieve the file as it was last Tuesday, not merely as it is now.8. The consolidated feedback round — all notes, one deduplicated document, against one named version — exists because the alternative (the drip-feed) causes:
A) Hurt feelings B) Slower uploads C) Work against a moving target, colliding and contradictory notes, and a receiver who must guess when the trickle ends D) Larger file sizes
Verify
**C.** Fourteen texts across three days arrive mid-change, half about things other notes already altered, some contradicting each other because the senders never compared reactions. One batched doc against one named version kills all three failure modes. Less is more is a communication law too.9. The anatomy of a protocol-grade note is:
A) A compliment, a criticism, and a compliment B) Timestamp — element — observation, with any suggestion clearly labeled as a guess C) A paragraph of context, then the note D) The fix you want, stated as an order
Verify
**B.** "1:07 — pad — swallows the vocal's first word" is checkable in thirty seconds. The timestamp converts opinion into location; the observation is the data; the prescription, if offered, is labeled as the guess it is — because the note-giver is an excellent smoke detector and an unreliable electrician.10. The reference mix travels with every send package because:
A) It proves you did the work B) Words like "spacious" and "intimate" mean something different in every head, but a rough mix is unambiguous about every balance and intention — including ones you don't know you have C) Collaborators expect a free song D) It pads the zip to a respectable size
Verify
**B.** The rough is the intent document — the only note that cannot be misread. An embarrassing rough beats an eloquent paragraph every time, which is why it ships version-tagged, with everything, always.11. Deciding wet versus dry for a multitrack print, the chapter's doctrine is:
A) Print everything dry — processing is the mixer's job B) Print everything wet — it's your sound C) If the processing is part of the instrument's identity, print it; if it's the mix's shared space, print it separately (and nothing from the 2-bus, ever) D) Flip a coin and note the result
Verify
**C.** Hard-tune, sound-design motion, edits and comps: identity — baked in. Shared reverb/delay sends: printed as their own return files, so the recipient gets the dry truth and the spatial intent separately. The master-bus chain stays off every print — a limiter baked into thirty-four files is distortion the mixer inherits forever.12. The baton rule states:
A) The producer always holds the session B) At any moment exactly one person holds the editable project; everyone else works on prints, and the baton is handed explicitly C) Sessions should be co-edited live for speed D) Whoever started the song owns the session forever
Verify
**B.** Two editable copies means two diverging songs and a merge job nobody enjoys. Singers track against prints, note-givers listen to prints, the baton-holder integrates — and the handoff is said out loud: "it's yours till Friday."13. Which of these does NOT belong in the README of a send package?
A) BPM, key, and sample rate/bit depth B) "All files start from 0:00" C) The file list with one-line notes, and what you want from the recipient D) Your complete plugin list with the serial numbers for each license
Verify
**D.** The send-package README answers the recipient's working questions: tempo, key, format, start point, what's in the box, what you need, how to reach you. (A plugin manifest *does* belong in the archival README of a time capsule — different document, different stranger.)14. This book's definition of the producer is:
A) The person who made the beat B) The person who owns the studio C) The person responsible for the record being good — and being finished: vision, decisions, logistics, psychology D) The person who pays for the session
Verify
**C.** The definition contains both cultural senses — the hip-hop track-maker and the rock-lineage director — because what they share is responsibility for quality *and completion*. Everything in this chapter, from folder trees to gravy takes, is producer work under that definition.15. Three listeners independently flag 1:12, with three different explanations. The chapter's rule:
A) Ignore all three — they contradict each other B) Implement all three suggested fixes C) Trust the convergence (something is true at 1:12) and hold the diagnoses loosely — go diagnose it yourself D) Trust whichever listener has the best monitors
Verify
**C.** Convergent timestamps are a fact about your record even when the explanations conflict — three smoke detectors went off in the same room. The diagnoses are leads, not verdicts; the location is gold.Section 2 — True/False, with Justification (2 points each — the justification is the point)
16. "Stems" and "multitracks" mean the same thing, and asking which one someone wants is pedantic.
Verify
**False.** They name different packages — bus prints versus one-file-per-track — that take different effort to make, grant different powers, and expose your production differently. The wild does use "stems" as slang for both, which is precisely why the clarifying question ("submixes or every track — how many files are you expecting?") is twenty seconds that routinely saves a full day of re-exporting.17. Printing your multitracks through the limiter on your master bus is good practice, because the files arrive sounding finished.
Verify
**False.** The 2-bus chain stays off every print. A limiter baked into every file is processing the recipient cannot remove — the mixer inherits your distortion and loses the headroom they need to work. Prints carry the parts; the rough mix carries the intent; the master chain belongs to whoever masters ([Chapter 31](../../part-07-mastering/chapter-31-what-is-mastering/index.md)'s story).18. A considerate collaborator sends each note the moment they think of it, so nothing gets forgotten.
Verify
**False.** That's the drip-feed: notes landing mid-change, colliding with each other, forcing the receiver to work against a moving target or freeze. Considerate is *batched*: capture notes as they occur, then consolidate, deduplicate, and send once, against a named version. "You'll have all my thoughts by Thursday" is the professional form of timeliness.19. If your rough mix is embarrassing, it's better to send a well-written description of your intent instead.
Verify
**False.** The rough mix is the only note that can't be misread — every balance, space, and intention demonstrated rather than described, including intentions you don't know you have. Words filter through the reader's imagination; audio doesn't. The embarrassing rough ships anyway, version-tagged, with everything.20. Declining a collaborator's note — with a stated reason tied to the song's goal — is a legitimate outcome of a feedback round.
Verify
**True.** A round is input, not orders; the roles agreement names a decider, and deciding out loud is the job. "Keeping the drumless bridge — the emptiness is the point" closes a note respectfully. The two failure modes flank the truth: silent stonewalling (notes left unanswered, festering) and universal vetoing (you wanted applause, not feedback).Section 3 — Short Answer (4 points each)
21. You're sending your song to an outside mix engineer. List the complete send package, item by item, with one reason each.
Verify
(1) Multitracks — one file per track, printed from zero, same length, session sample rate/bit depth, numbered in mixer order, identity processing baked, shared-space sends printed as separate return files, no 2-bus processing: the actual work, with every fader available to the person hired to move faders. (2) The rough mix, version-tagged: the intent document. (3) README.txt — BPM, key, sample rate/bit depth, "all files from 0:00," file list with one-line notes, what you want, contact: every question answered before it's asked. (4) The brief — three sentences plus one to three reference tracks: scope. (5) Filename metadata (BPM/key/version in names): facts that survive separation from the README. (6) One zip, properly named and version-tagged, sent via a service that doesn't transcode. Not included: project files, sample libraries, fourteen alternates, your indecision.22. Name two independent mechanisms by which a session that opens perfectly today will fail in ten years, and list what goes into the time capsule that makes the failure survivable.
Verify
Mechanisms (any two): plugin extinction — sessions store *requests* for plugins by name and version, and architectures get deprecated, companies die, licenses lapse; broken media references — DAWs store paths, not copies, so moved or renamed folders orphan the audio; and format drift — proprietary session formats carry no decade-scale compatibility promise. The capsule: collected session (media gathered inside the project folder), consolidated multitracks from zero, stems, the final mix print, and an archival README with tempo, key, structure, and the plugin manifest (settings noted for irreplaceable sounds). Audio is forever; sessions are weather.23. State the three rules for giving useful feedback, plus the two delivery moves that make notes land.
Verify
Rules: (1) specific and located — timestamp + element + observation, never "kinda muddy somewhere"; (2) about the goal, not your taste — measured against what the track is trying to be, which the brief and references defined; (3) problems over prescriptions — report what you hear, label any suggested fix as the guess it is, because note-givers are reliable detectors and unreliable diagnosticians. Delivery: open with what's working, as orientation (it tells them what not to break — information available nowhere else), and calibrate first ("vibe check or surgical?") so the kind of notes matches what the receiver can use.24. A producer must repeatedly judge "one more take, or move on?" Describe the signs on each side of that decision, and the cheapest way to ask for the take after "we got it."
Verify
Push when energy is rising: takes improving, the performer loosening, the sense that there's a gear they don't know they have. The cheapest ask removes the stakes — "we have it; give me one for fun" — which is why the gravy take so often wins (Demi's take six did). Stop when returns diminish: voice tiring, takes converging on identical, frustration compounding — past that point each take *subtracts*, eroding the performer's trust in keepers already captured and burning fresh judgment that can't be bought back. The craft is noticing which side of the curve the session is on while it's happening, not in the car home.Section 4 — Applied Scenario (8 points)
25. You're asked to rescue a stalled long-distance collaboration between a producer and a singer. The wreckage, as reported: the singer received forty-one files in which "every part starts at its own first note," so nothing lines up; the files turned out to be 44.1 kHz against the producer's 48 kHz session, documented nowhere; feedback has arrived as twenty-three texts spread over two weeks, several contradicting each other; there are now two diverging projects — final_MINE on the producer's laptop and FINAL_singer_edit on the singer's — because both kept working; the only "backup" was a sync folder without version history, through which an accidental deletion of the chorus takes propagated to every device; and the singer has stopped sending notes entirely, because the producer answered her last batch with a point-by-point defense of every choice. Both parties still want the song. Write your triage: the order you'd work, what each fix involves, which damage may be unrecoverable, and the one-line prevention rule each failure teaches.
Verify
Strong answers triage damage-per-minute and treat the humans as part of the system. A defensible order: **(1) The chorus takes (first, because data loss compounds):** hunt every possible surviving copy — the singer's recording machine and DAW auto-saves/temp folders, the sync service's trash and any version window, email/transfer-service attachments from the original delivery, the engineer's drive if one tracked her. If genuinely gone, they're gone: **the propagated deletion is the potentially unrecoverable wound.** Rule: sync is not backup — 3-2-1 with versioning, and a restore test before you need it. **(2) Declare a canonical version (10 min, unblocks everything):** the baton rule, retroactively — pick one project as the trunk (likely the producer's, as the fuller session), inventory what the fork contains worth merging (the singer's edits as printed audio, not session surgery), and name the merged result `v2.0` under a real grammar. Rule: one editable copy; everyone else works on prints; "final" is banned. **(3) Re-deliver the files correctly (an hour):** all parts re-printed from zero, same length, at the session's 48 kHz/24-bit, named and numbered, with a README carrying BPM/key/rate and the from-zero note. Explain what the 44.1/48 mismatch does when unnoticed (wrong-rate playback shifts pitch and timing; auto-conversion saves you silently until the one time it doesn't). Rule: document the format; put BPM/key/rate in the README and the filenames. **(4) Reset the feedback protocol (one call):** all open notes consolidated into one deduplicated, timestamped doc against the new v2.0; agree on rounds, windows, and — critically — who decides what (she gets approval over her voice; he holds the production baton). Rule: one round, one doc, one decider. **(5) Repair the human damage (same call, goes last only in sequence, not importance):** the point-by-point defense was the receiver-side failure — defending in real time instead of receiving. The producer's move now: thank her for the notes, answer each with accept/defer/veto-plus-reason *in the doc, not in combat*, and accept visibly where she was right. Rule: thank, write down, decide later; the note is about the file. Full credit requires: takes-recovery first with sync-is-not-backup named, the fork resolved via baton logic, from-zero/same-length/format-documentation prescribed correctly, the consolidated round installed, the defensive reply identified as a protocol violation with its repair — and a tone that diagnoses systems rather than convicting people, because both of these humans behaved exactly as untrained people always do.Scoring
| Section | Items | Points |
|---|---|---|
| 1 — Multiple choice | 15 × 2 | 30 |
| 2 — True/False + justification | 5 × 2 | 10 |
| 3 — Short answer | 4 × 4 | 16 |
| 4 — Applied scenario | 1 × 8 | 8 |
| Total | 64 |
| Score | Reading |
|---|---|
| 58–64 | Professional. People will say you're easy to work with, which is the highest-paying review in this industry. Proceed to Part V with a clean session. |
| 48–57 | Solid. Re-read whichever doctrine leaked points — the printing rules and the consolidated round are the two that protect you from the most expensive mistakes. |
| 38–47 | The definitions are in, but the reflexes aren't. Do exercises C2 and C5 (the printing drill and the real feedback exchange) before Part V — this chapter only becomes true in transit. |
| Below 38 | Reread with your own projects folder open and the damage visible. Then run C1, the hygiene resurrection — nothing teaches workflow like meeting your own past self as a stranger. |