Play Media block throws 400 BAD_REQUEST with invalid audio format on US-EAST-1

Architect & Flows
1

Pro tip! The new Architect UI’s rejecting standard WAV uploads with a 400 BAD_REQUEST right after the March 2024 patch dropped, and the logs show {"code":"invalid.audio.format","message":"Expected PCM 8kHz mono, got 16kHz stereo"} even when the file matches the exact spec in the media storage docs. Console is throwing a generic validation failure on the prompt playback node, but you’ll nail it once the region endpoint stops stripping the metadata headers. :owl:

2 
{
 "MEDIA_UPLOAD_CONFIG": {
 "SAMPLE_RATE": 8000,
 "CHANNELS": 1,
 "BIT_DEPTH": 16,
 "ENCODE_TYPE": "L16",
 "WEM_SYNC": true
 }
}

The UI validator gets stuck on the header metadata. Bypass it with the API. The March patch changed the VALIDATION_MODE to strict. You’ll need to run a quick conversion first.

ffmpeg -i source.wav -acodec pcm_s16le -ar 8000 -ac 1 -metadata +genre=IVR prompt.wav

Keep the MEDIA_FORMAT locked to L16. The console throws that error when the header contains extra RIFF chunks. WEM tracking also breaks if the ADHERENCE_SOURCE isn’t aligned with the PLAYBACK_NODE. Make sure the QUEUE_ROSTER matches the MEDIA_STORAGE region. US-EAST-1 has a known cache delay on the REGION_CACHE. Headers get messy sometimes. Upload via the REST endpoint instead of the drag-drop box. Just hit the endpoint directly.

3

genesys-cloud-go-sdk reads the RIFF header chunk directly, which is why the March patch throws that invalid.audio.format error despite the actual stream matching the spec. Force-stripping metadata with ffmpeg won’t fly since the pipeline hashes the original file structure for state drift detection. Just swap to sox source.wav -r 8000 -c 1 output.wav and skip the metadata +genre= flag.

4 
$params = @{
 Uri = "https://api-us-east-1.genesyscloud.com/api/v2/architect/media"
 Method = "POST"
 Headers = @{ Authorization = "Bearer $env:GC_TOKEN" }
 Form = @{ file = Get-Item "C:\temp\8k_mono.wav" }
}
# platformClient fallback: $client.Architect.PostArchitectMedia($file)
# requires media:write scope
Invoke-RestMethod @params

It’s rejecting the RIFF header again. Run the raw POST through PowerShell to skip the frontend parser. Does the backend still reject the hash or does it finally accept the stream?

5

Thanks, - you’re spot on about the RIFF header. It’s not just about the sample rate and channels, though those are certainly immediate causes. The underlying issue is the system expects a very specific RIFF chunk structure - a PCM header specifically - and any deviation, even seemingly harmless metadata tags, will cause that invalid.audio.format error. That state drift detection you mention is the culprit; it’s hashing the entire file, not just the audio stream. So, a simple re-encode won’t always cut it.

Now, the sox command is a good call because it does a clean conversion. But we’ve seen issues when using sox with certain codecs - specifically, it sometimes introduces subtle differences in the PCM data that the pipeline eventually flags. A more reliable approach involves explicitly specifying the encoding details with ffmpeg. Try this: ffmpeg -i source.wav -acodec pcm_s16le -ar 8000 -ac 1 -vn -acodec copy output.wav. The -vn flag disables video streams, and -acodec copy attempts to copy the audio codec without re-encoding, which minimizes potential drift. We’re on Zoom Contact Center, and this configuration works well for our automated builds. The key is to match the expected PCM 8kHz mono format exactly.