I've been conducting an in-depth evaluation of Murf.ai for a potential text-to-speech pipeline integration and have hit a consistent, puzzling roadblock during my technical validation phase. The audio generated in the web preview (using the studio editor) is of acceptable quality for our use case, but the exported WAV or MP3 file exhibits noticeable and unacceptable degradation. This isn't a subtle difference in "feel"—it's a clear reduction in fidelity.
My initial hypothesis centered on the export process applying an additional compression layer or a sample rate conversion. To isolate the variables, I've standardized my test conditions:
* **Source Text:** Identical for preview and export.
* **Voice & Settings:** "Justin" (English, US), all prosody and emphasis adjustments identical.
* **Playback Environment:** Local media player (VLC) with a flat EQ profile, compared against the in-browser preview via a loopback audio capture to rule out browser distortion.
* **Export Formats Tested:** High-quality WAV (16-bit, 44.1kHz) and 192 kbps MP3.
The exported files consistently present two issues:
1. A slight but perceptible high-frequency attenuation, making the voice sound marginally more "muffled."
2. In sections with complex audio (e.g., voice + embedded sound effect track), a faint artifacting or "phaser"-like effect not present in the preview.
My workflow for analysis involved generating a spectrogram comparison. The following is a conceptual representation of the commands I used for signal analysis (using `sox`):
```bash
# Generate a spectrogram for the preview capture (captured.wav) and the export (export.wav)
sox capture.wav -n spectrogram -o capture_spec.png
sox export.wav -n spectrogram -o export_spec.png
```
A visual comparison of the outputs shows a roll-off above ~12kHz in the export that is not present in the preview spectrogram.
This leads me to my core technical questions for the community:
* Is the Murf studio preview applying a non-defeatable "enhancement" or equalization that is not part of the actual render pipeline?
* Could there be an undisclosed, post-processing step during export that is optimized for filesize over fidelity, even on the "high quality" WAV setting?
* Has anyone else performed a similar signal analysis or found a workaround, such as using a different export method (API vs. dashboard) that yields bit-perfect results?
This is a critical issue for any application requiring broadcast or archival quality audio, and it significantly impacts the suitability of the platform for automated, API-driven workflows where the preview step is bypassed entirely. I'm keen to hear if others have deconstructed this pipeline or found a configuration that resolves the disparity.
API whisperer