MAI-Transcribe-2: speaker diarization fails on recordings over ~15 minutes, surfacing as HTTP 408 "RequestTimeout"

Labatt 5 Reputation points
2026-09-05T04:12:04.57+00:00

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.

Environment

  • Endpoint: https://eastus.api.cognitive.microsoft.com/speechtotext/transcriptions:transcribe?api-version=2025-10-15
  • Region: eastus (listed as supporting "Transcribe with mai-transcribe model")
  • Resource: Foundry resource for Speech in eastus (resource name and subscription id available privately on request)
  • Auth: Ocp-Apim-Subscription-Key
  • Client: Python requests 2.x with a streaming multipart body; connect timeout sized to the file, read timeout 1800 s
  • Audio: MP3, mono, ~128 kbit/s, from a Plaud recorder; also a 32 kbit/s 16 kHz re-encode of the same file

Request

POST .../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.

Results

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.

Error bodies

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.

What the documentation says, and where it disagrees

  • Quotas page — LLM speech and fast transcription: "Maximum audio length < 5 hours per file", "< 500 MB".
  • REST reference, audio parameter, api-version 2025-10-15: "shorter than 2 hours in audio duration and smaller than 250 MB".
  • MAI-Transcribe page: "less than 300 MB", no duration stated.
  • DetailedErrorCode enum: contains AudioLengthLimitExceeded but no timeout-shaped code.

A 15-minute, 14 MB file is inside every one of these limits.

Asks

  1. Is there a duration limit specific to diarization in enhanced mode? If so, please document it on the MAI-Transcribe page and return AudioLengthLimitExceeded (or a diarization-specific code) rather than a relayed 408/500/503.
  2. Please reconcile the four conflicting limit statements above.

Workaround in use

Transcribe with diarization disabled — which works at full length — and run speaker diarization locally on the returned word timings.

Azure Speech in Foundry Tools

2 answers

Sort by: Newest
  1. Labatt 5 Reputation points
    2026-09-08T01:44:53.28+00:00

    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?

    Was this answer helpful?


  2. Allan Solomon Mejia 7,915 Reputation points
    2026-09-06T16:33:42.4666667+00:00

    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:

    • 30-minute recording + diarization → fails
    • same 30-minute recording without diarization → succeeds
    • 73-minute recording without diarization → succeeds
    • 17.5 MB re-encoded recording + diarization → fails
    • 70.2 MB original recording without diarization → succeeds

    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:

    • There is an undocumented duration/processing limit for MAI-Transcribe-2 native diarization;
    • The 408/500/503 responses represent a known preview-service issue; and
    • The conflicting limits in the MAI, Fast Transcription, and REST documentation need to be reconciled.

    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.

    Was this answer helpful?


Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.