Page 2 of 3
TrueHD+AC3 file gap processing?
Posted: Sun Mar 20, 2022 5:56 pm
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
TrueHD+AC3 file gap processing?
Posted: Tue Mar 22, 2022 5:08 am
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.
TrueHD+AC3 file gap processing?
Posted: Tue Mar 22, 2022 7:29 am
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.
TrueHD+AC3 file gap processing?
Posted: Tue Mar 22, 2022 3:04 pm
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
TrueHD+AC3 file gap processing?
Posted: Tue Mar 22, 2022 3:25 pm
by Rocky
Still, we don't want other tools to do useful things that we cannot. I argue that it is not useful.
TrueHD+AC3 file gap processing?
Posted: Tue Mar 22, 2022 3:57 pm
by Guest
Single m2ts demuxing is "straight forward"
Multi m2ts is where it gets interesting
TrueHD+AC3 file gap processing?
Posted: Wed Mar 23, 2022 4:51 am
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?
TrueHD+AC3 file gap processing?
Posted: Wed Mar 23, 2022 8:54 am
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.
TrueHD+AC3 file gap processing?
Posted: Thu Mar 24, 2022 5:47 am
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.
TrueHD+AC3 file gap processing?
Posted: Thu Mar 24, 2022 7:23 am
by Rocky
That's what I was saying!
TrueHD+AC3 file gap processing?
Posted: Fri Mar 25, 2022 4:01 am
by von Suppé
You're right. Sorry, wasn't in sync here.
TrueHD+AC3 file gap processing?
Posted: Fri Mar 25, 2022 1:39 pm
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.
TrueHD+AC3 file gap processing?
Posted: Fri Mar 25, 2022 1:44 pm
by Rocky
Thank you,
nekno, and welcome to the forum. Great points. Really appreciate your test results too.
TrueHD+AC3 file gap processing?
Posted: Sat Mar 26, 2022 1:20 am
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.
- 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.
- 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.
- 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.
TrueHD+AC3 file gap processing?
Posted: Sat Mar 26, 2022 6:57 am
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.
TrueHD+AC3 file gap processing?
Posted: Sat Mar 26, 2022 1:49 pm
by nekno
Got it, that sounds great — thank you!
TrueHD+AC3 file gap processing?
Posted: Wed May 25, 2022 10:25 pm
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
), 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!
TrueHD+AC3 file gap processing?
Posted: Thu May 26, 2022 6:41 am
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?
TrueHD+AC3 file gap processing?
Posted: Thu May 26, 2022 10:27 pm
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.
TrueHD+AC3 file gap processing?
Posted: Fri May 27, 2022 12:58 am
by Bullwinkle
Please give us a link to purchase that exact same disk.
TrueHD+AC3 file gap processing?
Posted: Fri May 27, 2022 5:57 pm
by BDgeek2
TrueHD+AC3 file gap processing?
Posted: Fri May 27, 2022 6:05 pm
by Bullwinkle
Thank you. Disk ordered, arriving tomorrow.
TrueHD+AC3 file gap processing?
Posted: Sat May 28, 2022 9:43 pm
by Rocky
Problem duplicated with 00221.mpls. Investigating...
TrueHD+AC3 file gap processing?
Posted: Sat May 28, 2022 10:24 pm
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.
TrueHD+AC3 file gap processing?
Posted: Mon May 30, 2022 8:45 am
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.