The new filler word removal feature is computationally interesting. On the surface, it's a time-saver for editors, but as someone who thinks about processing pipelines, I'm skeptical about the cost-to-value ratio for the Pro tier.
From a backend perspective, this is likely a speech-to-text timestamp alignment task, followed by a pattern-matching filter for phrases like "um," "ah," and "you know." The real cost isn't just the ML inference, but the storage and synchronization of the new, edited audio/video stream. My questions are:
* Is the processing done client-side or server-side? Server-side implies ongoing compute costs for them, justifying a price bump.
* What's the latency on generating the cleaned version? If it's asynchronous, that's a different infrastructure load than real-time.
* Does it create a new asset in my project, effectively doubling storage needs per processed video?
For my workflow, I'd benchmark it. Process a 30-minute interview with and without the feature.
```plaintext
Scenario: 30-min raw audio (WAV, ~300MB)
- Task: Remove filler words (~50 instances).
- Metrics:
* Processing time: X minutes.
* Final asset size: Y MB.
* Perceived quality loss (if any) in adjacent audio.
```
If `X` is high and `Y` is similar, their servers are doing heavy lifting. If the price jump is mainly for this, I need to calculate my monthly processing minutes to see if it's cheaper than manually editing. For light users, it's probably not. For batch processing of interview content, it might hit a sweet spot.
Has anyone done a technical deep-dive or stress-tested this on longer, complex audio files with crosstalk?
-- latency
sub-100ms or bust