DGDemux development

[renols]

Hi.

This sounds really exciting.

As far as I can tell the duration of a major and a minor is the same, 8,3 ms. If Mike sometimes remove a minor as well, that might be the reason for the pops mentioned? I am not sure how much must be missing, before it becomes audiable noticable.

Are the two majors both at the start of the new m2ts file, or is one major at the end of one m2ts file and the seconf at the start of the next m2ts file?

Anyway, I am just happy that it seems like we might be reaching the final goal

Next will be to test with that 130+ m2ts Monsters Universe title I guess, and see how that pans out.

renols

[Rocky]

Good morning, renols.

TrueHD frame duration is 0.833 milliseconds. I don't understand the cause of the reported pops with MakeMKV. It may be something else, not even MakeMKV-related.

Pretty sure the first major of a double is at the end of the M2TS. I'll verify that when I get going this morning. I'll also test MONSTERS.

[Rocky]

I checked a handful of randomly selected M2TS files and here is the scoop. All the doubles appear at the start of the M2TS. The doubles are not split between files as I had hypothesized. Fortunately that does not affect our strategy of deleting the first major of doubles. Here is the start of CARS_2 00056.m2ts:

+ 35159
+ 35200 *
- 35240
- 35280
- 35320
- 35360
- 35400
...

Why is it like that? Beats me. Not all the doubles have timestamps that close, BTW.

Next I will double check things on MONSTERS. Then I will implement it in DGDemux/DGIndexNV. But first, Sherman is crying. I have to go find out why. Be kind Bullwinkle! One day Sherman will create a killer app.

[jj666]

Haha, yes, I have a very old license from DGNVDEC from I think 10 years ago, and I didn't remember the old neuron2 forum being so much fun with mooses and stuff (was not so active, but read quite a bit) . Was just curious...

Cheers,

-jj-

[Rocky]

Sherman threw a tantrum because his code did not work. Turned out he had an = where he needed an ==. Rookie mistake!

[Rocky]

Oy, oy, oy, guys. MONSTERS failed the ffmpeg test. Everything looked good. In-sync, first majors of doubles removed. Correct duration. But transcoding failed.

I did a lot of googling on this and stumbled on this thread:

https://trac.ffmpeg.org/ticket/6375?cve ... um_hist=10

These are "normal" source files not edited with deletions. The final comment is:

"This bug is still present... 3 years later... ¿?"

Increasing the buffer size does not help.

Also see here:

https://superuser.com/questions/1450168 ... cm-or-flac

No answer. And there are other similar threads.

So what to do now? First I want to try MakeMKV on MONSTERS. I don't think I ever did that. If it is OK then:

* Try to emulate Mike's deletion strategy.

* Build ffmpeg and try to fix the bug.

If it is not OK (did domy test this?) then building ffmpeg will be unavoidable. I've been meaning to bring up a linux system for a while.

Is ffmpeg just broken? Should we be trying to hack around that instead of fixing it?

[domy]

MakeMKV 1.15.1's Monsters University THD stream transcodes without errors to flac, only warnings (typical lossless check failed).

Rocky, could you upload your truehd tool that shows input_timing and major/minor/double frames? I know that Toy Story 4 has two gaps where the audio frames do not overlap, and I'd like to see what that looks like on the THD frame level.

[Rocky]

MakeMKV 1.15.1's Monsters University THD stream transcodes without errors to flac, only warnings (typical lossless check failed).

Thank you. Confirms renols' report. I want to see the deletion pattern.

Rocky, could you upload your truehd tool that shows input_timing and major/minor/double frames? I know that Toy Story 4 has two gaps where the audio frames do not overlap, and I'd like to see what that looks like on the THD frame level.

Sure. Lemme get through my current test first. Have to clean it up a bit.

Ah, now you wake me up with this overlap idea. What do you mean by an overlap? Can you determine it with the timestamps? Or are you seeing it in Audacity?

[domy]

Saw it in Audacity. I could send you the two THD streams from the m2ts files, maybe? What do you need?

[Rocky]

I have uploaded the traces for MONSTERS. raw.txt is the raw unadjusted THD. makemkv.txt is the MakeMKV-demuxed THD.

Right click and save as. You can diff these two in Beyond Compare. Search down in the raw pane for *. You'll see all the ways that frames are deleted. It's not just the three I mentioned earlier! If anyone has any brilliant insights, speak up! Is there a pattern based on the timestamps?

http://rationalqm.us/misc/raw.txt
http://rationalqm.us/misc/makemkv.txt

domy, hold off on sending me anything right now. Please have a look at the traces and see what you think. I'll get the tool ready for you now.

[Rocky]

Please re-download truehd to get the tracing:

http://rationalqm.us/misc/truehd.exe

Example:

truehd file.thd >stamps.txt

max_length at the bottom is the size of the largest frame.

[Rocky]

The MakeMKV files are formally illegal, per the spec paragraphs 2.5 and 5.1, as renols pointed out.

Re-download raw.txt as it had wrong formatting because it was made with an earlier version of truehd.exe.

[Rocky]

Maybe we cannot delete majors that contain restart blocks.

Gonna add that to my trace.

EDIT: Paragraph 4.5.2. Every major sync frame must have a restart block. Still, worth checking.

[renols]

Hi.

I haven't had time to look at the two text files "raw.txt" and "makemkv.txt" until now.

Seems like makemkv removes the first major and the minor just before it, but only every second time there are two majors. And sometimes it just deletes a minor only.

The numbers are relative to the raw.txt file.

179530-179532 No change eventhough there are two majors.
278229-278231 Makemkv removes minor 278229 and major 278230.
583640-583642 No change eventhough there are two majors.
625983-625985 Makemkv removes minor 625983 and major 625984.
665573-665575 No change eventhough there are two majors.
723282-723284 Makemkv removes minor 723282 and major 723283.
788048-788050 No change eventhough there are two majors.
850912-850914 Makemkv removes minor 850912 and major 850913.
868580-868582 No change eventhough there are two majors.
879342-879344 Makemkv removes minor 879342 and major 870343.
896310-896312 Makemkv removes minor 896310.
921736-921738 Makemkv removes minor 921736.
939505-939507 No change eventhough there are two majors.
964281-964283 Makemkv removes minor 964281 and major 964282.

I Have only gone though about 20% of the file.

Not sure what makes Makemkv decide wether to remove minor+major, just the minor or sometimes not remove anything.

I can go through the entire file, to see if there is any pattern, but takes quite some time

renols

[Rocky]

Spent the night cruising moonbeams with the butterflies and zebras looking for inspiration.

https://youtu.be/1pkbD33CnsE?t=49

The story has a happy ending, but first let me respond to renols and then mention a few random observations.

Seems like makemkv removes the first major and the minor just before it, but only every second time there are two majors. And sometimes it just deletes a minor only.

Quite right. Suppose MakeMKV empirically concluded that the only way to remove frames without slagging off ffmpeg was to remove the minor-major pair. That would remove two frames when only one should be removed. Therefore, that must be done only every other double.

I got curious about the ffmpeg "lossless check" failure. Off to the spec. Whoa, it's shown in the format but the semantics description is missing. Google is baffled about it too. Assuming UHD bluray THD streams are fully kosher, if ffmpeg is emitting this error then ffmpeg itself must be broken in that regard. Also remember that the players don't seem affected by this "error". And all that "end of stream detected" nonsense. What is that all about? We can be happy that the decoder actually delivers PCM but who knows if it is lossless, given the lossless check failures?

Looking more at the spec you see that the block semantics are missing too. The crucial block header definition is missing. Probably this is proprietary and you'd need a license and a lot of $$$ to get this information. Maybe we could use the ffmpeg source code to infer some of this information, but how much could we trust it?

We see from specs and whitepapers that the prediction spans some number of samples, but we don't know if that crosses audio frames. To me it must, in order to take good advantage of correlation in time. So there are constraints on just deleting frames arbitrarily, for both majors and minors (keep that in mind below). As humble SW developers and end users we are all groping in the dark.

You know where we're going with this, right? Smart! Of course you are already thinking that instead of deleting the minor-major pair every other time, we should delete just the minor every time. It makes sense because the following major starts a new group of frames, breaking the prediction chain. It should be harmless to delete a minor at the end of a group. As for minors in the middle, it seems problematic to delete them, absent further details of the missing semantics.

Obviously, immediately upon waking and making my morning cuppa, I implemented this strategy with MONSTERS. I am happy to report total success. The corrected THD plays in sync throughout, is the correct duration, and plays happy with ffmpeg. In fact, it plays happier than MakeMKV because it does not generate the "end of stream detected" errors:

Code: Select all

[out_0_0 @ 0000022e1acff980] 100 buffers queued in out_0_0, something may be wrong.
[truehd @ 0000022e1ad86a00] Lossless check failed - expected 00, calculated 45.
[truehd @ 0000022e1ad86a00] Lossless check failed - expected 00, calculated 06.
[truehd @ 0000022e1ad86a00] Lossless check failed - expected 00, calculated f4.
[truehd @ 0000022e1ad86a00] Lossless check failed - expected 00, calculated 6e.
[truehd @ 0000022e1ad86a00] Lossless check failed - expected 00, calculated 9b.
[truehd @ 0000022e1ad86a00] Lossless check failed - expected 00, calculated 2e.
[truehd @ 0000022e1ad86a00] Lossless check failed - expected 00, calculated bd.
[truehd @ 0000022e1ad86a00] Lossless check failed - expected 00, calculated 5c.
[truehd @ 0000022e1ad86a00] Lossless check failed - expected 00, calculated 32.
[truehd @ 0000022e1ad86a00] Lossless check failed - expected 00, calculated 16.
[truehd @ 0000022e1ad86a00] Lossless check failed - expected 00, calculated 90.
...until completion...

The resulting FLAC file plays normally.

Next step is to get a test version of DGDemux out there implementing this strategy for user testing. I will try to get that done today. Maybe first test on CARS_2 before doing that.

Have we completed the final chapter of the story?

[Curly]

Looking good, Rocky. Let's see how it plays out.

About the lossless check failures, maybe it's simply caused by the deleting of frames. It's no longer lossless to the source because frames were lost, nyuk?

But then you'd not have these errors when decoding the THD straight off the disk. But the errors do occur in that case.

Maybe this check is an optional kind of thing coordinated between the encoder and decoder. Wish we knew the semantics.

If we had a THD stream and its PCM we could check whether ffmpeg is correct. Does ffmpeg fail lossless on its own THD encodings?

So many questions. I tried to think but nothing happened.

[Rocky]

The new strategy works just fine on CARS_2. Hoping for a fixed DGDemux later today. Wheee.

[WGZ]

Hello everybody,
I'm new here.
I just installed DGDemux on my pc and everything is fine.
Now I wanna try it on another machine, a server with Windows Server 2019 on it, and when I launch the program, it hangs indefinitely, without showing nothing. (I tried to "execute as admin").
Meanwhile I already updated Windows, I installed the latest .Net framework and the latest VisualC Redistributable, but nothing changed.
Any suggestion ?

Thanks in advance.

[renols]

Hi.

This sounds great.

Some of the problem as you say, is that some of the tools we use to test this, we have no idea if they actually contain some errors, that misleads us in some way.

The output from the truehd.exe program, made it look quite obvious what was happening. Not why though.

How do you get the thd file from makemkv? Do you use mkvextract, to extract the truehd stream?

We need to test this as much as possible, and check the audio at each split to make sure it plays fine. Since you have already tested it on Cars 2 and Monsters Universe, I hope that our tests will do nothing else than confirm that it works

This TrueHD stuff seems to have baffled many in the past. Looks like when seamless branching was first introduced, a lot of HW players had issues playing the TrueHD track, and HW had to be replaced to fix it.

Guess we will have some testing to do.

Will be great if you have finally nailed it.

renols

[Rocky]

Now I wanna try it on another machine, a server with Windows Server 2019 on it, and when I launch the program, it hangs indefinitely, without showing nothing.

The machine has to support all the APIs that DGDemux uses for security. I do not have time nor money to investigate Windows Server machines. If you search the forum you can find a tester for that but all it will do is tell you what we already know.

[Rocky]

How do you get the thd file from makemkv? Do you use mkvextract, to extract the truehd stream?

Rip disk with TrueHD audio to MKV. Then demux the TrueHD stream from the MKV using DGIndexNV (no file gaps so no gap adjustment). Split the AC3 out separately or not, your choice.

[domy]

I've never gotten the "lossless check failed" warning on the original m2ts THD streams, so I'd say the warning is warranted. Do you have an m2ts where ffmpeg generated that warning?

I ran your truehd tool on Toy Story 4's 110.m2ts, where the start frame doesn't overlap with the previous streams' final audio frame. It doesn't look any different from other streams, and neither does 109.m2ts (the previous segment). Figured.

So the demuxed THD stream now keeps the double major frames of the individual segments, correct? I'm surprised ffmpeg doesn't complain about it, but it also shouldn't matter for decoding purposes.

How exactly do you maintain sync in the THD stream now? Do you simply delete a minor frame at every segment boundary, or do you somehow track desync with the video and delete minor frames as needed?

[Rocky]

Greetings, domy. Hey, what timezone are you in? Trying to determine when you are active.

I've never gotten the "lossless check failed" warning on the original m2ts THD streams, so I'd say the warning is warranted. Do you have an m2ts where ffmpeg generated that warning?

Without knowing the semantics, it's all speculation. I haven't tested individual M2TS files. Errors do occur with the full raw demuxed THD stream. You can get that yourself, no?

I ran your truehd tool on Toy Story 4's 110.m2ts, where the start frame doesn't overlap with the previous streams' final audio frame. It doesn't look any different from other streams, and neither does 109.m2ts (the previous segment). Figured.

That's where you can help us a lot. We need to know if and where there are any real audio duplications or overlaps and how they correspond to file gaps.

So the demuxed THD stream now keeps the double major frames of the individual segments, correct? I'm surprised ffmpeg doesn't complain about it, but it also shouldn't matter for decoding purposes.

Correct. Why should it complain? I haven't destroyed any groups or their prediction chains. I just truncate the previous group when a double major arrives. Theoretically, this new method delivers what you asked for...perfect sync!

How exactly do you maintain sync in the THD stream now? Do you simply delete a minor frame at every segment boundary, or do you somehow track desync with the video and delete minor frames as needed?

I do the former for now. There is always the option to use the Bresenham algorithm to determine when a frame needs deleting and then delete the next last minor of a group. Testing will tell us if that is needed. I suspect not.

[domy]

I'm on the Europe/Vienna time zone

So the demuxed THD stream now keeps the double major frames of the individual segments, correct? I'm surprised ffmpeg doesn't complain about it, but it also shouldn't matter for decoding purposes.

Correct. Why should it complain? I haven't destroyed any groups or their prediction chains. I just truncate the previous group when a new major arrives.

It's technically against spec 5.1. But ffmpeg doesn't complain, so it's almost certainly fine.

I will take a deeper look into the overlap situation. So far, for every m2ts I've looked at, the THD stream is half an audio frame or so longer than the video stream. It's not consistent and varies, so it's possibly designed to average out to a perfect sync if you delete a frame at every gap, but I'm not yet sure.

[Rocky]

Austria? Fine country. I learned to ski in Austria and lost my you-know-what there (such beautiful ladies). You guys are awesome skiers, unreal really.

I don't know either about the overlap. Empirically, deleting one frame per gap gives perfect sync.

Against spec, sure. But do we want a decoder to have to distinguish between file opens and continuously streaming multiple files. It would be pretty rude to bomb out because someone started streaming a new file.

Let's get a test version out and go from there.

Thank you for your testing and analysis, domy. Many will benefit and we are grateful.