The audio extract length is meant for visualizing/grabbing sequences that can
run minutes long, but the control capped it and stepped in fiddly 0.10s
increments. Raise the range to effectively unlimited (24h; ffmpeg stops cleanly
at end-of-file if the source is shorter) and make the arrows step 1s — typing
still allows sub-second precision. Widen the field for the larger values.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
_on_extract_audio clamped the duration to (timeline_duration - cursor), so with
the playhead within the requested length of the end (or any under-reported
duration) a 30s request was silently truncated to whatever remained — the user
asked for 30s and got 3s with no indication why.
Drop the clamp: pass the requested length straight to ffmpeg, which stops
cleanly at end-of-file if the source is shorter. Then ffprobe the result and,
when it comes up short, say so ("Saved 3.0s — source ended before 30.0s
requested") instead of silently shrinking. When there's room, 30s now yields
exactly 30s.
Adds core.ffmpeg.probe_duration(). Verified end-to-end: a fitting request
returns the exact length; a genuine near-end request returns the available
audio (rc=0) and is reported as truncated.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A dedicated "♪ Extract audio" button on the transport row grabs an exact
length of audio (set via the adjacent length box, from the playhead) and opens
a Save As dialog. Output format follows the chosen extension — WAV (pcm_s16le),
MP3 (libmp3lame), FLAC, m4a/aac, ogg/opus — re-encoding as needed; unknown
extensions let ffmpeg pick from the container.
- core.ffmpeg.build_audio_clip_command(input, start, duration, out_path):
fast-seek + exact -t duration + -vn, codec by extension. Verified end-to-end
(wav/mp3/flac all land at exactly the requested duration).
- Timeline shows the audio area as a distinct teal dashed band spanning
[cursor, cursor+length], updated live as the playhead or length changes, so
you see exactly what will be extracted.
- Length + last save dir persist in QSettings; button enabled once a file loads.
Tests: 3 core (codec-by-extension, exact length, case-insensitive) + 2 GUI
(controls exist, band tracks cursor/length).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Two issues with the per-subprofile (subcategory) export buttons:
1. Visibility was decided by a fuzzy `f.endswith("_" + suffix)` match against
the hidden-subcats set. A ghost "_blowjob" (empty-base leftover from the
trailing-slash folder bug) or an unrelated "mp4_no_clap" would match and
hide the wrong button — so enabling a subcategory in the Sub menu never
revealed its export button. Match the exact "<base>_<suffix>" folder name
instead (same name the menu shows and _hidden_subcats stores).
2. The buttons were crammed into the transport row after Export. Move them to
their own row with stretches on both ends so the (often many) "▸ name"
buttons stay centered and out of the transport controls.
Also cleared the polluted hidden_subcats/POV_Front set in the user's QSettings
(ghost "_*" names + a hide-all'd set of real "mp4_*"), so every subcategory is
visible again. Regression test added for the exact-match predicate.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A folder ending in "/" made os.path.basename() return "", so subprofile
folders/labels became "_blowjob" instead of "mp4_blowjob" — cluttering the
subcategory menu and breaking the marker↔category match. rstrip the trailing
separator in _tab_export_folder and the three basename(_txt_folder) sites.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Ethanfel
