A long podcast may exceed the current STT upload limit. Prepare bounded files locally, track their order and processing state, and assemble the returned text only after every intended part has been reviewed. IllyVoIP still receives individual audio uploads; this is not a native batch-transcription endpoint.

1. Inspect the source and plan the split
You need an IllyVoIP account permitted to use the relevant API, sufficient balance for paid operations and an API key. In the Portal, open Account settings → Developer tools and follow its verification prompts. Keep the key in your server’s secret configuration as ILLYVOIP_API_KEY, outside source control and shared documents. Read-only catalog and reporting requests are different from paid speech generation or SMS submission.
Work with a recording you are permitted to process. Use ffprobe to check duration, stream selection, channels and actual format. Record a hash of the original file and decide whether music, advertising or silence should remain. Keep a record of any deliberate exclusions.
Choose a conservative segment duration after measuring the output format and current upload limit. For example, 120 seconds of mono 16 kHz 16-bit PCM is roughly 3.84 MB before small container overhead. This is a planning estimate: measure each generated file before upload. Splitting also affects per-started-minute billing.
2. Create ordered audio segments
This example uses the first audio stream and writes a CSV segment list. Run it in a new private directory; retain the original input path. Review the channel decision as in the video-audio guide.
ffmpeg -n -i podcast.mp3 -map 0:a:0 -ac 1 -ar 16000 \
-c:a pcm_s16le -f segment -segment_time 120 \
-segment_list segments.csv part-%04d.wavSegment boundaries are processing boundaries, not sentence or speaker boundaries. A word crossing a cut can be lost or misrecognized. Listen around every join when reviewing the transcript. If you choose overlapping sections, retain that overlap explicitly and reconcile repeated words manually; do not silently concatenate duplicate phrases.
3. Freeze a manifest before paid requests
| Item | Meaning or action |
|---|---|
| sequence and filename | A unique, stable order for each local file. |
| source start/end | Offsets reported by segmentation, for review against the source; not word timestamps. |
| byte size and SHA-256 | Detect a changed or over-limit file before submission. |
| language/context | Use the current standalone catalog. |
| operation folder | One private request/response record for this exact file. |
| state and result | Prepared, attempting, saved, or review required; transcript filename after success. |
Verify that files cover the intended source interval in order and that each opens as audio. Do not assume a filename counter proves there is no missing segment. Review the number of requests and approximate billed duration before enabling the worker.
4. Submit and checkpoint one part at a time
Use the standalone speech_api context. Read the current language catalog, and for synthesis select an exact voice from the corresponding voice catalog. Do not assume that the Voice Agent’s available languages or another provider’s voice names apply to the standalone API.
Use the complete one-attempt STT client from the related Python guide. Before each submission, compare the file hash to the frozen manifest, check size, and create the operation folder atomically. Save the HTTP/API response before advancing the manifest state. Start sequentially; parallel processing makes uncertain outcomes harder to reconcile.
Preserve the exact input, local job identity and response before moving to the next step. A timeout or lost response is an uncertain outcome, not permission to submit the same paid operation again under a new name. Recover from a saved successful response when possible; otherwise reconcile the original attempt. API duplicate-charge protection does not replace your application’s operation history.
A restart should list saved results and review-required operations first. It may process untouched prepared items after review, but must not resubmit an item whose outcome is unknown. A file with a changed hash is a changed job that requires review, not an automatic retry.
5. Assemble and proofread in manifest order
Require a saved successful result for every included sequence. Write a new output containing each transcript in numeric manifest order. Keep source offsets as section annotations if useful, and make clear that those labels refer to audio chunks.
Listen at joins and check names, quotations and important numbers. Do not promise speaker diarization, automatic chapters or accurate word timestamps: the public response provides text, language and duration. Preserve the original recording for verification under your retention policy.
Recovery checklist
- One segment fails: keep all successful responses; inspect only that operation.
- A file is too large: revise the affected prepared segment and manifest before attempting it; do not change already-submitted inputs in place.
- Text repeats: inspect intentional overlap and sequence ordering.
- A passage is missing: compare offsets, segmentation boundaries and the original audio.
- Local transcript saving failed: reconstruct it from the saved response instead of buying another transcription.
Related guides and reference
FFmpeg segment muxer. IllyVoIP API reference. Reviewed October 11, 2026. Examples are instructional: local checks do not establish a completed paid request, live third-party integration or production PBX acceptance.