fix: preview source audio stops around 20s due to unreliable reported duration

[mvanhorn]

Pull Request Template

Description

Preview playback no longer cuts the source audio off around the 20-second mark. The audio-preview sync now treats an implausibly short reported media duration as unknown rather than trusting it, so audio keeps syncing for the real length of the clip.

Motivation

Issue #642 reports that in the video-editor preview the source audio stops at roughly 20 seconds even though the clip is longer. Early in playback the media element can report an implausibly short duration; the audio-preview sync trusted that value and stopped driving audio past it. This adds a mediaTiming helper that rejects implausibly short/invalid durations (treating them as unknown), and useAudioPreviewSync uses it so a bogus early duration no longer truncates audio; when a valid duration is later reported, normal syncing continues.

Type of Change

• New Feature
• Bug Fix
• Refactor / Code Cleanup
• Documentation Update
• Other (please specify)

Related Issue(s)

Fixes #642

Screenshots / Video

N/A — this is a timing/logic fix in the preview audio sync path with no UI change. Behavior is covered by unit tests rather than a visual capture.

Testing Guide

Run the unit tests: mediaTiming.test.ts passes, covering a valid duration being accepted, an implausibly short/zero/NaN duration treated as unknown, and a later valid duration being honored. To verify manually, open a clip longer than ~20s in the preview and confirm source audio continues past 20s.

Checklist

• I have performed a self-review of my code.
• I have added any necessary screenshots or videos. (N/A — no UI change; covered by unit tests)
• I have linked related issue(s) and updated the changelog if applicable. (linked [Bug]: 录制的视频在20s左右就会丢失音频 #642; no changelog applicable)

---

Thank you for contributing!

Summary by CodeRabbit

• New Features

  • Improved media preview timing by better resolving audio duration when the reported length is missing, invalid, or unreliable.
  • Preview playback now handles end-of-track and seek behavior more consistently across different media sources.

• Bug Fixes

  • Reduced cases where audio previews could stop early, seek incorrectly, or fail to detect the end of playback.
  • Added coverage for duration edge cases to help keep timing behavior stable.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 0fc11b10-7e4a-43b9-926a-1033c0628fa5

📥 Commits

Reviewing files that changed from the base of the PR and between 0726a08 and aa7904b.

📒 Files selected for processing (3)

• src/components/video-editor/audio/useAudioPreviewSync.ts
• src/lib/mediaTiming.test.ts
• src/lib/mediaTiming.ts

---

📝 Walkthrough

Walkthrough

Adds a new resolvePreviewMediaDuration function to mediaTiming.ts with tolerance-based validation logic, adds corresponding unit tests, and updates useAudioPreviewSync.ts to use this function instead of a simple finite-check when computing audio duration for preview sync.

Changes

Preview audio duration resolution

Layer / File(s)	Summary
resolvePreviewMediaDuration helper and tests src/lib/mediaTiming.ts, src/lib/mediaTiming.test.ts	New tolerance constants and exported resolvePreviewMediaDuration(reportedDuration, timelineDuration) validate/clamp inputs, return null for non-finite or implausible durations, and fall back to sanitized reported duration; tests cover matching, invalid, and fallback cases.
Wire helper into audio preview sync src/components/video-editor/audio/useAudioPreviewSync.ts	Imports and applies resolvePreviewMediaDuration(audio.duration, duration) to compute audioDuration, replacing the prior finite-check, affecting targetTime clamping and atEnd detection.

Estimated code review effort: 2 (Simple) | ~10 minutes

Sequence Diagram(s)

sequenceDiagram
  participant useAudioPreviewSync
  participant resolvePreviewMediaDuration
  participant AudioElement

  useAudioPreviewSync->>AudioElement: read audio.duration
  useAudioPreviewSync->>resolvePreviewMediaDuration: resolvePreviewMediaDuration(audio.duration, duration)
  resolvePreviewMediaDuration-->>useAudioPreviewSync: sanitized audioDuration or null
  useAudioPreviewSync->>useAudioPreviewSync: compute targetTime and atEnd

Loading

Related issues: #642 (fixes reported audio loss around 20 seconds during preview by resolving duration mismatches between reported and timeline durations)

Suggested labels: bug, audio, video-editor

Suggested reviewers: webadderallorg maintainers

🐰 A rabbit hums a steady tune,
Audio drifts but finds its noon,
Tolerance windows, clamped and neat,
Twenty seconds, sound complete!

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly describes the main fix: preview source audio stopping early due to unreliable duration.
Description check	✅ Passed	The description matches the template well and includes purpose, motivation, issue link, testing guide, and checklist.
Linked Issues check	✅ Passed	The changes address issue #642 by preventing bogus early durations from truncating preview audio during editing.
Out of Scope Changes check	✅ Passed	The diff stays focused on the audio-duration fix and its tests, with no unrelated code changes.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[ExtraBinoss]

Very good. No issues on my side, merging it since this is a lingering bug that affects lots of people.

[GuqierMcl]

That's fantastic—we're one step closer to a mature product!