Fix Windows console/file UTF-8 encoding crashes

[Prysiaznyj]

Summary

• Several helpers/*.py scripts print non-ASCII characters (arrows); on a stock Windows console (non-UTF-8 codepage, e.g. cp1252) this raises UnicodeEncodeError unless the caller happens to set PYTHONIOENCODING=utf-8 first. Reconfigure stdout to UTF-8 unconditionally at import time in render.py, grade.py, pack_transcripts.py, timeline_view.py, and transcribe_batch.py.
• render.py's build_master_srt wrote master.srt without an explicit encoding, corrupting accented characters on Windows and breaking the downstream ffmpeg subtitles burn (Invalid UTF-8 in decoded subtitles text). Now written explicitly as UTF-8.
• render.py's build_final_composite: after the encoding fix, ffmpeg's subtitles filter still failed on Windows (Invalid data found when processing input) because the absolute subtitles path used backslashes, colliding with the filter's own escaping syntax. Normalized to forward slashes before escaping the drive-letter colon.

Found and fixed while running the full transcribe → pack → render pipeline end-to-end on Windows against real footage.

Test plan

• Ran pack_transcripts.py on a real transcript on Windows without PYTHONIOENCODING set — no crash, arrow prints correctly.
• Ran the full render.py pipeline (extract → concat → subtitles burn) on Windows — master.srt accents intact, ffmpeg subtitles filter succeeds.
• Not tested on macOS/Linux (the encoding issue is Windows-specific; reconfigure(encoding="utf-8") is a no-op there since stdout is already UTF-8).

---

Summary by cubic

Fixes Windows-specific Unicode and path issues that caused UnicodeEncodeError in helper output and subtitle burn failures. Previously: helpers printed non-ASCII to a non-UTF-8 console and master.srt used the default encoding/backslash paths; now: stdout is UTF-8, master.srt is UTF-8, and subtitle paths use forward slashes with an escaped drive colon.

• Reconfigure stdout to UTF-8 at import in helpers/render.py, helpers/grade.py, helpers/pack_transcripts.py, helpers/timeline_view.py, and helpers/transcribe_batch.py. Callers no longer need PYTHONIOENCODING set. No-op on macOS/Linux.
• Write master.srt with UTF-8 encoding to preserve accents and satisfy ffmpeg subtitle parsing.
• Normalize subtitle path for ffmpeg by replacing backslashes with forward slashes and escaping the drive-letter colon to avoid filtergraph escaping conflicts on Windows.

^{Written for commit 4e7cc82. Summary will update on new commits.}

[cubic-dev-ai]

2 issues found across 5 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="helpers/grade.py">

<violation number="1" location="helpers/grade.py:40">
P3: `sys.stdout.reconfigure(encoding="utf-8")` runs unconditionally at import time and raises `AttributeError` if `sys.stdout` is not a live `TextIOWrapper` (e.g. stdout is `None` under `pythonw.exe`, or the module is imported while stdout is replaced by a non-filesystem stream such as `io.StringIO` under `contextlib.redirect_stdout`). These are standalone CLI scripts so normal console runs are unaffected, but guarding the call makes the fix robust to those environments instead of trading one crash (UnicodeEncodeError) for another (AttributeError). This applies identically to all four added calls in this batch.</violation>
</file>

<file name="helpers/render.py">

<violation number="1" location="helpers/render.py:34">
P3: `sys.stdout.reconfigure()` raises `AttributeError` when `sys.stdout` is not a `TextIOWrapper` (e.g., stdout redirected to a StringIO or a non-buffered wrapper in an embedded/hosted interpreter), and this call runs unconditionally at import time so it would abort the module before any fallback. In normal CLI usage stdout is a TextIOWrapper, so this is an edge case; guard it (or use the `errors`-safe reconfigure only when available) to keep the module importable in such environments.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

P3: sys.stdout.reconfigure(encoding="utf-8") runs unconditionally at import time and raises AttributeError if sys.stdout is not a live TextIOWrapper (e.g. stdout is None under pythonw.exe, or the module is imported while stdout is replaced by a non-filesystem stream such as io.StringIO under contextlib.redirect_stdout). These are standalone CLI scripts so normal console runs are unaffected, but guarding the call makes the fix robust to those environments instead of trading one crash (UnicodeEncodeError) for another (AttributeError). This applies identically to all four added calls in this batch.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At helpers/grade.py, line 40:

<comment>`sys.stdout.reconfigure(encoding="utf-8")` runs unconditionally at import time and raises `AttributeError` if `sys.stdout` is not a live `TextIOWrapper` (e.g. stdout is `None` under `pythonw.exe`, or the module is imported while stdout is replaced by a non-filesystem stream such as `io.StringIO` under `contextlib.redirect_stdout`). These are standalone CLI scripts so normal console runs are unaffected, but guarding the call makes the fix robust to those environments instead of trading one crash (UnicodeEncodeError) for another (AttributeError). This applies identically to all four added calls in this batch.</comment>

<file context>
@@ -34,6 +34,11 @@
+# Windows consoles default to a non-UTF-8 codepage (e.g. cp1252), which raises
+# UnicodeEncodeError on the arrows this module prints. Force UTF-8 stdout
+# unconditionally rather than relying on PYTHONIOENCODING being set.
+sys.stdout.reconfigure(encoding="utf-8")
+
 
</file context>

Suggested change

	sys.stdout.reconfigure(encoding="utf-8")
	if hasattr(sys.stdout, "reconfigure"):
	sys.stdout.reconfigure(encoding="utf-8")

[cubic-dev-ai]

P3: sys.stdout.reconfigure() raises AttributeError when sys.stdout is not a TextIOWrapper (e.g., stdout redirected to a StringIO or a non-buffered wrapper in an embedded/hosted interpreter), and this call runs unconditionally at import time so it would abort the module before any fallback. In normal CLI usage stdout is a TextIOWrapper, so this is an edge case; guard it (or use the errors-safe reconfigure only when available) to keep the module importable in such environments.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At helpers/render.py, line 34:

<comment>`sys.stdout.reconfigure()` raises `AttributeError` when `sys.stdout` is not a `TextIOWrapper` (e.g., stdout redirected to a StringIO or a non-buffered wrapper in an embedded/hosted interpreter), and this call runs unconditionally at import time so it would abort the module before any fallback. In normal CLI usage stdout is a TextIOWrapper, so this is an edge case; guard it (or use the `errors`-safe reconfigure only when available) to keep the module importable in such environments.</comment>

<file context>
@@ -28,6 +28,11 @@
+# Windows consoles default to a non-UTF-8 codepage (e.g. cp1252), which raises
+# UnicodeEncodeError on the arrows/em-dashes this module prints. Force UTF-8
+# stdout unconditionally rather than relying on PYTHONIOENCODING being set.
+sys.stdout.reconfigure(encoding="utf-8")
+
 try:
</file context>

Suggested change

	sys.stdout.reconfigure(encoding="utf-8")
	if hasattr(sys.stdout, "reconfigure"):
	sys.stdout.reconfigure(encoding="utf-8")