TrueHD+AC3 file gap processing?

DAE avatar
Guest

TrueHD+AC3 file gap processing?

Post by Guest »

no truncate option
I found that the difference was about 2 or 3 ms the few times I checked. Not a biggie.
I just want the raw thd+ac3
no gaps processing and its close enough.
Besides, you can only get the actual thd+ac3 to sync if there was only one m2ts file
DAE avatar
von Suppé
Posts: 21
Joined: Mon Dec 06, 2021 3:16 am

TrueHD+AC3 file gap processing?

Post by von Suppé »

Nice to see that you're integrating thdmerge into DGDemux, Rocky.
gonca wrote:
Sun Mar 20, 2022 5:56 pm
Besides, you can only get the actual thd+ac3 to sync if there was only one m2ts file
In which case it maybe an option to directly extract the THD+AC3 "as is", instead of interleaving back together after demux. I wouldn't know whether that would take a second run or DGDemux is able to spit out both in the first go.
User avatar
Rocky
Posts: 3556
Joined: Fri Sep 06, 2019 12:57 pm

TrueHD+AC3 file gap processing?

Post by Rocky »

Thank you for your comments, gentlemen. Theoretically, if there is only one M2TS (or no gaps processing is selected) then re-interleaving would not be needed. However, with the current design (before these last changes) two passes would be needed, which is obviously not acceptable. It could be redesigned to extract everything at once but that is a lot of work that seems unjustified because only one M2TS is an edge case and no gaps processing is purely a debugging thing. So unless it transpires that the interleaving difference is significant, which is highly unlikely, we will go with the current solution.

Before thdmerge came along, eac3to was used to add an AC3 stream created by encoding from the THD. So eac3to must be interleaving as well. Nobody has reported any issues with that, so I consider it empirical evidence that the details of the interleaving are unimportant, as long as something reasonable is done. You could place all the THD frames followed by all the AC3 frames (or vice versa), but that would not be reasonable.
DAE avatar
Guest

TrueHD+AC3 file gap processing?

Post by Guest »

von Suppé wrote:
Tue Mar 22, 2022 5:08 am
Nice to see that you're integrating thdmerge into DGDemux, Rocky.
gonca wrote:
Sun Mar 20, 2022 5:56 pm
Besides, you can only get the actual thd+ac3 to sync if there was only one m2ts file
In which case it maybe an option to directly extract the THD+AC3 "as is", instead of interleaving back together after demux. I wouldn't know whether that would take a second run or DGDemux is able to spit out both in the first go.
If only one m2ts you can just use tsMuxer to demux the thd+ac3 file
User avatar
Rocky
Posts: 3556
Joined: Fri Sep 06, 2019 12:57 pm

TrueHD+AC3 file gap processing?

Post by Rocky »

Still, we don't want other tools to do useful things that we cannot. I argue that it is not useful. :scratch:
DAE avatar
Guest

TrueHD+AC3 file gap processing?

Post by Guest »

Single m2ts demuxing is "straight forward"
Multi m2ts is where it gets interesting
DAE avatar
von Suppé
Posts: 21
Joined: Mon Dec 06, 2021 3:16 am

TrueHD+AC3 file gap processing?

Post by von Suppé »

I wouldn't go spending a lot of work to change the design only because of one-pass processing ability. I already was very delighted when thdmerge.exe came into life. Rocky being busy now to build it into DGDemux is an extra treat of course.
Most important for me is that things are done right and I can trust the results. And if multiple passes still are required sometimes, so be it. It takes what it takes.

BTW having tested latest DGDemux_test I can confirm it's working perfectly. Still have to test authoring the resulting streams to bluray, burn to disc and see how my standalone BD player reacts. Where I'm confident already.

I hope you don't mind a question about delays in a THD+AC3 track. After demux, the name of the embedded ac3 track holds no delay value. Where both the thd+ac3 and thd track show (in this case) "DELAY 0ms". I thus assume the embedded ac3 has no delay too.
I admit never having payed attention to this. But is it possible that an embedded ac3 track has a different delay than the thd part?
User avatar
Rocky
Posts: 3556
Joined: Fri Sep 06, 2019 12:57 pm

TrueHD+AC3 file gap processing?

Post by Rocky »

They should have the same delay. I'll look into adding it to the AC3 file name. Me too, never paid any attention to it.

Thank you for your testing.
DAE avatar
von Suppé
Posts: 21
Joined: Mon Dec 06, 2021 3:16 am

TrueHD+AC3 file gap processing?

Post by von Suppé »

Rocky wrote:
Wed Mar 23, 2022 8:54 am
I'll look into adding it to the AC3 file name. Me too, never paid any attention to it.
Not at ease with it, I did a quick & dirty test to see how DGDemux would handle the names when a delay would exist for thd+ac3.

With tsMuxer I created a short BD with a 200ms delay for the TrueHD+AC3 track.
After running DGDemux on it, the thd and thd+ac3 track show 'DELAY 200ms' in their names. The embedded ac3 however does not, where I think it should.

Maybe confusion about embedded ac3 delay can be addressed to by always putting the value in it's name, whether it be zero or different. Just like you do with the other tracks.
User avatar
Rocky
Posts: 3556
Joined: Fri Sep 06, 2019 12:57 pm

TrueHD+AC3 file gap processing?

Post by Rocky »

That's what I was saying!
DAE avatar
von Suppé
Posts: 21
Joined: Mon Dec 06, 2021 3:16 am

TrueHD+AC3 file gap processing?

Post by von Suppé »

You're right. Sorry, wasn't in sync here.
DAE avatar
nekno
Posts: 3
Joined: Wed Mar 23, 2022 12:13 am

TrueHD+AC3 file gap processing?

Post by nekno »

Thank you for this. thdmerge is brilliant. It fills a gap the community has needed for a while, where we needed someone with the requisite skills to understand how to read the frame sizes and take your reasonable approach to interleaving the frames.

I’ve done some testing and verified streams output by thdmerge and remuxed into BDMV, m2ts, or ts container formats play back without issue on the Sony X700 UBP, from USB or network locations.

I also used eac3to to do its usual thing of interleaving a thd stream from disk with an ac3 stream encoded on the fly with libAften, then demuxed the ac3 stream and remuxed it with thdmerge.

The interleaving output is the same file size but isn't entirely identical between eac3to and thdmerge (comparing SHA-1 hashes), so the approaches do differ somehow, but since thdmerge appears to be working, it doesn't seem to be a material diff.
User avatar
Rocky
Posts: 3556
Joined: Fri Sep 06, 2019 12:57 pm

TrueHD+AC3 file gap processing?

Post by Rocky »

Thank you, nekno, and welcome to the forum. Great points. Really appreciate your test results too. :salute:
DAE avatar
nekno
Posts: 3
Joined: Wed Mar 23, 2022 12:13 am

TrueHD+AC3 file gap processing?

Post by nekno »

Integrating thdmerge into DGDemux with an efficient demux approach is another brilliant stroke.

For a different use case, I have a BD that's already been remuxed to mkv for storage, and now I want to remux back to BDMV for playback. The mkv may contain an ac3 stream, but I’ll never use it for playback, so I don’t care to demux and use it.

I just want to efficiently interleave the thd stream while it's being demuxed from mkv together with a 4hr silent ac3 stream read from disk.

Not wanting to bother you with my specific needs, I modified thdmerge to accept the thd stream from stdin, so thdmerge can be placed at the end of a sequence of piped commands, e.g.,

Code: Select all

eac3to file.mkv 2: stdout.thd | thdmerge -ac3 silence.ac3 -o output.thd+ac3 -t
I have it working, and using file hashes have verified the output of my modified version is identical to thdmerge 1.1 output.

But I have a few concerns.
  1. You generously shared the source, but the LICENSE file with DGDemux doesn't explicitly cover thdmerge, so I'm not sure what you intended as far as modifications and redistribution.
  2. I'm sure you have opinions on coding style and approach, and I really don't. I just made changes in a way I thought would be best. Aside from looping to accept a stream as it becomes available on stdin, the biggest change is requiring command-line switches for each parameter, so that the thd file can still optionally be passed as an arg and, especially because of the call to _unlink() that could accidentally delete an input file, so that I could make sure I was reliably handling a variable number of command-line args.
  3. It’s been 15 years since I last coded in C/C++ so I’m not confident in my approach. Even then, I wrote tools for Unix, so I'm no wiz with Win CRT APIs. If you or anyone is inclined to take a look at the changes the source is here and you can view the diff here.
User avatar
Rocky
Posts: 3556
Joined: Fri Sep 06, 2019 12:57 pm

TrueHD+AC3 file gap processing?

Post by Rocky »

Sounds like you are doing great, nekno! Balti told me all great things begin modestly, but then they grow and grow and pretty soon, Sherman is your uncle. Not!

The code is in the public domain so do what you want with it. I prefer you to rename things if you significantly change functionality. Something like NKthdmerge. We used to say it's a free country, but nowadays?

I'll try to find time to look at your code. Thank you for sharing your development.
DAE avatar
nekno
Posts: 3
Joined: Wed Mar 23, 2022 12:13 am

TrueHD+AC3 file gap processing?

Post by nekno »

Got it, that sounds great — thank you!
DAE avatar
BDgeek2
Posts: 18
Joined: Tue Jul 07, 2020 10:48 pm

TrueHD+AC3 file gap processing?

Post by BDgeek2 »

Hi Rocky!

Thanks again for the great tool that is DGdemux!

I have a question about a branched UHD title. I searched but didn't find anything about it.

I just tried demux Baywatch UHD (I know :oops: ), which has both the Theatrical and Unrated Cuts.

On the output of DGdemux, it's only producing a the THD track, but not the embedded AC-3. How can I get the AC-3 track too?
I'm sorry I might have missed on this info before.

Thanks a lot!
User avatar
Rocky
Posts: 3556
Joined: Fri Sep 06, 2019 12:57 pm

TrueHD+AC3 file gap processing?

Post by Rocky »

I tried a random disk with THD and it worked fine. What version of DGDemux are you using? Try re-downloading the latest version 61.

Does it happen with all disks with UHD or just this one?
DAE avatar
BDgeek2
Posts: 18
Joined: Tue Jul 07, 2020 10:48 pm

TrueHD+AC3 file gap processing?

Post by BDgeek2 »

Thanks for the reply Rocky!

I was using version 61. But anyway I downloaded it again, booted the machine and tested. Same result. Also tested with version 60.

So far, it's the only UHD that this has happend with. But I haven't tried many with version 61.
User avatar
Bullwinkle
Posts: 338
Joined: Thu Sep 05, 2019 6:37 pm

TrueHD+AC3 file gap processing?

Post by Bullwinkle »

Please give us a link to purchase that exact same disk.
DAE avatar
BDgeek2
Posts: 18
Joined: Tue Jul 07, 2020 10:48 pm

TrueHD+AC3 file gap processing?

Post by BDgeek2 »

User avatar
Bullwinkle
Posts: 338
Joined: Thu Sep 05, 2019 6:37 pm

TrueHD+AC3 file gap processing?

Post by Bullwinkle »

Thank you. Disk ordered, arriving tomorrow.
User avatar
Rocky
Posts: 3556
Joined: Fri Sep 06, 2019 12:57 pm

TrueHD+AC3 file gap processing?

Post by Rocky »

Problem duplicated with 00221.mpls. Investigating...
User avatar
Rocky
Posts: 3556
Joined: Fri Sep 06, 2019 12:57 pm

TrueHD+AC3 file gap processing?

Post by Rocky »

Until this disk for every THD stream I ever saw the first packet was an embedded AC3 packet. But on this disk the first packet is an MLP (TrueHD) packet. My code was assuming that the first one was always the embedded AC3. I knew about this assumption but as I said, every stream I ever saw confirmed the assumption. I have it patched and working but it's late and I want to do a full code review and regression testing before releasing a fix.

Thank you for pointing this out, BDgeek2.
User avatar
Rocky
Posts: 3556
Joined: Fri Sep 06, 2019 12:57 pm

TrueHD+AC3 file gap processing?

Post by Rocky »

Please re-download version 61 and test it. Didn't want to make a full release for this. I also slipped the fix into DGIndexNV and updated the included DGDemux.exe.
Post Reply