Another day, another opaque "quality" gate from a vendor API. I've been integrating voice synthesis platforms for years, and Resemble AI's persistent rejection of what sounds like perfectly fine audio to human ears is a classic case of poor developer experience masked as a "feature."
Let's cut through the marketing. Their documentation mentions "high quality" and "clean audio" but is deliberately vague on the hard technical specifications. After wasting more time than I care to admit on trial and error, and a few pointed support tickets, here's the practical, unadvertised spec you actually need to meet to avoid the dreaded `400: Low quality audio` error.
**The Real Requirements (Inferred from Failures):**
* **Sample Rate:** 16kHz or 44.1kHz are safe bets. 8kHz will often be rejected. 48kHz sometimes works, but I've seen inconsistencies.
* **Bit Depth:** 16-bit PCM. Do not send 24-bit or 32-bit float thinking it's "higher quality." Their system seems to treat it as an invalid format.
* **Codec:** Uncompressed WAV (LPCM) is the only consistently reliable format. Their acceptance of MP3 is flaky at best, and AAC will almost certainly fail. Even some WAV headers they don't like.
* **Noise Floor:** This is the big subjective one. Their algorithm is hypersensitive. Any consistent background noise—AC hum, computer fans, distant traffic—will get your clip rejected. It's not about "studio quality," but about near-perfect silence in pauses.
* **Peak Amplitude:** You need to hit between -3 dB and -1 dB. Too quiet (e.g., -20 dB) is an instant failure. Clipping is obviously bad, but they're more lenient on the upper bound than the lower.
The most frustrating part is that you can have a clip that passes all these and still get rejected. Their quality check is a black box.
Here's the `ffmpeg` command chain I now use as a mandatory pre-processing step for **any** audio before sending it to Resemble's API, even if the source is "good." This has reduced failures by about 95%.
```bash
ffmpeg -i input_source.mp3
-af "lowpass=8000, highpass=80, afftdn=nf=-25, loudnorm=I=-2:LRA=7:TP=-1"
-ar 16000
-ac 1
-c:a pcm_s16le
-acodec pcm_s16le
-f wav
output_for_resemble.wav
```
This does: bandwidth limits (lowpass/highpass), aggressive noise reduction, loudness normalization to target -2 dB, downmixes to mono, and sets the sample rate and bit depth. It's a sledgehammer, but it's what their system seems to want.
My cynical take? This isn't purely about model performance. It's a cost and support optimization. By forcing you to pre-process heavily, they reduce the computational variance on their end and filter out casual users. It's cheaper for them. The advice to "use a professional microphone in a studio setting" for simple voice cloning is, frankly, overkill for many use cases and reeks of over-engineering.
Has anyone else reverse-engineered different thresholds? Or found a reliable way to use their API with slightly noisier, more "real-world" audio without building a full studio booth? I'm curious if the web uploader performs different checks than the API, because I suspect it does.
keep it simple
I appreciate you digging into this, because I've been banging my head against the same error. The bit depth point is something I ran into just last week, trying to send over 24-bit files from a field recorder, thinking more data would be better. It was a silent failure that took ages to trace back.
Your note about WAV headers is interesting and might be the key to some of my leftover issues. I've had files that meet all the obvious specs still get rejected. Do you think it's a specific header field that trips them up, like the audio format code or the chunk size? I'm wondering if re-encoding through something like Audacity, even to the same specs, creates a "cleaner" header their parser accepts.
Yeah, the WAV header thing can be a real silent killer. It's often not about the format code, but about having extra chunks or metadata that some parsers choke on. I've seen issues with `LIST` info chunks from certain DAWs.
When I get a rejection on a spec-compliant file, I run it through `ffmpeg` with a simple copy command. It often rewrites the header into a more "vanilla" structure without re-encoding the audio.
```bash
ffmpeg -i input.wav -c copy output.wav
```
Give that a shot. It's saved me a ton of time compared to opening things in Audacity.
Infrastructure as code is the only way