How to accurately verify the audio tracks demuxed from a bluray disc?

[yellowolf]

When demuxing some blu-ray discs (untouched or DIY), I find that the obtained audio tracks or subtitles shift from the original source, and the offsets have accumulated to an obvious extent at the part close to the end. So I want to verify the obtained audio tracks and subtitles accurately, to estimate whether the obtained tracks are credible enough by knowing their time shifts quantitatively.
At present, there is already an easy way for to accurately verifying demuxed subtitles, via the subtitle browser of potplayer. Firstly, play the original disc. Then add the demuxed subtitles to be verified. After opening the subtitle browser of potplayer, we can compare the timestamps of any sentence between the internal subtitle and the external one. My verification on many materials indicate that the latest version of tsmuxer works perfectly with a maximum time shift of only 1ms.
But I wonder an accurate verification method for audio tracks. What I do at present is judging directly by ears during playback. However, I can't discern them before the introduced time shifts reach a considerable degree.
Any help would be appreciated.

[Ghitulescu]

Maybe if you share with us how do you demux the BDs....

[yellowolf]

Originally Posted by Ghitulescu

Maybe if you share with us how do you demux the BDs....

tsmuxer, dgdemux, eac3to, and so on

[Ghitulescu]

You mean all of them give you bad results?

[yellowolf]

Originally Posted by Ghitulescu

You mean all of them give you bad results?

Sometimes some of them yield bad results , but not always. At least their yields are different from each other ALWAYS (observed by Audacity, similar to this post: https://forum.doom9.org/showthread.p...60#post1905060), so knowing which one is more faithful to the original material is really a problem.
Frankly speaking, I cannot draw a conclusion for these tools before finding a quantitative method to measure the gaps of the timestamps between a original BD and its demuxed audio tracks. Only after finding the aforementioned quantitative estimation method for subtitle tracks with the subtitle explorer of potplayer, I can say that the latest tsmuxer gives reliable results for demuxing subtitle tracks.
Could you give some more suggestion on the estimation method for audio tracks?

[Emulgator]

I would throw all available demuxers at the .m2ts.
Then I would compare the results across these various demuxers.
First by data size using windows explorer.
Second I would use a DAW, lets say audacity with ffmpeg.
Then I would check duration length and decoded waveforms visually and listen to the tracks.
Then I would report any findings to the coders of the demuxers.

[Ghitulescu]

I doubt it's an issue with any of them - there are zillions of people using them every day, including developers of new programs; if they were wrong, they would have noticed that.
When I asked, I was kinda expecting some unknown software companies...

[outgoing]

It's a good question, in some occasions, not too much, i have found that most of the programs with which i made the demux of the main movie .avc were not accepted in the main program to make the definitive remux and only the one generated (demux) by BDfix was accepted as valid to make the whole remux again. In theory, all of them were valid, but the programs do not accept all of them when processing the information. But as Ghitulescu said, in most cases they must be produced with a guarantee since no one has complained.

[Ghitulescu]

Subtitles can only be displayed by fps granularity. That could be anything from 20ms to 40+ (for 23.976). Audio is also hardware linked to itself (a silent gap between two packets of loud noise like explosions would be very bad). This is the reason why audio is left free to balance within certain limits ('unlocked').

What you describe is rather a wrong fps for the main movie.

Originally Posted by yellowolf

When demuxing some blu-ray discs ... the obtained audio tracks or subtitles shift from the original source,....

As long as I understand, the problem exists with something called seamless branching.
The only muxers I know can deal with it are: MakeMKV and MKVToolNix's mkvmerge.
So, they, probably, extract the BD streams perfectly.
At least, I think so and use them.

[Ghitulescu]

I don't think this is the REAL issue.

By DVD-comparison, no demuxer could cope with multi-angle or seamless-interleaving DVDs, yet none of them, even the earliest, ever had an issue with correctly demuxing the part they were asked to (yes, one had to select the angle or the story: theatrical, extended, director's cut, but after that the demux was correct).

Since each M2TS packet bears not only one but two timecodes, it should be no problem to have them arranged as they should be. And nobody ever complained to, here or in videohelp or elsewhere.

If you read carefully, it appers that this issue occurs also for home-brew BDs, which cannot be suspicioned of being seamless

My take, in the absence of any other material evidence, is that there is a mismatch of fps somewhere. Otherwise, small delays between the streams, caused by cuttings, are known to occur if no reencoding is used (one can only cut at packet boundaries, be they ac-3 or MPEG-2/VC-1/AVC, and these do not always correspond) - which should have been known by now.

[tebasuna51]

Originally Posted by SpasV

As long as I understand, the problem exists with something called seamless branching.
The only muxers I know can deal with it are: MakeMKV and MKVToolNix's mkvmerge.

To extract AC3 and DTS tracks the problem was solved by eac3to long time ago (2012): https://forum.doom9.org/showthread.p...94#post1600694

But with EAC3 and TrueHD tracks there are issues solved still in 2020.

Maybe a new soft 'mlp.exe' can solve the TrueHD extraction.

You can read also https://www.makemkv.com/forum/viewto...p=84453#p84453
And http://rationalqm.us/board/viewtopic.php?p=10841#p10841

I had a miss synchronization when remuxing Robin Hood 2010 2in1 2160p UHD BluRay HDR HEVC DTS-X (the director's cut) with eac3to and it was about 4-5 sec at the end of the movie.
There were no problems with mkvmerge and makemkv.

P.S. It turned out there is a demuxer:

DGDemux aims to correctly demux all elementary streams, subtitles, and chapters in proper AV sync from BluRay/UHD titles, including seamless branching titles.

[Ghitulescu]

I still don't think this is the problem the OP met.

I am one of the people that can sense 1 frame synch error, but I've seen in my life people that could not notice 2 seconds (those post-proc country music outside the studios, in the mountains etc., maybe you know other examples), or even bad interlacings (usually happening with amateur videos shown on some TV stations).

Anyway, THD overlapping of frames at joins is known, even tsmuxer drops if needed the duplicate. In order for audio to be shifted over 1 second it must be literally thousands of such joins (or thousands + 1 M2TS files), or correspondingly less for a keen ear.

Secondly, this only happens with certain movies and ONLY with a certain audio, not with all, and not with subtitles, not with homebrew movies (there is no consumer THD encoder and there is no THD-enabled camcorder; there is no THD stream anywhere on satellite, terrestrial or cable stations).

It must be a serious and constant/repetable delay in audio and subtitles for one to reach the conclusion that something is wrong. I mean: to reach the conclusion that it's not a particular movie but the tools are unreliable.

This is one of these philosophical questions with no immediate gain to the OP. An ancient proverb said one fool drops a stone in the lake, 10 wisemen cannot take it out.