Avatar package soundtrack failed: what soundtrack_audio_* means

When your own soundtrack file does not make it into an Avatar Video package, the video is not lost. The package soft-fails: video_url stays the furthest successful file (captioned if captions finished, otherwise the clean talking head), and package.soundtrack.status reads failed with a typed public_reason. For a bring-your-own audio_url, the reasons are soundtrack_audio_url_blocked, soundtrack_audio_too_large, soundtrack_audio_not_audio and soundtrack_audio_download_failed.

Where do I read the reason?

On the finished avatar video, package has three parts: captions, soundtrack and mux. Each has a status of skipped, pending, ready or failed, and a failed one carries public_reason. While the soundtrack is pending, the audio_url you sent is echoed back so you can confirm what was requested. After a successful prep it becomes the mirrored copy Sume stores.

When the soundtrack could not be prepared, package.mux usually fails too, often with soundtrack_unavailable, because there is nothing to duck under the voice. Read the soundtrack block first; the mux code is the consequence.

What does each soundtrack_audio_* code mean?

Sume does not hand your URL to a generic downloader. The worker fetches it through a public-media fetch that resolves the host, requires every address to be public, pins the connection to those addresses and checks every redirect hop. The codes below come from that path.

Which content types are accepted?

A response typed audio/ or video/ passes, and so does an empty type or application/octet-stream. Anything else, such as text/html, is refused as soundtrack_audio_not_audio. That second case is the usual cause: a share link or sign-in page returns an HTML page with a 200 status, and the player in your browser hides the problem.

The accepted file is re-hosted on Sume's media domain and mixed at the package volume, which is 0.15 unless you set another value between 0.05 and 0.4.

Should I retry or fix the URL?

Three of the four codes are terminal: the same URL will fail the same way, so resubmitting unchanged only repeats the work. Fix the URL first. The download code is the one the worker itself retries when the host answered with a transient status, so it only reaches you after that.

If you would rather not host a file at all, ask for a generated bed with soundtrack.prompt instead of audio_url. Send exactly one of the two.

• Open the URL in a private window: if you are asked to sign in, so is Sume.
• Check the response with curl -sIL <url> and read the final content-type.
• Avoid links that redirect to an internal or http host.
• Keep the file short enough for the video it sits under.