Problem with multi-edition MKV creation

[hubblec4]

Hi Rocky

Unfortunately, I now have a Blu-ray where removing the audio overlap is not precise.

The whole thing was reported to me by a user on Reddit.
Init issue: https://www.reddit.com/r/chapterEditor/ ... tion_mkvs/
And more discussion and try to use another Matroska linking way https://www.reddit.com/r/chapterEditor/ ... rsion_142/
After a while he sent me the Blu-ray and I was able to test it out myself.

Here's the link to the normal Blu-ray.
https://www.amazon.de/STAR-WARS-Ep-IV-H ... 8&qid=&sr=

And now something about the problem:
The Blu-ray is a typical multi-Angle Blu-ray with 3 different film versions.
All 3 versions are exactly the same length because there are no extra scenes, only certain video images are replaced where a language can be seen.
Therefore there are only 6 m2ts files for each version.

The user wants to save the English (00800.mpls) and German (00801.mpls) versions in a multi-edition mkv.
The first version should be the English one.
This uses the following m2ts files: 00901 + 00902 + 00903 + 00905 + 00906 + 00908
The German version is intended to be the second version and uses the following m2ts files: 00910 + 00902 + 00912 + 00905 + 00913 + 00908

cE now creates a multi-version segment list of all m2ts files used and generates the chapters.xml(see attachments) file with exact timestamps (this was also confirmed by the said user).
Then the audio tracks of such Blu-rays must be demuxed.
The mpls 00800 is used as the basis and the remaining m2ts files are appended using the -extras switch
00910 + 00912 + 00913

There is an English DTS track and a German EAC3 track.
When I demux both tracks with DGDemux (and then mux them into the mkv), there is an audio problem in the second version in chapter 23 which is clearly audible.
Shortly before chapter 23 is reached there is a change of scene and the new video image is shown but a little bit of audio is played which still belongs to the old chapter.

When I use eac3to3.34 for demuxing then the English track is fine and there is no audio error.
However, eac3to3.34 is not able to demux the EAC3 track.
That's why I tested everything with eac3to3.45.
The English track is also demuxed correctly, but unfortunately the German EAC3 track is not, so the audio problem is still audible.

Then I edited each version individually and only used the respective mpls as input for DGDemux.
Both versions were created correctly and there are no audio problems.
This shows that your audio algo is working correctly for an mpls with the correct playback order of the m2ts files.

Of course, I really hope that you can correct this for the extra attached m2ts files.
Even if they are not in the correct playback order, perhaps it would help if this information were available?

Since this problem also affects eac3to, I would report it there too.
I assume that Curly has read along here and I'm waiting for your answer(s), to avoid double posting.

[Rocky]

I warned you about this!

What happens if you disable gaps correction for demuxing in DGDemux? With only 5 gaps you should have just a small desync.

Meanwhile, I will think about possible solutions, as not all playlists will have so few clips.

[hubblec4]

I warned you about this!

Yes I know, and I had said this also to the user

What happens if you disable gaps correction for demuxing in DGDemux? With only 5 gaps you should have just a small desync.

This would be the same as a direct mux from the Blu-ray. The Audio glitch is there(both audios, DTS and EAC3) and the video frames no longer matches the chapter markers(a different frame is shown).

Meanwhile, I will think about possible solutions, as not all playlists will have so few clips.

My hope is that you can use the DTS stream demuxed with eac3to. Maybe this helps understand what eac3to does to remove the correct data.

[Rocky]

This would be the same as a direct mux from the Blu-ray. The Audio glitch is there (both audios, DTS and EAC3) and the video frames no longer matches the chapter markers (a different frame is shown).

Ah, seems I may have misunderstood your issue. It's naught to do with gaps correction then? Please clarify this as much as possible because your first post was referencing gaps correction.

Make it easy for me. Tell me concisely what DGDemux is doing wrong compared to eac3to 3.36 or whatever. Is it wrong with and without gaps correction?

[hubblec4]

Gap processing actually means that unnecessary audio data is removed and no gap is closed. Or am I misinterpreting that?

If DGDemux is used to demux the English DTS track then there is an audio problem, but not when using eac3to (no matter which version).
However, for the German EAC3 track there are audio problems regardless of whether demuxing is done with eac3to or DGDemux.

So that you can understand the problem, you would also have to create a multi-edition mkv and play it with MPC-HC. The second edition must be selected.

To create such a multi-edition mkv file, you could use cE or MTX directly. To do this you would have to demux the video and the two audio tracks and then load everything into MTX and, very importantly, the Chapter.xml must also be muxed.

[Rocky]

Gap processing actually means that unnecessary audio data is removed and no gap is closed. Or am I misinterpreting that?

I don't know what you mean by "no gap is closed". Gap processing for DGDemux means that audio is deleted at gaps as necessary to maintain sync with the video. "Gap" just means a junction between two M2TS files. At any given gap audio may or not be deleted, depending on the sync at that point. Sync is assessed by tracking the accumulated video and audio times.

If DGDemux is used to demux the English DTS track then there is an audio problem, but not when using eac3to (no matter which version).

You haven't told me what the "audio problem" is. Nor have you told me if it occurs with and without gaps processing enabled in DGDemux. Is your audio problem a pop or something or is it just that the chapter(s) are off?

However, for the German EAC3 track there are audio problems regardless of whether demuxing is done with eac3to or DGDemux.

Ditto. What "audio problems"? Nor have you told me if it occurs with and without gaps processing enabled in DGDemux.

So that you can understand the problem, you would also have to create a multi-edition mkv and play it with MPC-HC. The second edition must be selected.

To create such a multi-edition mkv file, you could use cE or MTX directly. To do this you would have to demux the video and the two audio tracks and then load everything into MTX and, very importantly, the Chapter.xml must also be muxed.

Sorry, I'm not going to involve cE. You have to demonstrate issues with DGDemux/MTX alone.

I asked you to make it easy but you're making me jump through hoops. Do this:

1. Tell what and how to demux.
2. Tell how to remux. Use MTX only, no cE.
3. Tell the resulting problem and how to see it.

The only problem I can glean from what you've said is some previous audio at a chapter. But cE is doing all kinds of magic with chapters. That's why I'd like a demonstration of the problem without cE. If you are trying to get a valid chapters file from a demux with -extras, I don't know offhand what that will produce.

I just read your two linked reddit threads and I don't see anything pointing to a DGDemux issue. The guy thinks it is a player problem.

I'll order the disk when you've addressed my points above.

[hubblec4]

Gap processing: Yes we mean the same and DGDemux removes Audio data if necessary.

The audio problem is an audible effect that occurs when the video is played normally.

The “error” in question occurs with and without gap processing. It seems that at this point audio data are used which are not should be there, because in a remux of the edition alone/separate will not produce the audio problem.

The chapters that cE creates aren't really magic. It's pure Matroska logic.
The same chapters are used once with the demuxed tracks with eac3to, and once with the demuxed tracks from DGDemux. With eac3to everything works perfectly for the DTS track.

I already thought that you wouldn't use cE. That's why I described in the next sentence how it works without cE.
With DGDemux, video and both audio tracks are demuxed. Gap processing is used here. Then the three tracks are loaded into MTX and you also have to mux the Chapter.xml. There is an option to load a chapter file in the “output” tab in the mux settings.

1. DGDemux 00800.mpls -extras 00905,00913,00908 "video und both audio PIDs" - demux
2. explained above
3. play the final mkv in MPC-HC, select the second edition from the edition menu. the edition menu is located in the system tray icon of LAV splitter or in the MPC-HC options(right click in the screen -> LAV Splitter)
jump to timestamp 00:49:55 and let it play. A loud humming noise can be heard when the scene changes.

There is just one thing without which this problem cannot be created.
Neither DGDemux nor MTX can create these special ordered chapters, but every good player handles it perfectly because it is defined that way in the Matroska specs.

As I said before, I use Google translate, and I'm sorry if things don't come across as clearly as I would like. If I copy the English text from you and Google translates it, then I often have to guess what might be meant. I guess Google Translater doesn't work that well after all.

[Shoespooner]

I am the other guy who has discussed this issue with hubble4c on Reddit. Although this really isn't my area, I'll try to answer a part of your questions.

If DGDemux is used to demux the English DTS track then there is an audio problem, but not when using eac3to (no matter which version).

You haven't told me what the "audio problem" is. Nor have you told me if it occurs with and without gaps processing enabled in DGDemux. Is your audio problem a pop or something or is it just that the chapter(s) are off?

I am referring to the explanations in this post from hubble4c: https://www.rationalqm.us/board/viewtop ... 298#p19298 and the attached chapters.xml.

When playing the second edition of the resulting MKV, the player at a certain point must switch from chapter 21 to chapter 22. Exactly at the begin of chapter 22, for a fraction of a second, there is a loud noise that does not fit to the video. It took me quite a while before I was able to identify it, but now I am sure that it is from the end of chapter 3. This is not a typo.

I don't know whether the issue is due to the player or due to the muxing / demuxing. However, I can understand why there is a problem in this moment. Let's look how the original M2TS parts are arranged in the resulting multi-edition MKV if we keep only the English and the German edition (leaving away the leading 00 and the extension of the M2TS file names):

901 902 903 905 906 908 910 912 913

When playing edition 1 (English), the playing order is 901 902 903 905 906 908. When playing edition 2 (German), the order is 910, 902, 912, 905, 913, 908.

910 contains chapters 1, 2 and 3 of the German edition. That is, the end of chapter 3 is identical with the end of 910.

The next part that differs between the first and the second edition is part 903 (English) vs. part 912 (German). In the second edition, when transitioning from chapter 21 to chapter 22, this means a jump from 902 to 912, since the start of chapter 22 is identical with the start of 912.

As described above, the disturbing noise occurs immediately after the transition from chapter 21 to chapter 22, and hence, after the transition from 902 to 912. Originally, I was wondering why there is noise from the end of chapter 3 at the begin of chapter 22, but if we look at the physical layout of the original M2TS files in the resulting MKV, it finally is logical:

The end of 910 (and hence, the end of chapter 3) immediately precedes the start of 912 (and hence, chapter 22) in the physical file layout. Given that, it is obvious that there is an audio overlap from 910 to 912 (that is, from chapter 3 to chapter 22).

Our question is whether DGDemux can do anything about it.

Regarding with or without gaps processing, I can't tell anything about it. But as far as I have understood your explanation, turning off gaps processing wouldn't be the best idea, because the offset between audio and video would add up at each gap.

You are right that it is only 5 gaps in that case, but in reality, it is 8 gaps (additional three gaps at the end). An EAC3 audio frame in a typical configuration is 32 ms. In a worst-case scenario with 8 gaps, that could sum up to 256 ms. If the demuxer works at the block level instead the frame level, it can get much worse. A smart algorithm could perhaps compensate a part of it by trading off overlap vs. silence, but in general, turning off gaps processing doesn't seem the right way to me, even when there are only a few M2TS files.

I perfectly understand that you can't analyze results that are produced by third-party software. But on the other hand, cE is a very convenient front end to software like DGDemux which non-experts like me wouldn't be able to operate at all without it. And after all, as far as I have understood, cE delegates the main part of the work to DGDemux and MTX, produces appropriate logs and even generates configuration files.

Perhaps I am able to understand the details later. Then I could post the command lines and configuration files that cE produces and executes. I may have to wait for the weekend to do that, though.

I hope I also can clarify the DGDemux vs. Eac3to thing. What hubble4c means is the following:

In the first edition (English), there are no audio problems, neither in the English nor in the German audio track, if the M2TS files have been demuxed by DGDemux before MTX has created the MKV from them. There are also no audio problems in the first edition in the English audio track if Eac3to (instead of DGDemux) has demuxed the M2TS files. A test of the German audio track is not possible with Eac3to because Eac3to can't process the German EAC3 track (making me wonder where its name comes from).

In the second edition, there is the audio glitch described above in the English and the German audio track if the M2TS files have been demuxed by DGDemux before MTX has created the MKV from them. But the glitch in the English audio track in the second edition does not appear if Eac3to has demuxed the M2TS files before MTX has created the MKV from them. Again, of course, the German audio track in the second edition cannot be tested with Eac3to for the reason mentioned above.

However, for the German EAC3 track there are audio problems regardless of whether demuxing is done with eac3to or DGDemux.

Ditto. What "audio problems"? Nor have you told me if it occurs with and without gaps processing enabled in DGDemux.

So that you can understand the problem, you would also have to create a multi-edition mkv and play it with MPC-HC. The second edition must be selected.

To create such a multi-edition mkv file, you could use cE or MTX directly. To do this you would have to demux the video and the two audio tracks and then load everything into MTX and, very importantly, the Chapter.xml must also be muxed.

Sorry, I'm not going to involve cE. You have to demonstrate issues with DGDemux/MTX alone.

I asked you to make it easy but you're making me jump through hoops. Do this:

1. Tell what and how to demux.
2. Tell how to remux. Use MTX only, no cE.
3. Tell the resulting problem and how to see it.

The only problem I can glean from what you've said is some previous audio at a chapter. But cE is doing all kinds of magic with chapters. That's why I'd like a demonstration of the problem without cE. If you are trying to get a valid chapters file from a demux with -extras, I don't know offhand what that will produce.

I just read your two linked reddit threads and I don't see anything pointing to a DGDemux issue. The guy thinks it is a player problem.

I'll order the disk when you've addressed my points above.

Well, actually, I have no clue what goes wrong. Originally, as you have stated, I thought it is a player problem. I came to this idea because I had verified by hand that the chapter start and end times that cE had computed were exactly correct, that subsequent video frames had the expected distance in time (including video frames before and after gaps), and that the first video frame after each gap was a key frame (I-frame). So cE / DGDemux / MTX worked correctly, at least at first sight.

During further analysis, I noticed that the first audio frame in chapter 22 (in contrast to the first video frame) started 4 ms after the start time of chapter 22. Thanks to mkvinfo, it was very easy to see this. I am convinced that the player tries to fill those 4 ms, and the question now is from where it gets the necessary audio. Obviously, it must get it from the "previous" audio frame (or block). I can imagine (but don't claim any more) that this is where things go wrong.

From the player's perspective, when starting chapter 22, the "previous" audio frame may be the last audio frame of chapter 3 (910), because that's the last audio frame before chapter 22 in the *physical* file layout. Of course, the player instead should consider the last audio frame in chapter 21 (902) to be the "previous" audio frame.

Again, I don't claim anything, but I can imagine that there is a dumb logic in most players that finds the "previous" audio frame by seeing back in the file in a linear fashion until it finds an audio frame. This would lead to audio issues like the one we are talking about in case of non-linear "jumps" in the MKV, even when all demuxers and muxers would have worked perfectly and the MKV would be free of errors.

I really don't know what I have to make out of all of this, and I am thinking of backing up my Blu-Rays not as MKVs, but in their original form. That would cost me much more storage capacity, but eventually is better than MKV files with glitches. When the situation regarding the audio problems is resolved, I still can convert the Blu-Rays that are backed up on my HDD to MKVs.

Best regards, and thanks a lot!

[Rocky]

@hubblec4

For step 2, you said see above and above I see this:

"Then the three tracks are loaded into MTX and you also have to mux the Chapter.xml. There is an option to load a chapter file in the “output” tab in the mux settings."

So I load them and then just hit the multiplex button? It will automatically create a multiedition MKV? Guys, I don't know anything about ordered chapters or multiedition MKVs.

[hubblec4]

@hubblec4

For step 2, you said see above and above I see this:

"Then the three tracks are loaded into MTX and you also have to mux the Chapter.xml. There is an option to load a chapter file in the “output” tab in the mux settings."

So I load them and then just hit the multiplex button? It will automatically create a multiedition MKV? Guys, I don't know anything about ordered chapters or multiedition MKVs.

Please excuse me. Of course it should have been clear to me that you have little experience with this.

Yes, exactly right. Only adding such a Chapter.xml file changes the playback behavior of a player.

In the chapter file there are two editions (EditionEntry a master element) and in them are the chapters that tell the player where the start and end is. When this playing time has been processed, the next chapter comes.

And here it doesn't matter to Matroska and the players whether the next timestamp can be found somewhere else in the file.

[hubblec4]

I have an idea, I will upload a new Chapter.xml file where the second edition is the default edition.
This avoids to change the edition after start playback the file.

EDIT:

When you have the disk it would be the best when you share with me the two mpls file 00800 and 00801.
I can create an new Chapter.xml file.
This is maybe necessary because the disks not entire identical.

[Rocky]

I will use the chapter file made by DGDemux? Directly with no changes?

My plan is to recreate the problem first with DGDemux, and after that try the process with eac3to. If DGDemux fails but eac3to doesn't then I can binary compare the files, etc.

I ordered the disk but it doesn't arrive until Jan 29. If you want faster action consider uploading the disk for me. You could use my FTP or somewhere else.

One possibility: If I remember correctly, DGDemux does not do gaps correction on the final M2TSs given in the -extras option. I did that because I know they are not in playing order. I could make a build that does gaps processing for all the M2TSs for you to try if you like.

[Rocky]

I have an idea, I will upload a new Chapter.xml file where the second edition is the default edition.
This avoids to change the edition after start playback the file.

And now it seems I do not use the chapters file directly from DGDemux. I have to use a special one you give me?

C'mon! Give me a detailed accurate step-by-step to recreate the MKV with the problem. Honestly, I still have no idea what to do.

The disks are not identical??? Then why did you have me buy it? Did I just waste $30 for nothing?

I'm getting frustrated.

[hubblec4]

I will use the chapter file made by DGDemux? Directly with no changes?

The chapters of DGDemux are only available in OGG format, which means they do not have end times and this alone means that ordered playback is not forced in the player.
The chapters are just markers on the timeline of the entire file.

As far as I remember, no extra chapters are created for the attached m2ts files.

My plan is to recreate the problem first with DEGDemux, and after that try the process with eac3to. If DGDemux fails but eac3to doesn't then I can binary compare the files, etc.

Good plan.

I ordered the disk but it doesn't arrive until Jan 29. If you want faster action consider uploading the disk for me. You could use my FTP or somewhere else.

Yes until January 29th. Is it still far. Maybe it would actually be better if you uploaded the disc.

One possibility: If I remember correctly, DGDemux does not do gaps correction on the final M2TSs given in the -extras option. I did that because I know ther not in playing order. I could make a build that does gaps processing for all the M2TSs for you to try if you like.

Gap processing for all M2TSs sound great!

[hubblec4]

The disks are not identical??? Then why did you have me buy it?

I'm getting frustrated.

That was just a theoretical idea.

And even if these disks are not 100% bit identical, it's not a problem, really not. Please believe me.

[Rocky]

Give me a detailed step-by-step and tell me why you made me waste $30 on a wrong disk! Give me a link to the identical disk. Don't you know where you got your disk? Upload the damn thing for me if I can't buy the SAME one.

[hubblec4]

Give me a detailed step-by-step and tell me why you made me waste $30 on a wrong disk! Give me a link to the identical disk.

Can you cancel the order? I will upload the disk to your FTP.

[Rocky]

I'll try but I NEED THE STEP-BY-STEP PROCEDURE. Written so that a gorilla can follow it. Thank you.

EDIT: I was able to cancel the order. When you give the step-by-step, be sure to include the special chapter file. Thank you and forgive my frustration.

While waiting for that, I'll make the test version for you with gaps processing all the way.

[hubblec4]

I'll try but I NEED THE STEP-BY-STEP PROCEDURE. Written so that a gorilla can follow it. Thank you.

You are not a gorilla, you are one of the best programmers I know.

I guess the only problem is you have not much experiences with multi edition mkv's and the ordered chapters.
And I know only a few fans like me know how it works.

The step on your side is only to demux the video and audio tracks, add the tracks to MTX and add my chapter.xml.
You also test the chapters from DGDemux, and you will see the difference for playback.

You can open the chapter.xml file in MTX (but better is cE) and see what the chapters do.

[hubblec4]

EDIT: I was able to cancel the order.

I'm very very happy to read this. Let us make slowly, step by step.

First I will upload the disk. Is this the correct FTP link?
ftp.rationalqm.us

[hubblec4]

When you give the step-by-step, be sure to include the special chapter file.

Sure. It will be a pleasure for me the explain you a bit the multi-edition world of Matroska.

While waiting for that, I'll make the test version for you with gaps processing all the way.

Thank you in advance. Maybe is this already the key.

[Rocky]

Sure. It will be a pleasure for me the explain you a bit the multi-edition world of Matroska.

Please, no! I don't care about anything but simple do this, do that. Thank you for understanding.

[Rocky]

Here is the test build:

https://rationalqm.us/misc/DGDemux_hubblec4.rar

[hubblec4]

Sure. It will be a pleasure for me the explain you a bit the multi-edition world of Matroska.

Please, no! I don't care about anything but simple do this, do that. Thank you for understanding.

That's perfectly fine.
Nothing is further from my mind than boring people with topics.

I wouldn't then explain how the Chapter.xml works, and I hope that you trust me that these chapters were created completely correctly and are part of this problem.


Wow, so fast. I will download it and test it but this will take some time. Muxing the mkv's needs much time.

[Rocky]

I hope you meant they are NOT part of the problem.

I'm not optimistic it will change anything, because one or two gaps may not be enough to trigger any removal. Bear in mind that DGDemux and eac3to do things differently. I don't look for duplicated audio, just a threshold of desync. I don't even know what eac3to does!

Don't forget the disk upload. I don't see anything started yet.