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. |
20th May 2020, 01:57 | #762 | Link |
Registered User
Join Date: Oct 2014
Posts: 476
|
I just tried to do a weird workflow which had a bugged result:
I have a Blu-ray with 3 episodes in 3 M2TS files. I wanted chapters in them but the Blu-ray playlist for them combines the episodes together, so I threw the playlist into mkvtoolnix and then split it at the episode chapter marks to get 3 MKVs with BD video and PCM audio with chapters. Here's the oddity: When trying to mux in AAC audio and subtitle tracks from a previous encode, it ends up delaying the video and original audio of the split mkvs. Ep 1 will mux fine, but on eps 2 and 3 the black lead-in will play for ~1 second longer than simply the BD video + PCM alone, the Info Tool will show an additional 1 second of playtime, and the AAC and subs will be out of sync with the BD video and PCM, even though if you throw both audio tracks in Audacity it shows them to be in perfect sync. If you mux the AAC audio and subs into the original M2TS' there's no issue. E: it seems to be setting an audio delay relative to video of -1.3 seconds. That's weird because doesn't mkvtoolnix usually cut AAC with a negative delay? Last edited by kuchikirukia; 20th May 2020 at 02:07. |
21st May 2020, 18:28 | #763 | Link |
Registered User
Join Date: Oct 2013
Posts: 207
|
I noticed what appears to be an issue with MKVToolnix, or with what I have in mind...
I have an ISO (DVD) from a TV recording. When I use MPC-HC to open the DVD, the disc is able to play the 2 parts together. When I use MAKEMKV it generates 2 Matroskas. That's OK, but when I append the 2nd file to the 1st, there is an audio bug that is never seen (heard) in these individual files. So this must be a) MKVToolnix's doing, or b) a bug inherent to this idea of appending. Important: I noticed with other disc that is totally different, so this isn't an isolated case, it's valid for ALL appendings we ever do. Let's see if I can explain this... We will assume each video has 2 minutes. Appending would make a single 4 minute MKV file, right? The problem is that the 4 minute file mutes the audio for a second after the point in which they are joined together. Like this: >>>>>> 4 minute file when analyzed further: 2 minutes 2 minutes ====== =/==== / = the muting. / would be at 2:02 or 2:03. Then at 2:04 the video and audio continue just fine. But (and here's the catch) if we open file2.mkv and play it... we never notice the / I just mentioned above. Here's proof of what happened. Instead of just posting a written explanation, I have actually recorded the bug happening First, I want to show how I am putting these files together: https://i.imgur.com/1QQDF2s.png Second, download this file from Google Drive and play in your PC: -LINK REMOVED-, problem solved PROOF.mpg; Pay attention of what happens in the following moments: - 0:00 until 20 seconds - file1.mkv is played. - 20 seconds until 47: file2.mkv is played - Starting at 50 seconds I play this "4 minute" file, which is file1.mkv and file2.mkv appended. 1 minute and 7 seconds: exactly the moment in which the / (bug) can be noticed: the audio is briefly muted. This would be in a 4 minute file the moment 2:02 or 2:03, approximately. Note that file2.mkv at 30 seconds onwards don't show anything wrong. This is how it should have been in the 4 minute file. In theory the appending of file1.mkv and file2.mkv should generate a 4 minute file spotless. Why is that not happening? MEDIAINFO from file1.mkv: https://pastebin.com/1BgabbRa Last edited by Perenista; 22nd May 2020 at 02:16. |
21st May 2020, 19:52 | #764 | Link |
Registered User
Join Date: Oct 2014
Posts: 476
|
Cut out 20 seconds at the end of mkv1, 20 seconds out of the beginning of mkv2, and upload both along with a merged 40 second copy. That will give mosu something to look at.
Also you can probably get around this issue by appending the audio and video tracks separately and them muxing them together. |
21st May 2020, 20:37 | #765 | Link | |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
Mkvmerge has 2 different --append-mode settings. It's common for the default setting to create audio or video gaps. You can read in the docs about them:
https://mkvtoolnix.download/doc/mkvmerge.html Quote:
|
|
21st May 2020, 21:54 | #766 | Link | |
Registered User
Join Date: Oct 2013
Posts: 207
|
Quote:
Yeah, this is a case of a DVD (VOB...) splitted into 2 different MKVs by MAKEMKV, so when appending them I need to use TRACK instead of "FILE" (see below), otherwise this problem will happen. These splitted MKVs are 2 parts of a single content, not two independent recordings from the same DVD that I wanted to put together, yet were always apart from each other. The only reason MAKEMKV created 2 MAKEMKVs is because the DVD was created with 2 options: WATCH ALL (which in the end just put them together) and watch 1st half of the match and 2nd half (it's a broadcast from a sports event). --append-mode mode ********* Determines how timestamps are calculated when appending files. The parameter mode can have two values: 'file' which is also the default and 'track'. When mkvmerge appends a track (called 'track2_1' from now on) from a second file (called 'file2') to a track (called 'track1_1') from the first file (called 'file1') then it has to offset all timestamps for 'track2_1' by an amount. For 'file' mode this amount is the highest timestamp encountered in 'file1' even if that timestamp was from a different track than 'track1_1'. In track mode the offset is the highest timestamp of 'track1_1'. Unfortunately mkvmerge cannot detect which mode to use reliably. Therefore it defaults to 'file' mode. 'file' mode usually works better for files that have been created independently of each other; e.g. when appending AVI or MP4 files. 'track' mode may work better for sources that are essentially just parts of one big file, e.g. for VOB and EVO files. ********* |
|
22nd May 2020, 02:15 | #768 | Link |
Registered User
Join Date: Oct 2013
Posts: 207
|
It worked! I read your message and was reluctant to try. Now I figured out how it's done:
I had to do the following: 1) gMKVExtractGUI: extract the video and chapter tracks from file1.mkv. Repeat procedure for file2.mkv. 2) MKVToolnix: create a MKV with extracted tracks from file 1. Repeat for tracks from file2. 2.1) Merge the two resulting MKVs (append option). 3) gMKVExtractGUI: extract the audio track from file1.mkv. Repeat procedure for file2.mkv. 4) MKVToolnix: create a MKA with extracted tracks from file 1. Repeat for tracks from file2. 4.1) Merge the two resulting MKAs (append option). 5) Insert the MKA inside the MKV and save as a new MKV. A little more work, but it fixed the problem. What I am not sure is how can we tell exactly if appending will cause this issue... I only noticed after checking, otherwise it would be still there. ******** Unfortunately mkvmerge cannot detect which mode to use reliably. Therefore it defaults to 'file' mode. 'file' mode usually works better for files that have been created independently of each other; e.g. when appending AVI or MP4 files. 'track' mode may work better for sources that are essentially just parts of one big file, e.g. for VOB and EVO files. ******** In this case it was easy to spot the error because: a) It's a DVD, so VOB files; b) It's a sports event, a match with 1st and 2nd half, and when we open the DVD it offers us the option to play all together or select one of the two. Another case in which I saw this problem was a TV show episode that is probably viewed as a single one (with 44 instead of 22 minutes) during DVD playback, but it's actually splitted into two when MAKEMKV is extracting. When I tried appending the MKVs the same thing happened, so I let them separated. I never stopped to read mkvmerge's documentation, this is very interesting. Last edited by Perenista; 22nd May 2020 at 02:18. |
22nd May 2020, 02:27 | #769 | Link |
Registered User
Join Date: Oct 2014
Posts: 476
|
Uh, alternately you could've just put file1 and 2 into mkvtoolnix set to append, selected only the video track and hit merge, then deselected the video track and selected the audio track and hit merge, then muxed the resulting mkv and mka files together.
You just always need to check your joins. There's no way to automatically tell which way is the right way to append. Subtitles especially will wreck things if you're splitting and appending since the lines don't get cut on split (it only splits between subtitle lines). So your audio and video will get cut on the keyframe, the subtitle line will extend further, and so when you try to append, everything in the next file will get pushed back to the end of the subtitle line. Last edited by kuchikirukia; 22nd May 2020 at 02:44. |
30th May 2020, 13:58 | #773 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,281
|
MKVToolNix v47.0.0 released
Well hello, gentle people.
Surprisingly it's still May, even though it feels much longer since… well everything, really. Anyway, roughly four weeks since the previous release means it's a good time for another MKVToolNix release. v47 contains a couple of new enhancements and few bug fixes. However, under the hood big chunks of the source code was changed in an ongoing effort of switching from using Boost libraries to the C++ standard library. For end users this replacement doesn't mean much — apart from the usual danger of accidentally introducing bugs. Hopefully not too many. For package maintainers the situation is different. There were several changes, not only due to this migration. Please read the news below carefully. Thanks. Here are the usual links: the MKVToolNix home page, the Windows installer/portable version & macOS DMG & Linux AppImage and the source code. The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available over the course of the next couple of hours. Here are the NEWS since the previous release: Version 47.0.0 "Black Flag" 2020-05-30 New features and enhancements
Bug fixes
Build system changes
Have fun
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
30th May 2020, 17:44 | #775 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,281
|
The thing is: I'm using libdvdread for reading DVDs. That library has the same problem a lot of other Unix-originating libraries have: they use the "open()" or "fopen()" function which only takes a char* as the file name argument, or to put it differently: they don't support reading from file names/paths that contain non-ASCII (non-ANSI, but due to how mkvmerge works internall, non-7bit-ASCII effectively) characters on Windows (on Linux/macOS that's not a concern as those functions take UTF-8 encoded char* strings there).
Bummer. But something I did know about when I made the decision to use libdvdread. Classical tradeoff between the amount of time I was willing to invest into this feature (it already took several hours to implement) and the importance of the feature (DVD? nowadays? Pleeease… and there are other tools that can get you the same information).
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
30th May 2020, 20:49 | #777 | Link |
李姗倩 Lǐ Shān Qiàn
Join Date: Nov 2002
Posts: 1,340
|
@Mosu
Thanks again for your passionate work It's unfortunate that FLAC support is limited; one doesn't have this problem if WavPack is used instead? [Btw I don't think you need to bad-mouth (?) DVD just because it's not the newest format; there are some hidden gems - old shows - only available as DVDs, and in some cases BD versions may even look worse when the show was originally created as SD but forcefully up-scaled to HD w/o careful remastering...] @hubblec4 On Windows, Unicode (non "ANSI") file names often have ascii file names too, as seen by dir /x. Which may help in some cases, transparently recognized as the alias of the Unicode file name. E.g. Avisynth can read Unicode file names if you use such short (ascii) names. @Masutin Not sure if this will help you with your specific problem, but if you just open a file (e.g. MKV) with VirtualDub2, Keyframes are shows as scuh (Shift + arrow keys). You could also do ffmsindex.exe -f -k "path\to\your file.mkv" to quickly get the keyframe list. |
30th May 2020, 21:23 | #778 | Link | |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
Since Windows 10 the code page can be changed to UTF8, most but not all apps work well with it.
Quote:
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists Last edited by stax76; 30th May 2020 at 21:30. |
|
30th May 2020, 22:23 | #780 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
Thanks, I hope it will be useful.
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists |
Tags |
matroska |
|
|