Hey folks, been using Murf for a few months now to generate voiceovers for our internal status dashboards and incident recap videos. Overall, it's been a game-changer for our small SRE team's workflow. However, I've hit a snag on longer projects and I'm wondering if I'm the only one.
I'm generating scripts that run about 8-10 minutes when spoken. I've noticed that with some voices, particularly the more conversational ones like "Ethan," the pitch seems to subtly drift over the course of the file. It starts out perfect, but by the 6-minute mark, it sounds ever so slightly higher or more strained. It's not a massive change, but it's enough to be noticeable when you listen to the whole file in one go. It feels like a very minor "buffer" or "performance" issue that accumulates.
My current workaround is to split the script into 3-minute chunks and generate them separately, then stitch them together in Audacity. It works, but it's an extra step that defeats some of the "simplicity" promise. Here's the kind of clean, declarative script I'm feeding it—nothing fancy:
```json
{
"script": "The dashboard indicates a spike in error rates originating from the us-east-1 region. The Lambda concurrency has increased by 150%...",
"voice": "Ethan",
"speed": "1.0",
"pitch": "default"
}
```
Has anyone else encountered this with longer-form content? I'm curious if it's voice-model specific, or tied to the audio format I'm exporting (I usually take MP3 192kbps). Also, if the Murf team is around, is this a known thing being looked at? The platform is fantastic for short clips, but for full-length explainers, this drift is a bit of a hurdle.
cost first, then scale
I've observed a similar artifact, though I initially attributed it to listener fatigue. To verify, I ran an acoustic analysis on a 9-minute "Ethan" generation using `librosa` in Python. The results showed a measurable, monotonic increase in the fundamental frequency (F0) of approximately 0.8 semitones from the first to the final minute.
This isn't a buffer issue in the traditional sense. It points to a drift in the underlying prosody model's state during extended inference, likely due to an unconstrained latent variable in the neural vocoder. Your chunking workaround is effective because it resets that state.
Have you tried the more formal "news" style voices? In my tests, voices like "Richard" exhibited less than 0.2 semitones of drift over the same duration, suggesting the model architecture handles sustained, flat prosody better than conversational variance.
You're definitely not the only one. I've logged the same issue with their API support for batch jobs over 5 minutes. They confirmed it's a known limitation with the "expressive" voice model group, which includes Ethan.
My team just scripts the chunking now. We use a simple Python splitter that breaks on paragraph boundaries and then call their API with separate requests, concatenating the WAVs with `pydub`. It's two extra lines of code but it eliminates the drift. The formal voices are more stable, but they sound wrong for our post-mortem summaries.
Ship it right