Problem with multi-edition MKV creation

[hubblec4]

Made some progress. All below is for the DGDemux files.

I determined that the length of the audio artifact is about 75 milliseconds, which is consistent with my earlier claim that it couldn't be just a few milliseconds, and consistent with the information at the site I linked.

So I made a new chapters file that starts 00912 and 00913 100 milliseconds later than what the original chapters file from cE specified. Note that these correspond to 2 of the extra segments. I didn't do the first one (00910) because it's the first segment. Maybe I didn't need to do 00913 also, as it is a "hidden" chapter, whatever that means. Here is the modified chapter file:

https://rationalqm.us/misc/chapters_ch3 ... s100ms.xml

This plays clean for both editions and both audio streams. It does not affect audio sync. You do start the extra segments a bit late but as these are chapter points they are highly likely to be scene changes so nothing is noticeable. So a possible heuristic would be to add 100 milliseconds to the start of all of the extra segments. You could omit the first extra if it happens to be the first played segment. Maybe it could be an option for cE: turn on artifact prevention and specify a start delay in milliseconds. But see the last paragraph here.

I have downloaded the file and make some tests. And I can confirm that the Audio POP is gone.

IIRC, it was Shoespooner that earlier referred to such tweaking but claimed there are other problems with it. I'd be very curious to know what he was referring to. Our goal is to make a clean multi-edition MKV, and I argue that this heuristic does that.

The issue with shift the timestamps a bit (100ms) I'm very sure we "lost" 2 or 3 video frames while playback.
I'm testing this right now.

I'm going to continue trying to find out why the extra audio is so large when it should be only 1/2 of an audio frame on average, and one frame maximum. I'll look at segment start times and lengths to see if the substitutions for edition 2 are really the same for start time and length. If they differed it wouldn't matter for playing the bluray as it would use PTS timestamps, which are lost when demuxing.

My wild guess is, that the extra Audio is the issue. The video frames are always fine and we have perfect timestamps and the player jump to the timestamp plays the correct video frame but the audio frame is not the correct one , because the timestamp of the Audio is not correct.

Unfortunately, I have no experience with the said PTS timestamps from the Blu-ray. It would be super interesting to see how it looks and works.
I always only used the IN and OUT times from the mpls, since MTX apparently does it that way too.

[Rocky]

@ hubblec4

Does your timestamp generation properly take into account that an M2TS intime may not be 0?

I have ruled out a DGDemux role in generating the large artifact. That leaves three possibilities:

1. cE is making a false assumption or has a bug.

2. For a pair of M2TSs, i.e., the original one and the substitute, there is some relevant difference in start time and/or actual audio data. I am trying to rule out this possibility.

3. The MTX muxer is going wrong.

Yes, with the workaround, you lose a few video frames. It may be acceptable as it almost always happens at scene changes and only for the substitute files. It's better than POPs.

I haven't given up on getting to the root cause. Next I'm going to check that the timestamp really corresponds to the first video frame of the substitute file. If so that would prove it's the audio at fault and I would proceed with step 2 above.

[Rocky]

More progress. Looks like MTX muxing is the problem.

I made a linear MKV with no chapters. I demuxed from that MKV starting at 2:07:12.124 (chapter 22 start). Then I looked at the demuxed streams. The video started with the correct first frame. The audio started with the POP! So it is there in the MKV.

I walked through DGDemux while demuxing the transition into 00912. It performs no gap adjustment and simply starts demuxing from the start of 00912 with no issues. If we had too much audio in 00902 then the POP would occur in edition 1 also. Don't forget we get a POP with eac3to also in one case.

I believe this proves that the MTX muxer is going wrong in muxing with ordered chapters. I know that's not what you want to hear, but there it is.

One more interesting thing is that if you look at the multi-edition MKV with MTX Info tool and go to the cluster that starts at 2:07:12.124, you see that the video starts at that time but the audio starts later. There is no reason for that and just confirms for me that the muxer is going wrong.

For completeness one last thing I want to do is check that intimes for 00903 and 00912 are the same in their respective MPLS files. Maybe it's not necessary, though, because the video is obviously correct in both cases.

It might be worth running this by Mosu.

[Shoespooner]

I doubt that the POP I've heard is only a few milliseconds, or that a few milliseconds would be an issue. We detect the POP sound as a low tone, you claim to be able to recognize it as part of an explosion, but the shortest detectable tone, identifiable as a tone, would be on the order of 100 milliseconds.
https://sound.stackexchange.com/questio ... -human-ear

A quick remark: I was playing the cello for a long time at a semi-professional level. There are a lot of works that have sixteenth notes in an allegro or even presto; some people are able to play more than 16 notes per second on classical instruments that are clearly distinguishable by the audience

[Rocky]

And that is 62 milliseconds, not a few.

Please catch up on the thread before posting again. I deleted some of your content that just reiterated what we already discussed.

[hubblec4]

@ hubblec4

Does your timestamp generation properly take into account that an M2TS intime may not be 0?

Yes I know, and mostly the IN-time start not at zero. It seems that is normal that the IN-time starts with a few Blu-ray time ticks.

I have ruled out a DGDemux role in generating the large artifact. That leaves three possibilities:


1. cE is making a false assumption or has a bug.

Could be, but I'm sure cE calculate everything fine. Because all other multi-Edititon mkv's are working until these Blu-ray.

2. For a pair of M2TSs, i.e., the original one and the substitute, there is some relevant difference in start time and/or actual audio data. I am trying to rule out this possibility.

Sorry this is not fully clear to me, Google translate weird German.

3. The MTX muxer is going wrong.

Also possible, but rather unlikely.

Yes, with the workaround, you lose a few video frames. It may be acceptable as it almost always happens at scene changes and only for the substitute files. It's better than POPs.

Yes I know, but this is for some user not a good solution.

I haven't given up on getting to the root cause. Next I'm going to check that the timestamp really corresponds to the first video frame of the substitute file. If so that would prove it's the audio at fault and I would proceed with step 2 above.

Thank you for all your willing to find a solution.

I believe this proves that the MTX muxer is going wrong in muxing with ordered chapters. I know that's not what you want to hear, but there it is.

Yes I can't really believe this, because chapters are irrelevant for muxing video and audio data. You could also mux the mkv first without the chapters and add the chapters later , with MTX or cE or any other tool that can edit Matroska Meta data. The Chapters are also "only" Meta data and you can change/remove so often you want them and this will not have any effect to other streams, but it changes the playback of the MKV.


If we treat each edition on its own then no POPs can be heard at all M2TS transitions and this for both audio tracks, regardless of whether dexmuxt was done with eac3to or DGDemux.
My next test will be to generate both Editions separate with both audio streams using DGDemux.
And then I create an extra main-playback-multi-Edition.mkv where only there chapters are inside, no streams.

[Rocky]

Yes I know, and mostly the IN-time start not at zero. It seems that is normal that the IN-time starts with a few Blu-ray time ticks.

OK, good.

Could be, but I'm sure cE calculate everything fine. Because all other multi-Edition mkv's are working until these Blu-ray.

OK.

Sorry this is not fully clear to me, Google translate weird German.

It means:

M2TS intime as per MPLS 1 (edition 1) != M2TS substitute intime as per MPLS 2 (edition 2)
M2TS outtime as per MPLS 1 (edition 1) != M2TS substitute outtime as per MPLS 2 (edition 2)

...checked for all the extra M2TSs. I haven't checked it but it seems unlikely.

3. The MTX muxer is going wrong.

Also possible, but rather unlikely.

Sherlock Holmes said when you have eliminated all but one theory, the remaining one must be true. Perhaps we have not reached that point yet.

Yes I know, but this is for some user not a good solution.

Understood.

I believe this proves that the MTX muxer is going wrong in muxing with ordered chapters. I know that's not what you want to hear, but there it is.

Yes I can't really believe this, because chapters are irrelevant for muxing video and audio data. You could also mux the mkv first without the chapters and add the chapters later , with MTX or cE or any other tool that can edit Matroska Meta data. The Chapters are also "only" Meta data and you can change/remove so often you want them and this will not have any effect to other streams, but it changes the playback of the MKV.

Did you miss where I said I made the linear MKV without chapters and it had the POP. So I am not claiming it is due to the chapters. I think this could be a key observation.
EDIT: In fact this is not true, the linear MKV shows no artifacts.

If we treat each edition on its own then no POPs can be heard at all M2TS transitions and this for both audio tracks, regardless of whether dexmux was done with eac3to or DGDemux.
My next test will be to generate both Editions separate with both audio streams using DGDemux.
And then I create an extra main-playback-multi-Edition.mkv where only there chapters are inside, no streams.

OK, please keep me informed. I will continue investigating.

[hubblec4]

It means:

M2TS intime as per MPLS 1 (edition 1) != M2TS substitute intime as per MPLS 2 (edition 2)
M2TS outtime as per MPLS 1 (edition 1) != M2TS substitute outtime as per MPLS 2 (edition 2)

...checked for all the extra M2TSs. I haven't checked it but it seems unlikely.

OK, now it's clear to me. Could be interesting, but maybe it is not important because the player has to jump to a timestamp given by a chapter, and when all chapter times are correct I would not expect issues.

Sherlock Holmes said when you have eliminated all but one theory, the remaining one must be true. Perhaps we have not reached that point yet.

Yes, I like this. Sherlock Holmes is a genius.

Did you miss where I said I made the linear MKV without chapters and it had the POP. So I am not claiming it is due to the chapters. I think this could be a key observation.

Yes, I read that, but I probably misinterpreted it.

[Rocky]

Squirrels work best in the morning. I'll be back at it at 4:00am. Rodents don't give up easily.

[hubblec4]

Squirrels work best in the morning. I'll be back at it at 4:00am. Rodents don't give up easily.

Have a good night.

[Rocky]

Preliminary summary and conclusion

Five theories were investigated:

1. MTX muxing is faulty.
2. cE is faulty.
3. DGDemux is faulty.
4. The players are faulty.
5. Random access in compressed audio is the cause.
6. There are audio artifacts in the source Bluray streams.

1. MTX muxing is faulty.

After MTX muxing followed by demuxing with mkvextract, the muxed and demuxed streams are binary identical. Spot checks using the Info tool show no irregularities. The 4 millisecond audio offset at the start of chapter 22 is expected and simply represents the sync condition at that point (audio and video streams have different granularities). No related bugs have been reported for MTX by others. MTX muxing is not the cause.

2. cE is faulty.

cE is a relatively simple process. The author has thoroughly checked it. Spot checks of the generated timestamps show no discrepancies with the MKV timestamps as seen in the Info tool. cE is not the cause.

3. DGDemux is faulty.

The DGDemux demuxing operation was traced in the debugger and showed no issues. The MKV creation process was repeated by demuxing with three other demuxers: eac3to, TSMuxer (the M2TSs were binary joined to produce a single input file, as required by TSMuxer), and DGIndexNV. All three generated MKVs showed the audio artifacts. Contrary to my earlier report, in fact, when creating a linear MKV with no chapters, the audio artifact is not present at the start of 00912. No related bugs have been reported for DGDemux. DGDemux is not the cause.

4. The players are faulty.

Three players were tried: MPC-HC, VLC, and MPV. All showed audio artifacts. However, the pattern of artifacts (their occurrence in which edition and which audio stream) differed across players, suggesting that their implementation details are significant. Creation of a single edition MKV for 00801.mpls shows no audio artifacts. The players are not ruled out as a cause.

5. Random access in compressed audio is the cause.

The input audio streams were converted to WAV64 for muxing. The audio artifacts are still present.

6. There are audio artifacts in the source Bluray streams.

There is no evidence for this at this time. I have looked and not seen anything. The problem occurs only for the second edition of multi-edition MKVs. Tentatively, therefore, I conclude that the Bluray mastering is not the cause.

Unless further theories are proposed, the "Sherlock Holmes rule" leads us to conclude that the players are causing this issue. If that is true, creation of multi-edition MKVs will remain problematic in the absence of fixes to the players.

Your responses and proposal of additional theories are eagerly solicited.

[hubblec4]

What about the English DTS stream, which is correct when demuxing with eac3to but not when DGDemux is used for demxing.
Could you tell from this which audio data is too much for the DGDemux DTS stream?


-------------------------

I' had prepared everything for the test. I used version 1 (00800.mpls) to extract the audio tracks with DGDemux (the latest version that you made for me).

And now I clearly hear a very short cracking noise.
Then I opened the 00800.mpls directly in MPC-HC and to my surprise I could hear the same short cracking noise there too.
So I'm not sure whether my test will produce a meaningful result.

------------------------
Therefore I would like to add a 6th point to your list.
6. The Blu-ray is poorly mastered

[Rocky]

What about the English DTS stream, which is correct when demuxing with eac3to but not when DGDemux is used for demuxing. Could you tell from this which audio data is too much for the DGDemux DTS stream?

It's just that the demuxes are not binary identical due to different gaps processing. I don't know what you mean by "too much for DGDemux". It's not due to gaps processing. eac3to and TSMuxer also fail in some cases. Just because in one case one of them doesn't fail while DGDemux does is nothing to hang your hat on. The problem is quasi-random and I believe due to player deficiencies. If you still want to blame DGDemux, how about TSMuxer too? Turn off gaps correction for DGDemux and then show me how the demuxed streams are not bit identical to the M2TS content. DGDemux accurately demuxes the streams. The problem also occurs when gaps correction is disabled. Do you think that if DGDemux was broken we would not have heard loud complaints already, especially given it's widespread use?

Are you going to run around telling all the demuxer developers their stuff is broken? You're happy to believe the players are all perfect but you don't grant the same to the demuxers. And I've already pointed out that the players have different patterns of failures. If they were all perfect they would not differ like that.

There is no problem with DGDemux and I'm upset you claim there is at another web site, even without investigating properly. You did the same here in your first post. What if I went there and said cE is broken?

Therefore I would like to add a 6th point to your list.
6. The Blu-ray is poorly mastered

Without a proposed mechanism, it doesn't say anything. And what am I supposed to do about it? Anyway, there's no evidence of that being true. If you are saying there are audio artifacts in the source Bluray, then tell me how to see that. I've looked and not seen anything, much less a loud pop. I'll add it but you have to back it up.

Look, I'm sorry that multi-edition MKVs are problematic, and it must be sad for you, but it's not on me or DGDemux. I've spent many hours trying to get to the bottom of things and it is troubling that you dismiss my conclusion on flimsy grounds.

[hubblec4]

I am in no way blaming DGDemux, please forgive me if that came out wrong.

In my ignorance about the audio data, I only made assumptions and I'm actually sure that DGDemux does everything correctly because you examined it with so much dedication and couldn't find any errors.

That's why I had the idea that it might be the Blu-ray itself.

[Rocky]

Thank you.

Can you show issues with the Bluray itself, for either 00800.mpls or 00801.mpls? I'll look again.

You don't seem to want to even consider that the players may be at fault.

[SomeHumanPerson]

Then I opened the 00800.mpls directly in MPC-HC and to my surprise I could hear the same short cracking noise there too.

Sticking my nose in here, but combined with Rocky's comments above, this immediately suggests bad player handling of a very unlucky cut point on the Blu-ray. Not technically a "mastering error" unless the physical disc also fails (i.e. makes the noise) in a proper hardware player, but just "unfortunate" by coincidentally showing up some fault in how certain software players handle that cut.

Has anyone discussed this with the MPC-HC or LAV Filters dev(s)?

[hubblec4]

You don't seem to want to even consider that the players may be at fault.

I may not have said it clearly, but yes, in the end the players are probably the most important thing and they could very well process it incorrectly, absolutely.

Can you show issues with the Bluray itself, for either 00800.mpls or 00801.mpls?

I don't know exactly how to "show" it.

All I did is open the 00800.mpls file in MPC-HC. Then skip to chapter 22 and go back 5 seconds and play the video. I made the sound on my LogiTechZ5500 a little louder so that I could also hear quiet noises from the film.
And then I heard this cracking sound.

In order to make a truly correct statement as to whether something is wrong with the Blu-ray, it would have to be available as an original disc and play it with a PlayStation (or other hardware Blu-ray player).

---------------------
In any case, you helped me a lot and you also showed me how I could build a work-around for this problem in cE.

For me it would be completely fine if we mark this problem as solved.

[hubblec4]

Has anyone discussed this with the MPC-HC or LAV Filters dev(s)?

I got since years no answer from LAV when I ask for Matroska stuff.
clsid do only bug fixing and very small enhancements, so I guess multi-Edition stuff will be ignored.

[Rocky]

All I did is open the 00800.mpls file in MPC-HC. Then skip to chapter 22 and go back 5 seconds and play the video. I made the sound on my LogiTechZ5500 a little louder so that I could also hear quiet noises from the film.
And then I heard this cracking sound.

I'll check again. I did notice something like that but listening very closely it seemed to be good content. It's 00801 that I would have expected to have issues, though, rather than 00800. I can get the audio out and check it for syntax errors. It's surely a possibility. Is this the only known disk that has problems with multi-edition?

[Rocky]

I un-resolved this because I have a new idea that I'm going to test this morning. More later...

I can't let this go.

[Rocky]

Well I figured out cE. Looks like cE always puts the extra files at the end.

I am worried that the timestamps for the extras are beyond the claimed duration of the MKV. Could it confuse the player?

In the track selection dialog, is there a way to deselect all tracks so I don't have to uncheck all of them individually?

Is there a way to make just the chapter file and not do the demuxing and MKV creation?

[Rocky]

In Info tool for the multi MKV I see that the cues do not include the extra segments. So seeking to an extra segment may be an issue.

[Rocky]

I hope y'all haven't gone away for good. I have some important findings for you!

I can prove it's a player seeking problem, even without any chapters at all. It's trivially easy.

I even have a simple workaround to make multi-edition MKVs that doesn't lose any data or destroy audio sync!

[Rocky]

The method:

1. Demux 00800.mpls with the three extras using DGDemux as before.

2. Load the demuxed streams into MTX.

3. Set a delay of -5 ms for both of the audio streams. This not enough to be perceptible.

4. Load the chapter file from cE.

5. Run the multiplex operation.

That's it. Have fun. I have to go do some coaching. When I come back I'll explain the theory.

[hubblec4]

just came online and am reading everything you wrote. Please wait a moment.