Answers.Body: <p>Yes, those warnings are safe to ignore. They're caused by the input streams not agreeing on the timestamps - which they don't because you're concatenating, and thus each file starts out with zero and increases from there.</p>
  <p>As far as I've determined, this warning <em>always</em> happens when concatenating. The output file should have corrected timestamps, and that can easily be checked by re-encoding it or playing it with mplayer. It works for my case, mp3 files, but you may want to double-check that .flac files also get there timestamps recalculated correctly. They should, as that's what this warning is all about.</p>
  <p>Of the three commands you give, I'd use the middle one. It's simpler, and doesn't waste CPU cycles re-encoding.</p>
  <p>I'd not use the &quot;-ignore_unknown&quot; flag, as if there's an input with an unknown format (not flac) then something has gone seriously wrong and you probably want to abort rather than produce unexpected output. I.E. your output file would be missing bits that you expected to be there.</p>
  <p>The first command also seems to want to re-encode things, which is a waste of CPU cycles, but won't decrease audio quality as you're using a lossless codec.</p>
  <p>I was unable to find documentation on the &quot;-safe 0&quot; flag, so can't comment on the third.</p>
  <p>Personally, I would use the '-f concat -i filename.list' syntax for concatenation. The main advantage being that I don't have to worry about hitting command length limits with hundreds (or thousands) of files to concat, and the disadvantage being that I have to remember to delete the temporary &quot;files to be concatenated&quot; list after ffmpeg completes successfully.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-12-23T12:43:58.793Z
Answers.LastActivityDate: 2024-12-23T12:43:58.793Z
Answers.UserDisplayName: John Gilmore
Body: <p>I'm using <strong>ffmpeg</strong> to cut slices from a <strong>flac</strong> audio file then concatenate them together.  I'm able to do this and the output file plays in VLC media player and appears to have the correct duration; however, I get several errors of the form:</p>
  <blockquote>
  <p>&quot;Application provided invalid, non monotonically increasing dts to muxer in stream 0&quot;</p>
  </blockquote>
  <p>I have two questions:</p>
  <ul>
  <li>Do these errors matter?</li>
  <li>Which of the three concat commands that I use is preferable?</li>
  </ul>
  <p>I create the slices with these commands:</p>
  <ul>
  <li><code>ffmpeg -ss 00:00:00.200 -to 00:00:03.100 -i &quot;input.flac&quot; -c:a copy &quot;slice_1.flac&quot;</code></li>
  <li><code>ffmpeg -ss 00:00:04.400 -to 00:00:07.200 -i &quot;input.flac&quot; -c:a copy &quot;slice_2.flac&quot;</code></li>
  </ul>
  <p>These are the three different ways I've tried to concat the files:</p>
  <ul>
  <li><code>ffmpeg  -i &quot;concat:slice_1.flac|slice_2.flac&quot; -codec copy -c:a flac -ignore_unknown merged_1.flac</code></li>
  <li><code>ffmpeg  -i &quot;concat:slice_1.flac|slice_2.flac&quot; -c:a copy merged_2.flac</code></li>
  <li><code>ffmpeg  -i &quot;concat:slice_1.flac|slice_2.flac&quot; -safe 0 -c copy merged_3.flac</code></li>
  </ul>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-07-05T00:24:49.153Z
Comments.Text: For some reason it looks like when using `copy` for FLAC ffmpeg just copies the DTS timestamps as-is, refusing to regenerate them even if the flags are set to do so. I'm not sure if this is by design or a bug, but I ran into the same issue with concatenating FLAC files. I ended up using sox for now, but that's hardly ideal since it ends up re-encoding the FLAC - not a problem in the sense of transcoding losses, but takes a lot of unnecessary time. I'll probably be posting about this to the FFMPEG devs to see if this is by design or if it can be worked around.
Comments.UserDisplayName: mngeek206
Tags: <ffmpeg><audio>
Title: ffmpeg split and concat flac audio file generates error "Application provided invalid, non monotonically increasing dts to muxer in stream 0"
UserDisplayName: Dave
ThreadText: # ffmpeg split and concat flac audio file generates error "Application provided invalid, non monotonically increasing dts to muxer in stream 0"
  
  (Asked by: username_0 on 2021-10-20)
  
  I'm using **ffmpeg** to cut slices from a **flac** audio file then concatenate them together. I'm able to do this and the output file plays in VLC media player and appears to have the correct duration; however, I get several errors of the form:
  
  > "Application provided invalid, non monotonically increasing dts to muxer in stream 0"
  
  I have two questions:
  
  * Do these errors matter?
  * Which of the three concat commands that I use is preferable?
  
  I create the slices with these commands:
  
  * `ffmpeg -ss 00:00:00.200 -to 00:00:03.100 -i "input.flac" -c:a copy "slice_1.flac"`
  * `ffmpeg -ss 00:00:04.400 -to 00:00:07.200 -i "input.flac" -c:a copy "slice_2.flac"`
  
  These are the three different ways I've tried to concat the files:
  
  * `ffmpeg -i "concat:slice_1.flac|slice_2.flac" -codec copy -c:a flac -ignore_unknown merged_1.flac`
  * `ffmpeg -i "concat:slice_1.flac|slice_2.flac" -c:a copy merged_2.flac`
  * `ffmpeg -i "concat:slice_1.flac|slice_2.flac" -safe 0 -c copy merged_3.flac`
  
  **Tags:** ffmpeg, audio
  
  > **Comments:**
  > **username_1**: For some reason it looks like when using `copy` for FLAC ffmpeg just copies the DTS timestamps as-is, refusing to regenerate them even if the flags are set to do so. I'm not sure if this is by design or a bug, but I ran into the same issue with concatenating FLAC files. I ended up using sox for now, but that's hardly ideal since it ends up re-encoding the FLAC - not a problem in the sense of transcoding losses, but takes a lot of unnecessary time. I'll probably be posting about this to the FFMPEG devs to see if this is by design or if it can be worked around.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2024-12-23. Score: 0
  
  Yes, those warnings are safe to ignore. They're caused by the input streams not agreeing on the timestamps - which they don't because you're concatenating, and thus each file starts out with zero and increases from there.
  
  As far as I've determined, this warning *always* happens when concatenating. The output file should have corrected timestamps, and that can easily be checked by re-encoding it or playing it with mplayer. It works for my case, mp3 files, but you may want to double-check that .flac files also get there timestamps recalculated correctly. They should, as that's what this warning is all about.
  
  Of the three commands you give, I'd use the middle one. It's simpler, and doesn't waste CPU cycles re-encoding.
  
  I'd not use the "-ignore\_unknown" flag, as if there's an input with an unknown format (not flac) then something has gone seriously wrong and you probably want to abort rather than produce unexpected output. I.E. your output file would be missing bits that you expected to be there.
  
  The first command also seems to want to re-encode things, which is a waste of CPU cycles, but won't decrease audio quality as you're using a lossless codec.
  
  I was unable to find documentation on the "-safe 0" flag, so can't comment on the third.
  
  Personally, I would use the '-f concat -i filename.list' syntax for concatenation. The main advantage being that I don't have to worry about hitting command length limits with hundreds (or thousands) of files to concat, and the disadvantage being that I have to remember to delete the temporary "files to be concatenated" list after ffmpeg completes successfully.
  
  
  ---
  
  