42 voice lines and the 20-part concat cap: four joins for 4 cents

Sume timeline audio concat accepts 1 to 20 parts per job, so 42 separate voice lines need more than one join. Join them as 20, 20 and 2 in three jobs, then join those three results in a fourth job. That is four jobs at a flat $0.01, or $0.04. The final file must stay within the 1,800-second limit on produced audio.

The limits and the price are from Sume's timeline audio docs and public catalog, read on 2026-10-09.

The plan

Concat is sample-domain: it joins Sume-hosted audio into one gapless file with no re-synthesis and no silence at the seams. Each output is a durable media.sume.com file with its own URL, so it is a valid input to another concat. All parts must share a channel layout, or the job fails with audio_parts_channel_mismatch.

What the request looks like

Each job is a POST to /v1/timeline-1.0/audio with operation concat and a parts array. Each part has a url and may have source_in and duration. All URLs must be your workspace's media.sume.com audio; an off-host URL is rejected at admission, so import any external files first. Idempotency-Key is required, and the default mode is async, so you get a 202 and poll the job unless you ask for sync, which waits up to 30 seconds.

The result is kind timeline_audio with one audio_url, a duration_seconds, and segments that give each part's start offset. Keep the segments from your joins if you need to line up video shots to the lines later.

When you do not need the intermediate files

If the lines will only be used inside one video render, you do not need to join them at all. Timeline 1.0 accepts audio.parts with up to 20 slices in a render. For more than 20, you still need an earlier join to get under the cap. And if the lines come from one TTS request with sentence segmentation, you already have the continuous take as audio_url, so joining slices is unnecessary.

The reusable merged file is useful when the same narration is used in several renders, since you pay the join once.

• Same channel layout on every part.
• Keep the order explicit in the parts array; there is no sort.
• Use a distinct Idempotency-Key per join, such as join-a, join-b, join-c, join-final.

Checking the result

After the final join, compare the duration_seconds of the output with the sum of your parts. The two should match within the usual rounding of your sources. A shortfall means a part was trimmed by a source_in or duration you did not intend. The segments array in each join result shows where each input landed, which is the quickest way to find the part that changed.

At $0.01 a job the check costs nothing to repeat, so rerun a join with a new Idempotency-Key if you need to change one input.