mirror of
https://github.com/digitalsamba/claude-code-video-toolkit.git
synced 2026-09-18 19:41:13 +08:00
Conal Mullan
c05a0cb7e6
* Added 60dB integration
* FIX: make 60db TTS synthesize transport work against the live API
The original integration coded to 60db's documented /tts-synthesize contract
(single JSON object with `audio_base64` in the requested container format).
In production the endpoint instead streams newline-delimited JSON of raw
16-bit mono PCM (Content-Type: application/x-ndjson) with a trailing
`{metadata}` line, so the default voiceover path failed with "Invalid JSON
response".
Changes (tools/sixtydb_tts.py):
- Rewrite _synthesize_rest to consume the NDJSON PCM stream, while still
accepting the documented single-JSON shape if 60db ships it.
- Add _finalize_audio: sniff bytes for an audio container (mp3/wav/ogg/flac)
and write/transcode as-is, else wrap raw PCM as WAV and transcode to the
requested --output-format via ffmpeg.
- Add _derive_pcm_sample_rate: infer the rate from byte-count and the
metadata audio_sec (snap to nearest standard rate) instead of hardcoding.
- Surface 60db metadata warnings; route _synthesize_stream through the same
PCM-aware finalizer and flag that /tts-stream currently 500s upstream.
Verified live: sixtydb_tts.py and `voiceover.py --provider 60db --scene-dir`
both produce valid 48kHz MP3s for English and Hindi.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* FIX: apply pacing QC (wpm/--max-wpm) to the 60db provider path
Rebase integration: pacing QC landed on main after this branch was cut;
elevenlabs and qwen3 paths report wpm/pacing and honor --max-wpm, but the
60db path bypassed it. Wire _apply_pacing_qc into generate_single_audio_60db
and pass max_wpm at both call sites.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MKbS3m7TXrfYjE7gDVEpnV
---------
Co-authored-by: manishEMS47 <manish.prasad@engineermaster.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>