Did the trim drop the audio?

Check the audio in an MP4

Choose a finished MP4 export to read its audio track and sample counts. Your file stays in this browser.

This reads the file’s track tables. Play the export to verify audible sound and sync.

What happens at 0.500 seconds

The first video packet beyond the cutoff arrived at decode timestamp 0.501406. The audio packets through the cutoff arrived later in the read order, even though their own timestamps were between 0.000000 and 0.490667.

Eligible audio packets before the stop

0

Eligible audio packets after the stop

24

Audio packets in the FFmpeg trim

24

These values come from FFmpeg and ffprobe 8.1.2 on this exact fixture. File and pipe reads gave the same order. The reproduction evaluates the early-stop rule against that packet order. See the fixture recipe and upstream discussion.

What the released KiteFFmpeg trim did

On Windows, we ran the published KiteFFmpeg JVM 0.5.1 remuxer on the test input, from 0 to 500,000 microseconds. The result had no audio track. Its 12 decoded picture frames matched the FFmpeg reference frame by frame. The reference kept 24 audio packets.

The maintainer’s fix is in the project’s source. Each timed stream gets its own stopping point, so the remuxer can still read audio packets that arrive after the first late video packet. The published JVM version we checked on November 10, 2026 predates that fix. Published package · Upstream fix

Try it on your trimmer

1. Stream-copy the downloaded input from 0 to 0.5 seconds with the tool you are testing. Keep video and audio selected.
2. Run the packet count below on your output and the reference file. The reference reports 12 video packets and 24 audio packets.
3. Play or decode your result to check the sound. If the audio count falls to zero or audio ends early, inspect stream selection and the read-stop condition before changing encoders or generating another clip.

ffprobe -v error -count_packets -show_entries stream=codec_type,nb_read_packets -of json "trim-audio-test-reference.mp4"

Packet count helps locate a missing track or a truncated read. Playback and a distinct cue help assess audibility and sync. For generated footage, keep the original delivery file so you can tell whether the audio was lost during generation or during editing.

Did the export keep the right audio track?

Two tracks can have the same duration and packet count. For a full stream copy, compare the ordered audio packet hashes to identify which source track was kept.

The example copies the second of two one-second tone tracks. Both tracks have 47 packets. Your reports stay in the browser and can be up to 10 MiB each.

Run this command on your source. Repeat with your export file and write to export-audio.json.

ffprobe -v error -select_streams a -show_streams -show_packets -show_entries stream=index,codec_type:stream_tags=title,language:packet=stream_index,data_hash -show_data_hash sha256 -of json -o source-audio.json "source.mkv"

Packet matches check copied payloads and their order. Trimming, encoding or different packet boundaries can change the hashes. Use playback to check timing and sound quality. See the two-tone fixture recipe.