Repository navigation
Reopening a Stem refuses one whose audio starts later than ours (#881) - #930
Merged
Merged
Conversation
Skeyelab
enabled auto-merge (squash)
October 22, 2026 22:59
StemWriter.reopen assumed this writer's header size. For a Stem a DAW re-saved with its own chunk ahead of the audio, Repair's fill, a Marker rename and a channel rename wrote at the wrong offsets and could cut the file short. It now throws, and nothing is written. ChannelRenamer reopens the Stem before it moves it, so a refused Stem keeps its name. Checked only by tests, not on a Mac with a DAW. Assisted-by: Claude Code:claude-sonnet-5-5
Skeyelab
force-pushed
the
fix/881-reopen-datastart
branch
from
October 23, 2026 05:05
ab88e71 to
265e548
Compare
2 tasks
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #881.
StemWriter.reopenassumed this writer's header size, so a Stem a DAW re-saved (its own chunk ahead of the audio) could be cut short and overwritten at the start by Repair's fill, a Marker rename or a channel rename.reopennow throws whenStemFile.inspect(url).dataStart != StemWriter.dataStart; nothing is written. Our own Stems, plain RIFF and RF64 alike, always start their audio atdataStart(the header doesn't depend on Info and RF64 promotion rewrites it in place); a test pins an RF64 reopen.ChannelRenamermoved the file before it reopened it, so a refusal would have left a renamed Stem and an old Take.json. It now reopens first and moves last; a refused Stem keeps its name and bytes.CutOffTake.finishStemalready had its own guard.reopentest failed (it went ahead and altered the file), the channel-rename test failed (the Stem had been renamed), then the guard and the reorder. The Marker and RF64 tests passed on first run once the guard existed.TakeSession(resuming a Stem our writer made during a live Take) writes at our offsets with no check; the reviewer rated it low risk and left it.Checked only by tests, not on a Mac with a DAW. Not the real-time path. Code Reviewer: no blockers.