Cuts causing audio shift when ts is compressed

Begonnen von SamiS, Dezember 27, 2022, 11:58:48

« vorheriges - nächstes »


Hi everyone, happy holidays whatever's left of it!
Seems I've been TS-Doctor user for exactly 2 yrs today  ;D

I have a problem I've come across, but only now had some time to test it better:
When I make cuts (ie remove commercial breaks) and then compress the resulting .ts file (tried StaxRip and AVIdemux, x264 & x265)
- compression process often halts at the cut point
- if it happens to run through whole file, every cut produces shift in audio (+subtitles? did not check properly yet), which accumulates to very distracting result towards end

Every cut creates an error like this when you run the resulting .ts-file through ProjectX:
!> dropping GOP# 1536 @ orig.PTS 03:27:41.234 (1121511115), errorcode: 24
!> Pics exp/cnt 3/1, inGOP PTS diff. 0ms, new Timecode 00:12:18.760
!> startPTS of GOP# 1537 is earlier than the end of last GOP.. (exp. 1121511115)
!> dropping GOP# 1537 @ orig.PTS 03:27:41.154 (1121503915), errorcode: 10
!> Pics exp/cnt 6/6, inGOP PTS diff. 0ms, new Timecode 00:12:18.760
!> PTS difference of 14400 (00:00:00.160) to last exported GOP detected
!> dropping useless B-Frames @ GOP# 1538 / new Timecode 00:12:18.760

I've attached example log from ProjectX, along with TS-Doctor log of the previous step of the process. This should be easily repeatable as I've tried with a variety of different material with same result.

As it stands, ProjectX corrects the error in audio, so SD-material without subtitles I can work with just fine. ProjectX can not handle HD.

I tried quite a few settings hoping for a miracle, without luck. Any help to settings / use of another software like ProjectX for HD would be greatly appreciated !

Answers like 'hard drives are cheap, why compress' are also appreciated, and my current method, but would like to get to the bottom of this. I'm cheap that way  ;)



I'm not an expert in TS-Doctor, but are you sure you made the cut points on I-Frames? The beginning of the "cut-out" (to be omitted) might be located anywhere, but the first frame which is again part of the resulting stream must be an I-Frame, otherwise the stream will be broken until the next I-Frame appears. Just to make sure this basic requirement is fulfilled...


Yes, forgot to mention that. Actually I've always made all cut points on I-frame. Now tried with only the first frames on I-frames like you described, to see if there's any difference. End result is the same, but sure enough ProjectX log is cleaner with no errors from the beginnings of cut-outs. So maybe that's a clue..

-> starting export of video data @ GOP# 14
!> dropping useless B-Frames @ GOP# 14 / new Timecode 00:00:00.000
!> dropping GOP# 1536 @ orig.PTS 03:40:09.954 (1188895915), errorcode: 24
!> Pics exp/cnt 18/16, inGOP PTS diff. 0ms, new Timecode 00:12:11.200
!> PTS difference of 46800 (00:00:00.520) to last exported GOP detected
!> dropping useless B-Frames @ GOP# 1537 / new Timecode 00:12:11.200
!> dropping GOP# 2612 @ orig.PTS 03:48:46.714 (1235404315), errorcode: 24
!> Pics exp/cnt 3/2, inGOP PTS diff. 0ms, new Timecode 00:20:47.360
!> startPTS of GOP# 2613 is earlier than the end of last GOP.. (exp. 1235404315)
!> dropping GOP# 2613 @ orig.PTS 03:48:46.674 (1235400715), errorcode: 10
!> Pics exp/cnt 12/12, inGOP PTS diff. 0ms, new Timecode 00:20:47.360
!> PTS difference of 39600 (00:00:00.440) to last exported GOP detected
!> dropping useless B-Frames @ GOP# 2614 / new Timecode 00:20:47.360



Hi, I have the same problem with 2.x first and also with 3.x.
When I play the TS file recorded from receiver, i adio is in sync with th evideo, also if i go up and down into the file.
When i cut file in 2-3 part for remove advertising, .TS file are still in sync, but if i convert this .TS fine in all ways (direct, demuxing first, 1000 ways) the result is out of sync.


TS-Doctor cuts files without reencoding the video stream. To avoid problems at the cut points, TS-Doctor choose i-frames at the cut in and the cut out and removes all data packets inbetween them. As every audio and video frame has a dedicated timer, the file stays in sync.

Most video converts unfortunately ignore those timers and create a scar at the cut points.