Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
7th February 2019, 20:53 | #381 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,281
|
Sounds like the -1446ms might have to be 1446ms.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
7th February 2019, 23:07 | #383 | Link |
Registered User
Join Date: May 2016
Posts: 197
|
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. |
8th February 2019, 15:24 | #384 | Link |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,079
|
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 |
9th February 2019, 01:14 | #385 | Link | |||
Registered User
Join Date: May 2016
Posts: 197
|
Quote:
(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:
Quote:
|
|||
9th February 2019, 16:20 | #386 | Link |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,079
|
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 |
9th February 2019, 16:46 | #387 | Link | |
gMKVExtractGUI author
Join Date: Aug 2003
Location: Greece / Thessaloniki
Posts: 251
|
Quote:
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. |
|
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:
|
|
10th February 2019, 09:43 | #390 | Link | |
Registered User
Join Date: May 2005
Location: Around the corner
Posts: 6
|
Quote:
__________________
Best regards: Csimbi |
|
19th April 2019, 09:04 | #393 | Link |
Registered User
Join Date: Mar 2019
Posts: 1
|
This is a wonderful software but only one thing. I am wondering if you don't mind to add the utility to automatically create the destination folder if not existing? For people who use a fixed folder, it's a little annoying being warned about "not exist" and manually navigating and creating it. Many thanks if you could implement it for the minority.
Update: Thanks. No need to bother any more. I already had a look at the source code and manually changed it to automatically create the output dir without warning. Last edited by airium; 22nd April 2019 at 07:15. |
17th May 2019, 17:48 | #394 | Link |
Registered User
Join Date: Oct 2006
Location: Omicron Persei 8
Posts: 180
|
Hey gpower2, thanks for the great tool. I love it extracts chapters too! I noticed that there isn't an option for mkvextract --raw so that video streams are extracted to the raw format rather than .avi (at least for vc1 streams).
Could you add that option please? Maybe with the --fullraw if that is of use at all. Thank you very much! |
12th June 2019, 19:59 | #396 | Link |
gMKVExtractGUI author
Join Date: Aug 2003
Location: Greece / Thessaloniki
Posts: 251
|
gMKVExtractGUI v2.5.0
Hey guys! I managed to find the time and refactor the inner works for the output filename generation, so that it can now be customizable!
I added a new Options form which can be accessed from a new button located at the bottom of the main form. I also added some small features that were requested over time and made some changes in the form's controls. Enjoy people! Changelog v2.5.0
|
15th June 2019, 23:05 | #398 | Link | |
Registered User
Join Date: May 2005
Location: Around the corner
Posts: 6
|
Quote:
Even better than I hoped for. It was well worth the wait. Thank you, much appreciated!
__________________
Best regards: Csimbi |
|
Tags |
extractor, gmkvextractgui, matroska, mkv, mkv extract, mkvextract, mkvextractgui |
|
|