An Azure service that integrates speech processing into apps and services.
Thanks - I'm new to Azure. I specifically came to try the new transcription engine. I believe Azure support has a cost associated with it?
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Calling the fast transcription endpoint with enhancedMode.model = "MAI-Transcribe-2" and diarization.enabled = true fails for recordings longer than roughly 15 minutes. The same recordings transcribe successfully with diarization disabled — including a 73-minute, 70 MB file in a single request. The failure is therefore in the diarization component, not in upload size, duration, or transcription.
The errors returned do not describe this. They are a relayed RequestTimeout / Timeout(HTTP 408) that reads like a network problem, an HTTP 500, and an HTTP 503 wrapping "Diarization service returned error code 400". None of these codes appear in the documentedDetailedErrorCode` enum for this API version, and no documented limit predicts the failure: every published limit (5 h / 500 MB on the quotas page,
2 h / 250 MB in the REST reference, 300 MB on the MAI page) places these files in range.
https://eastus.api.cognitive.microsoft.com/speechtotext/transcriptions:transcribe?api-version=2025-10-15eastus (listed as supporting "Transcribe with mai-transcribe model")eastus (resource name and subscription id available privately on request)Ocp-Apim-Subscription-Keyrequests 2.x with a streaming multipart body; connect timeout sized to the file, read timeout 1800 sPOST .../speechtotext/transcriptions:transcribe?api-version=2025-10-15
Content-Type: multipart/form-data
audio = <file>
definition = {
"enhancedMode": {
"enabled": true,
"model": "MAI-Transcribe-2",
"modelOptions": { "timestamps": "word", "transcribeStyle": "clean" }
},
"diarization": { "enabled": true }
}
The failing and succeeding requests differ only in the presence of the diarization object. No phraseList or locales were sent in the runs below.
All runs on 2026-09-04/05 (UTC), same resource, same region. "Upload" is the time for the request body to finish sending; the error arrived immediately after in every case.
#audiodurationsizediarizationuploadresult1clip25 s0.4 MBon1 s200 OK — 2 speakers2first 15 min of recording15 min14.4 MBon130 s408 ×3 (see body A)3first 30 min of recording30 min28.8 MBon86 s503 ×3 (see body B)4full recording, re-encoded73 min17.5 MBon132 s408, then 500 (body C), then 503 (body B)5first 30 min of recording30 min28.8 MBoff33 s200 OK — 85 segments6full recording, original73 min70.2 MBoff141 s200 OK — 193 segmentsRun 4 (17.5 MB) failing while run 6 (70.2 MB) succeeds rules out file size. Runs 5 and 6 succeeding rules out duration and transcription. Only the diarization flag separates the failing runs from the succeeding ones.
A — HTTP 408 (runs 2 and 4, first attempt):
MAI service returned an error: RequestTimeout - { "error": { "code": "Timeout", "message": "The operation was timeout." } }
B — HTTP 503 (run 3 all attempts; run 4 third attempt):
MAI service returned an error: ServiceUnavailable - {"error":{"code":"diarization_unavailable","message":"Speaker diarization service is unavailable: Diarization service returned error code 400"}}
C — HTTP 500 (run 4, second attempt) — includes what looks like a trace id:
MAI service returned an error: InternalServerError - {"detail":"'d582ccb307fe4e5c93857111650d7224'"}
The bodies are prose wrapping a JSON object, not the documented JSON error shape, and the wrapper "MAI service returned an error" suggests these are relayed from the MAI backend rather than raised by the Speech front end.
audio parameter, api-version 2025-10-15: "shorter than 2 hours in audio duration and smaller than 250 MB".DetailedErrorCode enum: contains AudioLengthLimitExceeded but no timeout-shaped code.A 15-minute, 14 MB file is inside every one of these limits.
AudioLengthLimitExceeded (or a diarization-specific code) rather than a relayed 408/500/503.Transcribe with diarization disabled — which works at full length — and run speaker diarization locally on the returned word timings.
An Azure service that integrates speech processing into apps and services.
Thanks - I'm new to Azure. I specifically came to try the new transcription engine. I believe Azure support has a cost associated with it?
Hello @Labatt
Thanks for the detailed reproduction. Based on the results you posted, I don't think additional client-side timeout or file-size troubleshooting will explain this.
Speaker diarization is a supported MAI-Transcribe-2 capability, enabled with: diarization.enabled = true
The current MAI-Transcribe documentation also specifies an input file size of less than 300 MB, but I cannot find a published MAI-Transcribe-2 diarization-specific duration limit around 15 minutes.
Your A/B tests are particularly useful here:
That makes the general audio-duration limit, upload size, and transcription itself unlikely explanations. The 503 diarization_unavailable response containing “Diarization service returned error code 400” also points toward the downstream diarization component rather than the Speech request upload.
Microsoft also describes MAI-Transcribe-2 as supporting diarization for multi-party/long-form scenarios, and the model is currently in public preview.
At this point, I recommend opening an Azure Support request for Azure Speech in Foundry Tools and asking them to escalate it to the MAI-Transcribe/Speech engineering team.
Include your existing test matrix, region (eastus), API version (2025-10-15), resource ID, UTC timestamps for the failed requests, and especially the trace/detail ID from the HTTP 500 response: d582ccb307fe4e5c93857111650d7224
Specifically ask Microsoft engineering to confirm whether:
I don't recommend further re-encoding or increasing the HTTP client timeout at this stage. Your results already show that substantially larger/longer audio succeeds when diarization.enabled is removed, and the service returns failures after upload.
Your current workaround, which is performing the MAI transcription without native diarization and applying diarization separately, is reasonable until Microsoft confirms the backend behavior.
References:
MAI-Transcribe-2 documentation - Microsoft Learn
MAI-Transcribe-2 model catalog - Microsoft Foundry
MAI-Transcribe-2 announcement - Microsoft Azure AI Foundry Blog
Help make this community better for everyone: if this answer assisted you/resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution.