Support forum for DG Tools

My first short test was successful.
I have only a chunk of the Gladiator UHD disc, but I get the same stream size for the ES's as with my self created 99999,mpls.

Now it takes same time to code this in cE.

Many many thanks.

You're welcome. Let me know how things go.

If you like and it is not so much work, could you try that all m2ts files specified with the "-extras" switch are used only.
All m2ts from the mpls should be ignored.

With this behavior it would much much easier to implement everything,
because some things are already handled in cE.
For example the Angles: All Angles from an mpls are readed by cE and internal provided with the correct m2ts order.
I don't need to observe switches from other applications.
The same with the skip first and last m2ts, this is already handled while parsing the mpls file.

In any case, I would like to say a big thank you at this point.
It's a pleasure to work with you.

We use the disk CLPI files referenced by the MPLS to determine the available streams and their properties. We could still open the MPLS in the normal way but then just throw out the file list and replace it with your full list. But it's on you to ensure that the M2TS's you reference are correct for what we have parsed from the MPLS. Could that work? Realize that we are trying to avoid a big redesign to accommodate you. Ditching the MPLS open would be a big redesign.

Rocky wrote: ↑

Thu Jun 22, 2023 3:38 pm

We use the disk CLPI files referenced by the MPLS to determine the available streams and their properties.

OK.
I had already suspected that not only the mpls is evaluated.
cE only parses the mpls and also receives a lot of information about the streams contained.
I assume that there is more information in the CLPI, right?

Rocky wrote: ↑

Thu Jun 22, 2023 3:38 pm

We could still open the MPLS in the normal way but then just throw out the file list and replace it with your full list. But it's on you to ensure that the M2TS's you reference are correct for what we have parsed from the MPLS. Could that work?

I guess and hope it will work, because the good is that all used m2ts files for seamless branching or Angles have the same content and order of streams.
The Angles are a good example. There is only one mpls file but different m2ts maps, a prove that changing the order or appending is not a problem.
On top of cE's working chain are always MKVToolNix(MTX). "All" what is possible with MTX is provided by cE.
Appending m2ts files in any order is no problem for MTX, with the exception of removing the audio gaps.

Rocky wrote: ↑

Thu Jun 22, 2023 3:38 pm

Realize that we are trying to avoid a big redesign to accommodate you. Ditching the MPLS open would be a big redesign.

Yes.
I think all will work and there is no reason to remove mpls-opening.

OK, I'll do that.

Regarding audio gaps, I can't guarantee that it will do sensible things when the files are in arbitrary order. I can't see how it could be sensible but let's see.

CLPI describes the stream properties, such as frame rate, aspect ratio, etc.

Please redownload and test. I did minimal testing. It all seems rather pointless to me as the gaps processing is going to be nonsense with arbitrary file order, and if you disable it, you may as well use EAC3TO. Do you understand the process and why it is not sensible? I explained that earlier. At least with the first approach most of the M2TS files are still in order.

It may take several to many M2TS gaps to accumulate enough playback desync to require a correction. It only works if the files are in playing order.

I have tested the new version and previous one a bit more with Terminator 2 BD.
It seems it works with both versions.

But there is one issue with the newest version. DGDemux crashes but after all is finished.
The "Done!" output is send and all streams are demuxed.

I don't why but I thought: remove the m2ts from the first edition and use only the appended m2ts files.
There was no crash and than I added one by one m2ts files from the first edition.
A while I could add more m2ts files in front of the list(with the correct order), but after a specific m2ts file the crash occurs.

All this m2ts files are used from the first edition and matches with the mpls order for the m2ts files.

The DGDemux append-version works and there is no crash.

I can address that, but do you have any comments on the gaps correction matter?

Sorry to interrupt your idle chatter, but here it is. Allow users to upload their own emojis.

I would like a squirming maggot emoji and if possible a putrescent rotten flesh emoji. To each his own.

Granted, it's an interesting question.

Rocky wrote: ↑

Thu Jun 22, 2023 8:13 pm

I can address that, but do you have any comments on the gaps correction matter?

The audio gap correction seems to be working well, because all is in sync in my T2.mkv test.
I will make some more test at night, but I'm sure you have done it.

Was more interested in theoretical considerations, rather than an informal test of one disk.

We discussed this internally and here is what we are willing to do. The arbitrary order for everything is not going to be supported, because it is nonsense in the context of our gaps correction. We will support the main MPLS/extras approach. If that is still useful for you, we can proceed. Please advise.

Rocky wrote: ↑

Fri Jun 23, 2023 11:49 am

Was more interested in theoretical considerations, rather than an informal test of one disk.

OK. But I see no problem in theory with an arbitrary order. First, the order is not really arbitrary, because this makes not sense.
I'm carefully to set a logical order. All m2ts which are set for the first edition follows the correct order and all appended m2ts are also in it's original order.

Second, the order:
Of course, an order of content only makes sense for people if it is from beginning to end.
But such an order does not necessarily have to be observed from the point of view of bits+bytes. As long as removing the overlapping audio data works, everything is fine.

I had just finished another test.
I had demuxed T2 with eac3to and with the newest DGDemux version:
The finial mkv's plays both perfect and the chapter markers matches ever the same frames.

There are some differences for two Audio streams, but I don't know if it is a DGDemux fault.
The german DTS-MA ES is almost 12kb greater.
The english DTS-MA ES is 4kb smaller
And the french DTS-HR ES is equal
All other ES's have the same size

I think this could also be a fault of eac3to.
And what means "fault", as I know there is nowhere a perfect solution for this Audio overlapping issue.
But who knows, maybe works DGDemux better than eac3to.

I was about to repeat the test with DGIndexNV. To see how the "arbitrary" import of m2ts files works there.


Furthermore I had created a new mpls file for T2 which contains appended m2ts files to combine two editions.
DGDemux has no problems with this mpls. This shows me DGDemux can work with an "arbitrary" order, but it is a pain to create manually a new mpls to achieve that DGDemux uses my order of m2ts files.

Rocky wrote: ↑

Fri Jun 23, 2023 11:49 am

We discussed this internally and here is what we are willing to do. The arbitrary order for everything is not going to be supported, because it is nonsense in the context of our gaps correction. We will support the main MPLS/extras approach. If that is still useful for you, we can proceed. Please advise.

Oh no, that's very hard
But it is your tool, and I can live with your decision.
Yes, the appending feature is the minimum what we need to get multi edition mkv's. It is more work for me but better than nothing.

The DGIndexNV demux test for T2 is ready.

Video and Sub ES's are equal to DGDemux and eac3to.
The Audio ES's a bit greater as the DGDemux audio ES's.

The finial mkv plays also fine and the chapters at the correct points.

All three tools uses an algo to remove the audio overlaps and it seems all three work a bit different but the final result is for all fine.

hubblec4 wrote: ↑

Fri Jun 23, 2023 1:31 pm

better than nothing

In native colloquial English, this phrase has very negative connotations:

https://en.wiktionary.org/wiki/better_than_nothing

It's certainly not something you would say if you wanted to motivate someone. After all, why bother if it's only better than nothing? Native English speakers take it as "almost worthless". Here at DG Tools, we are not in the habit of spending time on things that are almost worthless.

The major raison d'etre of DGDemux is the robust audio gaps processing. Allowing an option that supports an arbitrary M2TS list will either: a) require gaps processing to be disabled, or b) produce erroneous output due to non-sensible gaps processing applied to files in non-playing order. So it's not going to happen.

Rocky wrote: ↑

Sat Jun 24, 2023 6:44 am

hubblec4 wrote: ↑

Fri Jun 23, 2023 1:31 pm

better than nothing

In native colloquial English, this phrase has very negative connotations:


https://en.wiktionary.org/wiki/better_than_nothing



It's certainly not something you would say if you wanted to motivate someone. After all, why bother if it's only better than nothing? Native English speakers take it as "almost worthless". Here at DG Tools, we are not in the habit of spending time on things that are almost worthless.

Please excuse me again, that was not my intention. I use often Google translater because my English is not so good.

It is really helpful to have this append feature.

I re-uploaded the first version (append only). If you plan to use it then it could be released. If not, why waste our time?

Yes I will use this feature.

Hi Rocky

It was easy to implement it in cE.
What is particularly great is that I no longer have to build file paths to the respective m2ts files.
The list for the m2ts files to be attached has simplified a lot.

Thank you very much and once again I apologize for conveying a bad feeling or spreading displeasure.

In German, "better than nothing" definitely means something positive. This expresses that an offer is sufficient and that one is glad to have received something.
In return, the other knows that the offer has been accepted and both are happy with it.

I was very shocked that things are different in English and I am aware that something like this can have bad consequences.

Don't worry, I understand. Let's give a little while for further testing before making a release.

Maybe I can finish a cE test version tonight.
This will not yet contain any DolbyVision functions, as I would like to wait to see if you change anything on the output of the file names.

It seems that if I specify a malformed string for the -extras switch, DGDemux crashes.
I initially made a mistake implementing it in cE and wondered why DGDemux crashed.

Can you give me the malformed option that led to a crash? Thank you.