• “创新从来都是九死一生”(人民论坛) 2019-02-14
  • 端午假期广州铁路运客640.5万人次 创历史新高 2019-02-14
  • 19次生态输水让塔河下游生机勃勃 2018-11-22
  • 男篮再胜伊朗迎热身赛两连胜 任骏飞19+11陶汉林18分 2018-11-22
  • 小卒子,你南街村的代言人啊?扮豬不咋像呢!你滴,大大滴,明白? 2018-11-22
  • 女性之声——全国妇联 2018-11-21
  • 新华网评:凝聚打赢脱贫攻坚战的强大合力 2018-11-21
  • 栗战书:执法检查要直面问题不搞评功摆好 让法律制度成为不可触碰的高压线 2018-11-21
  • 这些水果越新鲜越不能吃 放一放更好吃 2018-11-21
  • 生产资料公有制不会也不可能涉及生产资料的分配,这完全是你杜撰的,是强词夺理的。从这点看,你的所谓逻辑是幼稚可笑的。哈哈哈哈! 2018-11-20
  • 践行“两山论”是一场发展的革命 2018-11-20
  • 女教师舍身保护学生被撞身亡感动各界 2018-11-20
  • Welcome to

    Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

     

    Go Back   Doom9's Forum > Capturing and Editing Video > New and alternative a/v containers

    Reply
     
    Thread Tools Search this Thread Display Modes
    Old 7th February 2019, 20:53   #381  |  Link
    MKVToolNix author
     
    Mosu's Avatar
     
    Join Date: Sep 2002
    Location: Braunschweig, Germany
    Posts: 3,749
    Sounds like the -1446ms might have to be 1446ms.
    __________________
    Latest MKVToolNix is v31.0.0

    If I ever ask you to upload something, please use my FTP server.
    Mosu is offline   Reply With Quote
    Old 7th February 2019, 21:47   #382  |  Link
    Registered User
     
    manolito's Avatar
     
    Join Date: Sep 2003
    Posts: 2,388
    No, that's not it. To get the correct audio sync the delay has to be 0.
    manolito is offline   Reply With Quote
    Old 7th February 2019, 23:07   #383  |  Link
    Registered User
     
    Join Date: May 2016
    Posts: 157
    The second audio track (track #3) starts at 5ms, the first audio track (track #2) at 65ms. The first video keyframe has a timestamp of 1571ms, the lowest video frame has a timestamp of 1511ms (this file uses open GOP). If you extracted both track #2 and track #1 (the video) and muxed it back with mkvmerge, mkvmerge would give the lowest video frame a timestamp of 0ms and the first video keyframe a timestamp of 60ms. This is a difference of 1511ms; in order to keep AV sync, you would have to offset the audio by 1511ms, too; extracting audio to elementary streams makes it loose its initial delay (here 5ms and 65ms) which already amounts to subtracting 5ms resp. 65ms from the audio tracks. So you would have to subtract a further 1511ms - 65ms from track #3. But this is only true if you actually extracted both audio and video and remuxed the elementary tracks -- your comment seems as if you didn't extract the video at all.
    Btw: Why extract the tracks to elementary tracks at all? If you have transmission errors (and therefore missing packets), you will loose A/V sync no matter whether the initial offsets were right.

    Last edited by mkver; 7th February 2019 at 23:19.
    mkver is offline   Reply With Quote
    Old 8th February 2019, 15:24   #384  |  Link
    Registered User
     
    manolito's Avatar
     
    Join Date: Sep 2003
    Posts: 2,388
    Thanks mkver for the detailed analysis, but this is not really my point...

    The average user will not have such analysis skills (I certainly don't), and we have software like mkvextract and mkvmerge to do this automatically. This is all I am asking for.

    You are correct, I did not extract the video track at all, I just extracted the audio track and remuxed it into the source MKV. And this resulted in the sync error. I just tried again and extracted both the video and audio tracks, then imported both tracks into MKVMerge to create a new MKV. And yes, this time the only way to avoid sync errors was to honor the audio delay for the muxing process. So it does make a difference if I add an audio track with a delay to an already existing MKV with a video track, or if I create a brandnew MKV with video and audio tracks. Weird, and basically I do not want to deal with this.

    The reason why I need to extract the audio track(s) from the source MKV is that I use StaxRip (an older 32-bit version) to recode the HD source HEVC / AAC-LATM (or E-AC3) into an SD AVC / AAC file. And StaxRip processes the audio separately from the video, and the extracted audio always needs to be decompressed to PCM first to make frame accurate editing possible.

    And if the captured source has transmission errors, you do have a point. If I have repacked a captured MTS file to MKV first and there are glitches in this file, I will loose audio sync. But by trial and error I found out that this does not happen if I use the original MTS or TS as the source for StaxRip. My source filter is DSS2Mod, and when the source has transmission errors and I use the original Transport Stream as the source then I will see the broken frames, but sync is maintained.

    Using the original Transport Stream as the source has its problems, though, and I try to avoid it when I can. Editing out commercials is a major PITA when using HEVC Transport streams, seeking the desired frame by stepping through the frames always brings up corrupt frames because the next I-Frame cannot be found. After repacking the source to MKV these problems disappear completely.

    Luckily transmission errors are very rare for me with the DVB-T2 format. I always use TSDoctor to check for transmission errors, and about 95% of my captures are error-free.


    Cheers
    manolito
    manolito is offline   Reply With Quote
    Old 9th February 2019, 01:14   #385  |  Link
    Registered User
     
    Join Date: May 2016
    Posts: 157
    Quote:
    Originally Posted by manolito View Post
    The average user will not have such analysis skills (I certainly don't), and we have software like mkvextract and mkvmerge to do this automatically. This is all I am asking for.
    The software can't read your mind, but what could be done is that if a Matroska file has a video track and you select to not extract the video track, then the delay that is put into the filenames should not be calculated as if the video started with 0, but rather as if the video timestamps were unchanged (in your example, the delay that would be put in the filenames would be 5ms and 65ms). You may ask gpower2 about it; but who knows: Maybe someone else would call the behaviour just proposed weird.
    (And what should happen when there is more than one video track? I don't know.)

    There is BTW a second workaround for you that is only applicable when your recording contains a few seconds at the beginning that you want to discard (there needs to be a complete GOP at the beginning that you don't want to keep). When you initially remux from ts to mkv, you can let mkvmerge split by parts based on timestamps in order to discard the very beginning. The lowest timestamp of the main video track will then be zero (for each part). So the problem you encountered here doesn't happen for such files.
    Quote:
    Originally Posted by manolito View Post
    The reason why I need to extract the audio track(s) from the source MKV is that I use StaxRip (an older 32-bit version) to recode the HD source HEVC / AAC-LATM (or E-AC3) into an SD AVC / AAC file. And StaxRip processes the audio separately from the video, and the extracted audio always needs to be decompressed to PCM first to make frame accurate editing possible.
    I don't use StaxRip, but keep in mind that StaxRip may add confusion of its own to the offsets. (I.e. does StaxRip even care about the offset in the input file (namely that the first video track doesn't start at zero?)? How does it handle the fact that the lowest video timestamp belongs to an undecodable frame (one of the B-frames shared between GOPs?)?)
    Quote:
    Originally Posted by manolito View Post
    If I have repacked a captured MTS file to MKV first and there are glitches in this file, I will loose audio sync. But by trial and error I found out that this does not happen if I use the original MTS or TS as the source for StaxRip. My source filter is DSS2Mod, and when the source has transmission errors and I use the original Transport Stream as the source then I will see the broken frames, but sync is maintained.
    Newer versions of mkvmerge discard whole PES packets when mkvmerge detects any errors (by looking at the continuity counter). This might explain your observation. The last version that didn't do this was AFAIK 19.0.
    mkver is offline   Reply With Quote
    Old 9th February 2019, 16:20   #386  |  Link
    Registered User
     
    manolito's Avatar
     
    Join Date: Sep 2003
    Posts: 2,388
    Quote:
    Originally Posted by mkver View Post
    The software can't read your mind
    It does not have to. All I would like to see is a behavior which is consistent with the behavior of other software for the identical task.

    Let's not talk about the peculiarities of captured transport streams, let's also forget about StaxRip. Let's break it down to a very common task which I need to perform frequently (and other users probably too).

    I have a clip in an MKV container, MediaInfo reports a certain audio delay. I need to "beautify" the audio. So I need to extract the audio track, decompress to WAV, do all my nasty tricks in WaveLab (or any advanced WAVE editor), save the WAV and convert it to AAC. The last step is to import this audio track into the original MKV, disable the original audio track and remux it into a new MKV. Very simple...

    If I do this using gMKVExtractGUI and MKVToolnixGUI then the result will be out of sync, because the audio delay value is written into the file name of the extracted audio track. All following operations will preserve the filename with the embedded delay value. Remerging it back into the original MKV will honor the delay value, and this results in a sync error.

    I will not get sync problems if I use FFmpeg or AviDemux for this task. The reason is simple, this other software does not care for audio delay values. Remuxing the "beautified" audio back into the original MKV will give out a new MKV in perfect sync.

    So all I am asking for is consistent behavior. It is too bad that Pashin stopped maintaining his MKVExtractGUI2 software, IIRC the last supported MKVToolnix version was v. 20.


    Cheers
    manolito
    manolito is offline   Reply With Quote
    Old 9th February 2019, 16:46   #387  |  Link
    Yet another Doom9 member
     
    gpower2's Avatar
     
    Join Date: Aug 2003
    Location: Greece / Thessaloniki
    Posts: 195
    Quote:
    Originally Posted by manolito View Post
    It does not have to. All I would like to see is a behavior which is consistent with the behavior of other software for the identical task.

    Let's not talk about the peculiarities of captured transport streams, let's also forget about StaxRip. Let's break it down to a very common task which I need to perform frequently (and other users probably too).

    I have a clip in an MKV container, MediaInfo reports a certain audio delay. I need to "beautify" the audio. So I need to extract the audio track, decompress to WAV, do all my nasty tricks in WaveLab (or any advanced WAVE editor), save the WAV and convert it to AAC. The last step is to import this audio track into the original MKV, disable the original audio track and remux it into a new MKV. Very simple...

    If I do this using gMKVExtractGUI and MKVToolnixGUI then the result will be out of sync, because the audio delay value is written into the file name of the extracted audio track. All following operations will preserve the filename with the embedded delay value. Remerging it back into the original MKV will honor the delay value, and this results in a sync error.

    I will not get sync problems if I use FFmpeg or AviDemux for this task. The reason is simple, this other software does not care for audio delay values. Remuxing the "beautified" audio back into the original MKV will give out a new MKV in perfect sync.

    So all I am asking for is consistent behavior. It is too bad that Pashin stopped maintaining his MKVExtractGUI2 software, IIRC the last supported MKVToolnix version was v. 20.


    Cheers
    manolito
    I am sorry manolito, but if your usage scenario involves reencoding the extracted audio track, then it certainly can involve renaming the file!

    Extracting audio tracks with the exact delay is and will stay the default action since if this information is lost, then the user can't re-merge the original tracks without losing sync.
    If someone uses the extracted track for something more complicated than that, then simply renaming the extracted track's filename will suffice.

    In the next version, I will add a custom filename creation mode, in order for the user to choose how the extracted filenames are generated.
    I guess you can then change the filename generation rule and your problem will be solved.
    __________________
    Gp2 says: Don't be a fool, just be cool :D !
    gpower2 is offline   Reply With Quote
    Old 9th February 2019, 17:04   #388  |  Link
    Registered User
     
    manolito's Avatar
     
    Join Date: Sep 2003
    Posts: 2,388
    Yes, this will certainly solve it for me...
    manolito is offline   Reply With Quote
    Old 9th February 2019, 17:24   #389  |  Link
    Registered User
     
    Join Date: Mar 2017
    Posts: 51
    Hi gp2, had a few suggestions if you don't mind:

    Quote:
    Is it possible to add an option to extract tracks with its title property? Especially useful for subs (forced subs, sdh etc) and audio (lossless, lossy, different channels mix etc) where there are multiple of them in the same language and currently it's not easy to differentiate them by name.

    An option to extract based on number of chapters/attachments entries each file has would also be very useful!
    dissory is offline   Reply With Quote
    Old 10th February 2019, 09:43   #390  |  Link
    Registered User
     
    Join Date: May 2005
    Location: Around the corner
    Posts: 4
    Quote:
    Originally Posted by Csimbi View Post
    Hi there,
    I'd like to make a request for gMKVExtractGUI.
    That is, to zero-pad track numbers.
    Current example: _track8_
    Future example: _track08_

    The reason is simple: so they would show up in correct order in my file manager.
    (08,09,10,11 instead of 10,11,8,9)

    Thank you!
    Pretty please? ;-)
    __________________
    Best regards: Csimbi
    Csimbi is offline   Reply With Quote
    Old 10th February 2019, 11:49   #391  |  Link
    Yet another Doom9 member
     
    gpower2's Avatar
     
    Join Date: Aug 2003
    Location: Greece / Thessaloniki
    Posts: 195
    Quote:
    Originally Posted by dissory View Post
    Hi gp2, had a few suggestions if you don't mind:
    Quote:
    Originally Posted by Csimbi View Post
    Pretty please? ;-)
    Hopefully all the above will be addressed with the new version. However, it's not going to be released soon, since my job is keeping me really busy...
    __________________
    Gp2 says: Don't be a fool, just be cool :D !
    gpower2 is offline   Reply With Quote
    Reply

    Tags
    extractor, gmkvextractgui, matroska, mkv, mkv extract, mkvextract, mkvextractgui


    Posting Rules
    You may not post new threads
    You may not post replies
    You may not post attachments
    You may not edit your posts

    BB code is On
    Smilies are On
    [IMG] code is On
    HTML code is Off

    Forum Jump


    All times are GMT +1. The time now is 06:09.


    Powered by vBulletin® Version 3.8.11
    Copyright ©2000 - 2019, vBulletin Solutions Inc.
  • “创新从来都是九死一生”(人民论坛) 2019-02-14
  • 端午假期广州铁路运客640.5万人次 创历史新高 2019-02-14
  • 19次生态输水让塔河下游生机勃勃 2018-11-22
  • 男篮再胜伊朗迎热身赛两连胜 任骏飞19+11陶汉林18分 2018-11-22
  • 小卒子,你南街村的代言人啊?扮豬不咋像呢!你滴,大大滴,明白? 2018-11-22
  • 女性之声——全国妇联 2018-11-21
  • 新华网评:凝聚打赢脱贫攻坚战的强大合力 2018-11-21
  • 栗战书:执法检查要直面问题不搞评功摆好 让法律制度成为不可触碰的高压线 2018-11-21
  • 这些水果越新鲜越不能吃 放一放更好吃 2018-11-21
  • 生产资料公有制不会也不可能涉及生产资料的分配,这完全是你杜撰的,是强词夺理的。从这点看,你的所谓逻辑是幼稚可笑的。哈哈哈哈! 2018-11-20
  • 践行“两山论”是一场发展的革命 2018-11-20
  • 女教师舍身保护学生被撞身亡感动各界 2018-11-20