Sherman wrote: ↑

Sat Sep 07, 2024 2:21 pm

Not quite. They are both reported separately, just as for EAC3/AC3.

You are right.
So far is all working now, maybe I can provide the new cE version this month.
Many many thanks to you for all your help.

For TrueHD it's more accurate to say that THD and AC3 are merged (hence the utility thdmerge!) rather than embedded. So if a pusi doesn't pass the TrueHD test then it falls into the AC3 test and gets caught there. Thank you very much for the explanation, now everything is clear. By checking for Tru...

Hi Sherman Your source code is very easy to read because it is clearly structured. That makes it easy for me to understand everything. I like the new way of skipping the PES_HEADER bytes. OK, all the bits/bytes for the audio codecs mean nothing to me of course. I have a question about the detection ...

This looks very good once again. Thanks very much.
A lot has changed there, but I'll figure it out.

Sherman wrote: ↑

Wed Sep 04, 2024 7:18 am

For now let's stick with your empirical finding. We can come back to it if needed.

Good idea.

Sherman wrote: ↑

Wed Sep 04, 2024 7:18 am

I'll get busy on number 2.

Many thanks for all your work and time.

You can have PTS without DTS but not vice versa. .... You don't care about video. Great! That means all sorting can be ditched. Yes, TrueHD has major and minor frames but no re-ordering is involved, i.e., sorting is not needed. OK, that is great. So I can remove the sorting option which should impr...

So the question is whether I even need to parse the durations if the duration can also be determined using the PTSs. Do you think that still makes sense? Rocky (who used to work on set-top box backend HW/SW) told me there is a wrinkle involved. Since presentation times are evenly spaced, it is not ...

Please get main4.cpp from my misc directory as before. ... Many thanks. I'll take a closer look at it in the next few days, but my first look tells me it shouldn't be difficult. If you have doubts about getting duration for other audio formats lemme know. When you have absorbed this I will move on ...

Thank you Rocky.
I have now asked Sherman for deeper parsing.

Hi Sherman I would like to ask for your help again. It is better to distinguish whether the PTS belongs to the embedded part or not. Because with TruheHD it is not just duplicate time stamps. And if it is not too much trouble, I would also like to deal with the parsing of the audio frame durations (...

Hi Rocky I have a question about E-AC3. OK, you're going to have to parse deeper in some cases. I'll give the access unit duration in seconds. EAC3: // Assumes 48K sampling! switch (numblkscod) { case 0: duration = 0.00533; break; case 1: duration = 0.01067; break; case 2: duration = 0.016; break; c...

Found directly isn't quite right.
I simply muxed an m2ts with PCM to Matroska and then looked in the MTX info tool to see what value it had.

Rocky wrote: ↑

Thu Aug 22, 2024 1:25 pm

I'll try to get the values for LPCM. Which bluray is that?

I have found a FPS value for PCM, it is 200. 5ms Frame duration.
Has LPCM another FPS value?

Rocky wrote: ↑

Thu Aug 22, 2024 1:25 pm

I'll try to get the values for LPCM. Which bluray is that?

I have found it.
Public Enemy (Staatsfeind Nr.1).

Maybe it's a language issue but you said "whenever seamless branching discs are involved, regardless of the format (single or multi m2ts files)" which implies a seamless disk can have a single M2TS. But then you say "as soon as more than one Playitem is used". In my simple squirrel logic that is a ...

Guys, it seems to me that Mr hubblec4 's advance is all about correctly transcoding (or more precisely remuxing ) from seamless branched bluray to MKV. The conventional approach is to demux with gaps correction and then remux to MKV. Mr hubblec4 's new approach avoids all that. Of course, it is a w...

About the Audio frame durations.

Do you have the value for PCM also?

I have one Blu-ray(single movie but it is splitted into 3 m2ts files) with a PCM track.

Yes, absolutely. As described above, the timestamp files could be used whenever seamless branching discs are involved, regardless of the format (single or multi m2ts files). ??? Seamless branching implies > 1 M2TS file, so I don't understand this. I always assume that as soon as content/data is to ...

I wasn't aware that you are interested only in multi-edition. Seems to me your new approach without demuxing could be equally valuable for single-edition. Since MTX only has problems when muxing seamless-branching discs, films that only consist of an m2ts are not really of interest. Because there a...

Yes, that's true. But as far as I understand, this only affects the first m2ts. So far, I haven't seen this behavior with seamless-branching material. Does the DG team perhaps have a Blu-ray where this is the case? Haha, you gave me one. Please recall COLUMBO from this thread: https://www.rationalq...

Because every m2ts always starts with a keyframe for video and audio and always at "0" Not following you. M2TS streams do not have to start at 0. Are you talking about something different from IN_time? I'm sure I didn't express myself very clearly here. If you look at each m2ts individually and ign...

Hi Rocky I was already thinking about asking you if you were interested in how this works. Because you could also offer this as an option in DGDemux. Unfortunately I haven't had much time in the last few days and didn't want to start the topic without being there when questions come up. First of all...

Since mkvmerge has a "terrible" append bug, muxing seamless-branching Blu-ray does not work correctly and it was always assumed that (madshi's)eac3to removes duplicate audio frames. Unfortunately, this is not true, because there are no duplicate audio frames. cE is now able to create a perfect multi...

For the moment it is fine. I delete/ignore the double lines.

I have a question about duplicate timestamps for some Audio streams. DTS-HD Master 0.000000 0.000000 10.666667 10.666667 21.333333 21.333333 32.000000 32.000000 42.666667 42.666667 53.333333 53.333333 64.000000 64.000000 and E-AC3 0.000000 0.000000 32.000000 32.000000 64.000000 64.000000 96.000000 9...