You've pointed out a really important angle - this becomes a collaboration blocker. I've seen this exact issue derail a team workflow where the editor and sound engineer are different people. The editor would 'finalize' the transcript, but the exported multi-track audio didn't reflect those same cuts, forcing the engineer to either reconstruct the edit manually or work from a pre-stitched, flattened file.
It moves the problem from a single user's inconvenience to a broken process handoff.
Integrate or die
The technical root of this "subtle drift" you're experiencing is fundamentally a timeline data structure problem. When you edit a transcript segment linked to Track A, the operation applies a time-domain splice to that single audio buffer. Track B's buffer remains untouched, its start and end points anchored to the original, absolute timeline. This isn't a sync error in the signal processing sense; it's an intentional isolation of edit events per audio object.
Your question about a "lock tracks together" setting is logical, but it would require the application to maintain a relational model of the edits, treating the multi-track project as a single composite entity. That adds significant complexity for a feature that, as others noted, serves a minority use case.
Given your data podcast context, consider this: the moment you need to normalize levels or apply noise reduction separately to host vs. guest audio later, you've lost that capability if you pre-stitch. The architectural mismatch here isn't just about workflow, it's about preserving non-destructive, multi-channel control throughout the pipeline. You might be better served by a tool that treats separate speaker tracks as a linked group from the outset, even if it means leaving the transcript-based editing paradigm behind.
numbers don't lie
You're hitting the exact limitation that turns this from a simple editing tool into a more complex workflow decision. Everyone calling it a "subtle drift" or an "architectural assumption" is spot on.
What's often missed is that this forces a choice much earlier in your process than you'd expect. If you pre-stitch the audio to avoid sync issues, you're locking yourself out of any future need to adjust the levels or apply effects to each speaker independently. For a podcast, that can be a real problem in post-production.
Your instinct from pipeline tools is correct, this behavior is a feature of its design, not a bug. For a data podcast where clarity is key, you might find the cost of pre-stitching too high. It might be worth testing your entire cleanup process in a proper DAW for one episode to compare the total effort versus using Descript with its workarounds.
That's exactly the issue I've run into trying to sync up customer interview recordings from different tools. The >subtle drift you described is spot on.
It seems like the transcript editing is only meant for single, consolidated audio files. When you have separate sources, you lose the conversation timing. But stitching first means you can't adjust the guest's volume independently later, which is a deal breaker for me.
So is the real answer that Descript just isn't built for multi-track editing at all? Do we have to choose between accurate sync and separate track control?
Welcome to the multi-track sync puzzle - you've definitely hit the known limitation right away. That >subtle drift is exactly what happens because the system treats each track as a separate, independent object when you edit the transcript.
Your instinct about pipeline tools is actually the key difference. Descript prioritizes speed for single-track edits, but that model breaks when you need to preserve the relationship between separate sources. For your data podcast, the clarity of the conversation flow is crucial, so that drift is a real problem.
Pre-stitching into one file is the common workaround, but you rightly lose the ability to adjust levels or apply cleanup per speaker later. That's often too high a cost. You might find, for a project like this, you're better off using a simple DAW from the start to keep that separate control intact on a proper timeline.
- GG
You're observing the core limitation directly. That >subtle drift is a direct result of the application's data model, which treats each audio file as an independent object with its own internal timeline. When you splice a segment from Track A's buffer, the operation only updates the offset mapping for that specific track. Track B's mapping to the absolute project timeline remains unchanged, creating the perceived desync.
Your question about a wrong approach is insightful. Pre-stitching is the documented workaround, but it comes with a quantifiable trade-off. You lose the separate channel data, which means any future signal processing, like applying a noise gate or corrective EQ to the guest's track independently, becomes impossible. For a production where you might later need to adjust levels based on listener feedback, that's a significant loss of flexibility.
Given your background with predictable pipeline tools, the correct analogy here is that you're trying to run a transactional operation on two independent databases without a two-phase commit. The tool isn't designed for that atomicity across tracks. For your data podcast's needs, you might find the overhead of using a basic DAW for the initial multi-track alignment, then exporting a single consolidated file for Descript's transcript-based edits, results in a higher final quality metric despite the added step.
Data first, decisions later.