MAI-Transcribe-2 diarization returns 503 on audio longer than 32 minutes

Question

MAI-Transcribe-2 diarization returns 503 on audio longer than 32 minutes

Adrian Acurero 0

I am using MAI-Transcribe-2 through the Azure Speech REST API. Transcription works on the full recording, but native speaker diarization hits a repeatable cutoff between 31:20 and 33:15.

Setup:

Azure AI Foundry resource (AIServices), S0
East US
API version 2025-10-15
POST /speechtotext/transcriptions:transcribe
enhancedMode.enabled: true
diarization.enabled: true

I ran these tests from the same Colab runtime and Azure resource:

| Audio length | Result |

| --- | --- |

| 90 seconds | Success, 2 speakers |

| 600 seconds | Success, 4 speakers |

| 1,800 seconds | Success, 5 speakers |

| 1,860 seconds | Success, 5 speakers |

| 1,880 seconds (31:20) | Success, 5 speakers |

| 1,995 seconds (33:15) | HTTP 503 |

| 2,095 seconds | HTTP 503 |

| 2,100 seconds | HTTP 503 |

| 2,864.576 seconds | HTTP 503 |

Every failed request returns the same response:


MAI service returned an error: ServiceUnavailable - {"error":{"code":"diarization_unavailable","message":"Speaker diarization service is unavailable: Diarization service returned error code 400"}}

I first suspected a file-size limit. The 2,100-second WAV was 67,201,128 bytes, so I encoded the same audio as a 16,801,389-byte MP3 and tried again. It still failed with the same response.

I also repeated the request with both supported endpoint forms:

https://eastus.api.cognitive.microsoft.com/
https://<resource>.cognitiveservices.azure.com/

The result did not change. The credentials work, short native-diarization requests return speaker labels, and the full 2,864.576-second recording transcribes when I turn native diarization off. The full file also completes when I use MAI for transcription and Community-1 for diarization afterward.

This looks like a duration limit or a preview-service bug rather than an authentication, encoding, or endpoint problem.

Request definition:


{

  "enhancedMode": {

    "enabled": true,

    "model": "MAI-Transcribe-2",

    "modelOptions": {

      "timestamps": "word",

      "transcribeStyle": "verbatim"

    }

  },

  "diarization": {

    "enabled": true

  }

}

Could someone confirm:

Is there a duration limit for MAI-Transcribe-2 native diarization in the East US public preview?
If chunking is the supported workaround, how should speaker identities be matched across chunks?
Should an over-limit request return a 4xx validation error instead of 503?
Would another region, API version, or preview enrollment support longer files?

0 comments

1 answer

Your answer

Answer 1

Hello @Adrian Acurero

Thanks for providing the detailed test matrix. Based on your results, this does not appear to be a general audio file-size, authentication, or endpoint issue.

Your testing isolates the problem quite well:

MAI-Transcribe-2 successfully transcribes the complete 2,864-second recording when diarization is disabled.
Native diarization succeeds through 1,880 seconds (31:20).
It consistently fails at 1,995 seconds (33:15) and above.
Re-encoding the same audio from WAV (~67 MB) to MP3 (~17 MB) doesn't change the behavior.
The returned error specifically originates from the diarization component: diarization_unavailable.

Microsoft’s published Azure Speech quotas don't document a ~32-minute limit. In fact, the documented maximum audio length for transcription with diarization is substantially higher (up to 240 minutes in the applicable Speech scenarios).

MAI-Transcribe-2 was released in public preview and specifically adds native speaker diarization and word-level timestamps. Given the repeatable boundary you've demonstrated, treat this as a likely preview-service limitation or defect in the MAI-Transcribe-2 native diarization path, rather than assume 32 minutes is an intentional supported limit.

Regarding your questions:

1. Is there a duration limit?

I can't find a Microsoft-published MAI-Transcribe-2-specific ~32-minute diarization limit. Your results strongly suggest an implementation limit or issue, but Microsoft would need to confirm this internally.

2. Is chunking a suitable workaround?

Yes, as a temporary workaround, but speaker IDs generated independently for each chunk shouldn't be assumed to represent the same speaker across chunks. If you need consistent speaker identity across the full recording, your existing workaround, MAI-Transcribe-2 for transcription followed by a separate diarization process, may be safer than independently diarizing chunks.

3. Should this return 4xx rather than 503?

If there is an intentional documented duration constraint, I would expect the request to be rejected as an invalid/unsupported request rather than surface an internal diarization 400 as an outer 503 ServiceUnavailable. The current response further suggests the failure is occurring downstream in the diarization service, not during request validation.

4. Would another region/API version help?

I don't recommend changing API versions or regions as a definitive fix unless Microsoft confirms a regional deployment difference. Your request is already using the documented 2025-10-15 Speech API, and the same behavior across both endpoint forms makes the endpoint hostname unlikely to be the cause.

At this stage, I'd recommend opening an Azure support case and including the successful 1,880-second and failing 1,995-second requests, timestamps, region, resource ID, and request/correlation IDs. Ask support specifically to confirm whether there is an undocumented MAI-Transcribe-2 native diarization duration limit in East US or whether this should be investigated as a preview-service defect.

Your reproducible ~31–33 minute boundary should give the engineering team a very useful starting point.

References:

MAI-Transcribe-2 model information

Azure Speech quotas and limits

Fast transcription API and diarization

Help make this community better for everyone: if this answer 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.