> On Oct 11, 2022, at 1:45 AM, Erik Dobberkau <erik.dobber...@gmail.com> wrote: > >>> Is there a way to avoid having FFmpeg inject those additional silent >> packets while concatenating? >> >> Here is my FFmpeg information: […] >> > > Is your audio encoded using AAC? Your uncut console output would tell had > it not been omitted… therefore, please make sure to always provide the > complete console output. > > IIRC, AAC has packets of 1024 samples, and the concat (de)muxer/filter may > operate on packet level, not sample level, which would explain the silence > (missing samples to complete their number to the next integer multiple of > 1024). > > It’s only a guess though, and (one of) the developers should be able to > share some insight on what’s (not) happening.
Yes my audio is encoded using AAC. From what I see in ISOViewer, the first file has 91410 samples with a sample duration of 1024 (what we’d expect). Then it has 1 sample with a duration of 456. When I look at the concatenated file, I see 91410 samples with that same 1024 sample duration. Then I see 1 more sample with a duration of 461. I tried trimming this sample on my own before the concat, but even if I pass in the exact duration (91410 * 1024/<sample rate>) to the trim command, FFmpeg doesn’t actually remove that last sample. Any tips on this? I would attach the complete FFmpeg output, but it’s rather long…. > _______________________________________________ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
