soundtrack_shorter_than_spine: loop the music bed in Timeline

The soundtrack_shorter_than_spine warning means the music file you passed as soundtrack.url is shorter than audio.duration_seconds, so the bed stopped partway through the render. Set soundtrack.loop to true and the bed repeats until the spine ends. That is the whole fix; the rest of this page is what the other soundtrack fields do, so you do not trade one problem for another. Everything here comes from the Timeline 1.0 docs and its OpenAPI schema.

What does the soundtrack object accept?

A required url (a Sume-hosted HTTPS file) and four optional fields. Defaults matter: the bed sits at -16 dB under a spine unless you change it, and it stops dead at the end unless you add a fade.

Why did my render finish with a warning instead of failing?

The Timeline docs describe soft warnings, including padded or looped short sources, in the job's warnings[]. The render completed; the warning tells you the bed ran out. Read warnings[] on the result before you publish, because a silent last third of a video will not raise an error.

When is looping the wrong fix?

When the bed has a clear start and end, such as a 30-second track with an intro and a final hit. Looping repeats that arc. For a 30-second video, generate a 30-second track instead: the Music Router has no duration field, but Music 1.0 says to steer length in the prompt ("a 30-second track"). Loop only for ambient beds that are meant to repeat, and add fade_out_seconds so the last pass does not cut off.

What does a render with a looped bed look like?

Only the soundtrack block is shown; the rest of the Timeline body (audio, video[], output) is unchanged from the docs example.

{
  "soundtrack": {
    "url": "https://media.sume.com/artifacts/artf_demo/bed.mp3",
    "gain_db": -18,
    "loop": true,
    "fade_out_seconds": 3,
    "duck_db": 10
  }
}