ted423
Useac3to/eac3to 提取音轨问题
As this was another Disney UHD disc with seamless branching (notorious for remux audio OOS and video glitching issues) some detailed analysis was required of the output from various tools. This title has 54 m2ts segments requiring 53 'seamless' joins and as expected eac3to output concatenated all the duplicate TrueHD frames at each of the boundaries leading to a 45ms cumulative audio delay after the last branch. This isn't as bad as some Disney UHD discs but it's still more than one video frame of delay so certainly not acceptable. The MLP tool algorithm was implemented by MakeMKV a few versions earlier and the output from both tools is identical with only 4 cumulative extra duplicate TrueHD frames included (just over 4ms extra delay) compared to the correct target audio duration. The best result was achieved with DGDemux on this occasion with only 2 extra cumulative duplicate frames included (so 2ms total extra over the entire movie). DGDemux removed two extra duplicate frames at the 5min06sec and 45min57sec boundaries where MakeMKV failed to do so. However, no substantial jump in sample level occurred at those points sufficient to cause audible effect distortion. So MakeMKV output is acceptable this time but not as technically correct as the DGDemux output. Therefore DGDemux was used to create all the streams from the UHD disc source (eac3to was used for the regular Blu-ray commentary streams). Note that there are two time points (10min38sec and 11min22sec) that have hard-coded English subs for foreign dialogue. The Spanish playlist has them hard-coded in Spanish and it's unlikely Disney will release a version without hard-coded subs. The Spanish subs don't translate that dialogue.
@mitlearn 建议deew的音轨制作可以不用useac3to，可以考虑不用配图 dgdemux 或者 gmkvextractgui的界面都相对简单
3天前 eac3to进行了更新 https://forum.doom9.org/showthread.php?p=1968821#post1968821
但是目前不确定是否已经解决
by tebasuna51 Thanks madshi for that unexpected release to fix the most important UHD Blu-Ray problems. Like the sintax is the same can be used with my GUI UsEac3To v1.3.3 without changes.
Also the libdcadec.dll was updated but still don't support all DTS sources. But seems the EAC3 decode problems remain unsolved.
Like I say before the decoder problems can be solved if eac3to can use the last avcodec-XX.dll, avutil-YY.dll delivered with ffmpeg. That can solve the AAC, EAC3, DTS, ... decode.
About encoders the libFLAC.dll remain not updated and libAften.dll is obsolete. It is possible use the libav encoders? Can be solved with 'pipe' commands but libav encoders are there.
by madshi Updating libFLAC.dll should be easy. Unfortunately updating the ffmpeg dlls is not easy at all. Most of the dlls I'm using have a stable interface, which means you can update to a newer build without a worry in the world. However, with ffmpeg, updating is never easy. It could screw with everything. E.g. I've experienced in the past that the channel order of decoders changed from one libav build to another. The internal structures change for sure, which makes things more difficult for Delphi. So everything would have to be carefully retested from scratch. That's not something I can do atm. Changing to other decoders and/or encoders is even more time consuming. That's why I love dlls like libFLAC.dll and libDcaDec.dll because they make my life easy. Don't get me wrong, I think ffmpeg is a wonderful project. I just wish they offered a precompiled dll version with a stable binary interface, and with no funny unexpected changes like channel order reordering from one version to another, or other things like that.