Answers.Body: <pre><code>ffmpeg -i test.mp4 -ss 0 -t 5 test-1.mp4
  ffmpeg -i test.mp4 -ss 5 -t 5 test-2.mp4
  </code></pre>
  
  <p>This is the root of evil. You almost never can split your audio/video with very high precise. Reasons for it:</p>
  
  <ol>
  <li>Non-integer FPS in video. You can't split non-integer number of frames, so if you use 29.997 fps, you can't get 149.985 frames in file.</li>
  <li>Audio codecs compress audio samples in blocks of samples, for example, in 1024 samples per second. So, if you split your sound in 5 second and sound has samplerate 44100Hz, you can only get 44100*5/1024=215.332 frames, this is too not integer. Actually, here you get small drop. Some codecs always add some silent frames at end, mp3 do in that way. Only one exception I know: pcm (any kind), this "codec" can save any count of frame, with no rough.</li>
  </ol>
  
  <p>So, in conclusion, if you want split and concatenate files without loss:</p>
  
  <ol>
  <li>use integer count for fps</li>
  <li>use codecs what can encode any count of samples without rough or padding.</li>
  </ol>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-02-14T05:27:50.383Z
Answers.Text: could you explain how to use integer count for fps for #1. Also Michal - how did you solve your problem
Answers.UserDisplayName: Garuuk
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-30T17:48:38.617Z
Answers.LastActivityDate: 2017-08-30T17:48:38.617Z
Answers.UserDisplayName: bukkojot
Answers.Body: <p>The problem you're describing with blanks between each segment is due to priming samples. This can be removed with the inpoint directive. However, for it to be completely seamless, there's a bit more to do.</p>
  <p>To concat seamlessly with no gaps, you can do the following:</p>
  <ol>
  <li>Calculate the AAC frame length based on the sample rate, e.g. 1024/44100 = 0.02321995 for 44.1KHz.</li>
  <li>Encode an extra 2 AAC frames at the beginning and end of each segment.</li>
  <li>Account for the 2 silent padding frames that ffmpeg always adds internally.</li>
  <li>Assign inpoint and outpoint directives in the concat txt file so that only the &quot;good&quot; content is used when creating the output file.</li>
  </ol>
  <p>The 2 extra beginning frames are required because each AAC frame is dependent on up to 2 frames before it. So to encode the first frame correctly, it needs that context. The 2 extra frames at the end are required because ffmpeg tapers the audio at the end to avoid a sudden pop. By adding 2 extra frames, we shift the taper so it doesn't affect our actual content. These extra frames are then removed with inpoint and outpoint to avoid repeated content.</p>
  <p>Using this method, it's important that all segments have a length that's an exact multiple of an AAC frame duration. If they don't, you will see unpredictable artifacts at segment boundaries.</p>
  <p>I recently released a repo that demonstrates this further with actual code: <a href="https://github.com/wistia/seamless-aac-split-and-stitch-demo" rel="nofollow noreferrer">https://github.com/wistia/seamless-aac-split-and-stitch-demo</a>.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-03-09T16:20:00.947Z
Answers.LastActivityDate: 2024-03-10T21:21:00.000Z
Answers.LastEditDate: 2024-03-10T21:21:00.000Z
Answers.UserDisplayName: MaxPower15
Body: <p>I am trying to use FFMPEG (v.3.3.3) concat demuxer and as the file is stitched the audio drops at concat points. As I have files of same codecs, bitrates and so on - it doesn't make much sense to transcode again, so I really want to make concat demuxer to work. </p>
  
  <p>I've had this problem with h.264 and aac. Here is how to recreate so you can see what I am talking about.</p>
  
  <ol>
  <li><p>Create test file with bars and tone (10s)</p>
  
  <p><code>ffmpeg -f lavfi -i "sine=frequency=1000:sample_rate=48000:duration=10" -f lavfi -i smptehdbars=size=1920x1080 -t 10 test.mp4</code></p></li>
  <li><p>Split the file into two using seeking</p>
  
  <p><code>ffmpeg -i test.mp4 -ss 0 -t 5 test-1.mp4</code></p>
  
  <p><code>ffmpeg -i test.mp4 -ss 5 -t 5 test-2.mp4</code></p></li>
  <li><p>Join the files together using concat demuxer</p>
  
  <p><code>ffmpeg -f concat -safe 0 -i &lt;(for f in ./test-*.mp4; do echo "file '$PWD/$f'"; done) -c copy testconcat.mp4</code></p></li>
  </ol>
  
  <p>This creates a file with clearly audible audio drop at 5s mark. To picture this here I've created two spectrograms by extracting audio.</p>
  
  <ol>
  <li><p>Extract audio</p>
  
  <p><code>ffmpeg -i test.mp4 test.wav</code></p>
  
  <p><code>ffmpeg -i testconcat.mp4 testconcat.wav</code></p></li>
  <li><p>Create spectrograms</p>
  
  <p><code>sox test.wav -n spectrogram -Y 130 -c "Input file" -o test.png</code></p>
  
  <p><code>sox testconcat.wav -n spectrogram -Y 130 -c "Concat file" -o testconcat.png</code></p></li>
  </ol>
  
  <p>And here is the result:</p>
  
  <p><a href="https://i.sstatic.net/U10Rl.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/U10Rl.png" alt="Input File"></a></p>
  
  <p><a href="https://i.sstatic.net/1PsSQ.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/1PsSQ.png" alt="Concat File"></a></p>
  
  <p>So my questions are: </p>
  
  <ol>
  <li>Can concat demuxer be used in such a way to avoid the described problem?</li>
  <li>Or what would you see as a solution (beyond full re-transcode)?</li>
  </ol>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-08-28T10:30:26.280Z
Comments.Text: Transcode the audio of your inputs to PCM and save as MOV. Concat those.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-08-28T15:53:02.697Z
Comments.Text: @Mulvya - I know it's brief, but you could make a good answer from that comment.
Comments.UserDisplayName: Dr Mayhem
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-08-30T17:35:47.517Z
Comments.Text: MOV and MP4 almost same container
Comments.UserDisplayName: bukkojot
Tags: <ffmpeg><audio>
Title: FFMPEG demux concat dropping audio at stitch points
UserDisplayName: Michal
ThreadText: # FFMPEG demux concat dropping audio at stitch points
  
  (Asked by: username_0 on 2017-08-28)
  
  I am trying to use FFMPEG (v.3.3.3) concat demuxer and as the file is stitched the audio drops at concat points. As I have files of same codecs, bitrates and so on - it doesn't make much sense to transcode again, so I really want to make concat demuxer to work.
  
  I've had this problem with h.264 and aac. Here is how to recreate so you can see what I am talking about.
  
  1. Create test file with bars and tone (10s)
  
     `ffmpeg -f lavfi -i "sine=frequency=1000:sample_rate=48000:duration=10" -f lavfi -i smptehdbars=size=1920x1080 -t 10 test.mp4`
  2. Split the file into two using seeking
  
     `ffmpeg -i test.mp4 -ss 0 -t 5 test-1.mp4`
  
     `ffmpeg -i test.mp4 -ss 5 -t 5 test-2.mp4`
  3. Join the files together using concat demuxer
  
     `ffmpeg -f concat -safe 0 -i <(for f in ./test-*.mp4; do echo "file '$PWD/$f'"; done) -c copy testconcat.mp4`
  
  This creates a file with clearly audible audio drop at 5s mark. To picture this here I've created two spectrograms by extracting audio.
  
  1. Extract audio
  
     `ffmpeg -i test.mp4 test.wav`
  
     `ffmpeg -i testconcat.mp4 testconcat.wav`
  2. Create spectrograms
  
     `sox test.wav -n spectrogram -Y 130 -c "Input file" -o test.png`
  
     `sox testconcat.wav -n spectrogram -Y 130 -c "Concat file" -o testconcat.png`
  
  And here is the result:
  
  [![Input File](https://i.sstatic.net/U10Rl.png)](https://i.sstatic.net/U10Rl.png)
  
  [![Concat File](https://i.sstatic.net/1PsSQ.png)](https://i.sstatic.net/1PsSQ.png)
  
  So my questions are:
  
  1. Can concat demuxer be used in such a way to avoid the described problem?
  2. Or what would you see as a solution (beyond full re-transcode)?
  
  **Tags:** ffmpeg, audio
  
  > **Comments:**
  > **username_1**: Transcode the audio of your inputs to PCM and save as MOV. Concat those.  
  > **username_2**: @Mulvya - I know it's brief, but you could make a good answer from that comment.  
  > **username_3**: MOV and MP4 almost same container  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2017-08-30. Score: 0 | Accepted answer
  
  ```
  ffmpeg -i test.mp4 -ss 0 -t 5 test-1.mp4
  ffmpeg -i test.mp4 -ss 5 -t 5 test-2.mp4
  
  ```
  
  This is the root of evil. You almost never can split your audio/video with very high precise. Reasons for it:
  
  1. Non-integer FPS in video. You can't split non-integer number of frames, so if you use 29.997 fps, you can't get 149.985 frames in file.
  2. Audio codecs compress audio samples in blocks of samples, for example, in 1024 samples per second. So, if you split your sound in 5 second and sound has samplerate 44100Hz, you can only get 44100\*5/1024=215.332 frames, this is too not integer. Actually, here you get small drop. Some codecs always add some silent frames at end, mp3 do in that way. Only one exception I know: pcm (any kind), this "codec" can save any count of frame, with no rough.
  
  So, in conclusion, if you want split and concatenate files without loss:
  
  1. use integer count for fps
  2. use codecs what can encode any count of samples without rough or padding.
  
  > **Comments:**
  > **username_4**: could you explain how to use integer count for fps for #1. Also username_0 - how did you solve your problem  
  
  ---
  
  ### Answer by username_5 on 2024-03-09. Score: 0
  
  The problem you're describing with blanks between each segment is due to priming samples. This can be removed with the inpoint directive. However, for it to be completely seamless, there's a bit more to do.
  
  To concat seamlessly with no gaps, you can do the following:
  
  1. Calculate the AAC frame length based on the sample rate, e.g. 1024/44100 = 0.02321995 for 44.1KHz.
  2. Encode an extra 2 AAC frames at the beginning and end of each segment.
  3. Account for the 2 silent padding frames that ffmpeg always adds internally.
  4. Assign inpoint and outpoint directives in the concat txt file so that only the "good" content is used when creating the output file.
  
  The 2 extra beginning frames are required because each AAC frame is dependent on up to 2 frames before it. So to encode the first frame correctly, it needs that context. The 2 extra frames at the end are required because ffmpeg tapers the audio at the end to avoid a sudden pop. By adding 2 extra frames, we shift the taper so it doesn't affect our actual content. These extra frames are then removed with inpoint and outpoint to avoid repeated content.
  
  Using this method, it's important that all segments have a length that's an exact multiple of an AAC frame duration. If they don't, you will see unpredictable artifacts at segment boundaries.
  
  I recently released a repo that demonstrates this further with actual code: <https://github.com/wistia/seamless-aac-split-and-stitch-demo>.
  
  
  ---
  
  