Facebook Reels audio spec: AAC-LC, stereo, 48 kHz, 128 kbps+

Facebook's Reels API asks for AAC Low Complexity audio, stereo, 48 kHz, at 128 kbps or more. Sume can show you the codec, channel count and sample rate of any clip, and its trim keeps audio as AAC, but it cannot set the profile or bitrate. So the workable plan is: produce the clip, probe it, and accept or reject on the three fields that the probe does report.

Audio rows from the page

How to read the audio facts

POST /v1/video-inspect with frames: false is unbilled and returns the probe. Check has_audio first; a silent clip has no audio fields worth reading, and a Reel with no audio track is a different decision from one with the wrong sample rate.

def audio_problems(p):
    if not p.get("has_audio"):
        return ["no audio track"]
    out = []
    if p.get("audio_channels") != 2:
        out.append("not stereo")
    if p.get("audio_sample_rate") != 48000:
        out.append("not 48 kHz")
    if p.get("audio_codec") != "aac":
        out.append("not aac")
    return out

print(audio_problems({"has_audio": True, "audio_channels": 2,
                      "audio_sample_rate": 48000, "audio_codec": "aac"}))

What you can change

In video trim, audio: "keep" (the default) remuxes the kept audio as AAC in exact mode, and audio: "drop" removes it. For a new audio bed, build the audio with audio detach (sample_rate 16000, 44100 or 48000; channels source or mono) and mix it in Timeline 1.0 as the audio spine or soundtrack.

A practical order

Probe the finished MP4, not the inputs, because trimming and rendering can change the audio track. If the probe reports one channel or a rate other than 48000, decide whether that is acceptable for the post: the page lists stereo and 48 kHz as the specification, and a Reel that only misses the recommendation may still publish. Log the probe next to the job id so a later complaint about audio quality can be traced to a specific render.

Limits

The only way Sume offers to hit 128 kbps or the LC profile is whatever its encoder produces by default, which the docs do not state. If you need a guaranteed profile or bitrate, re-encode with your own tool after Sume and keep Sume for the editorial steps. The API page we read gives these as specifications, not as a list of rejection causes, so a file that misses one may still publish.