| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Audio-only recordings were written as AAC in an MP4/.m4a container. The stop path SIGINTs ffmpeg, and if the MP4 muxer doesn't write its moov trailer before exit, the file has no moov atom and won't decode. ffmpeg and AssemblyAI both reject it. Three recordings were lost that way and had to be rebuilt with untrunc. The video path already avoids this by using Matroska, which needs no finalize pass.
I switched the audio-only path to FLAC. FLAC frames are self-contained, so an abruptly stopped recording still decodes, with no trailer to miss at close. It's also lossless, dropping the 64k AAC encode that degraded speech before transcription. AssemblyAI recommends a lossless source and accepts FLAC directly. The transcription path passes audio files through untouched.
|
| |
|
|
|
|
|
|
|
|
| |
Add pre-recording validation that catches stale or drifted system audio
devices before they cause silent recordings. When the default audio
output changes (Bluetooth reconnect, device switch) between setup and
recording, the monitor device is auto-updated. Warns if no audio is
currently playing through the monitored sink.
Co-Authored-By: Craig Jennings <c@cjennings.net>
|
|
|
These tests verify the syntax and flags of shell commands generated for
video/audio recording. They catch issues like:
- Invalid wf-recorder flags (e.g., --no-audio doesn't exist)
- Wrong encoder names (h264 vs libx264)
- Incorrect stdout output syntax (-o - vs -f /dev/stdout)
- Missing required flags (-y for auto-confirm)
18 new tests covering Wayland, X11, and audio recording command structure.
|
