[fritsch]

Things has not ended yet

While in Free Guy the error is constant (with normal oscillations now attenuated with /2.25 factor) in Cars this error progressively increases... so with long playback duration 10 min - 20 min reaches the threshold  and corrections (frame skip / audio dropout happens again).

Graphics are 20 minutes playback time:







Even that, correction factor seems a valid improvement in all cases although something more will be needed for Cars.....

AE never forgets and never forgives, it accumulates. We need to find a way that it gets a variable factor to the integral, which says: real PCM delay vs accurate truehd delay. Currently every package is creating and error. Halfing it won't really work. It is not so easy cause audio clock expects constant PTS over time.

[jogal]

The previous post was with maxpassthroughoffsyncduration = 96 because I had changed it before and it had stayed the same but with 62 value things changes a lot.

Accumulated error problem is gone:




Also in Free Guy constant error is reduced (-30 vs -60):



With the only change 96 to 62, dropouts in Cars in minutes 10 to 20 has disappeared and error seems is stabilized around +40 ms (not continues increasing).

This is because when it reaches 62 it is corrected by skipping/repeating one frame while if it is allowed to accumulate up to 96 it is not possible because it would require skipping two frames and the algorithm considers it too destructive.... When the error reaches 100 is forced the correction by a different method that also involves the audio and the dropout occurs.

Conclusion: high maxpassthroughoffsyncduration values broke a/v sync adjust.

Conclusion 2: self-learning algo should be revised.

I also want to highlight that I have not noticed any anomalies in the video. If there has been a repeated frame, it has been very subtle or in a scene with little movement because I have not noticed anything in 20 minutes paying special attention. For me this is more than enough.

[Draconix]

Conclusion: high maxpassthroughoffsyncduration values broke a/v sync adjust.

On my Shield I need to use a high maxpassthroughoffsyncduration value or I will get lots of video stutters. Also some people are more sensitive to micro-stutters than others, there's a chance that it happened but you just didn't notice them. For me, I notice stutters very easily even when there's not a lot of movement.

If you need to make adjustments to the learning algorithm, that's fine as long as you keep the ability to set the advancedsetting up to 100 ms, because I definitely need it.

[RedTwenty50]

I am pretty sure that after Cars logo at 2:22 there is no audio drop - it is a pause/silent part in the actual song, just saying lol. https://www.youtube.com/watch?v=X3HlFewKByw 1:00 - 1:01

It is 100% an audio dropout for me, its very very noticeable and even makes a slight popping sound. I can immediately rewind it so that part plays without the drop, the difference is very obvious.

It is definitely an audio drop out as it happens mid-sentence for me, and in my case the audio doesn't come back without restarting the file.

In saying that, if I disable/enable passthrough via the video player menu, and then rewind, it'll play past that point just fine. I made my own fresh version using mkvmerge and the same thing happens with that file, so I think it may just be the way mkvmerge joins it.

[RedTwenty50]

Thank you for continuing to look into this issue Jogal, it would seem Cars is a very particular audio track and with Free Guy also a Disney title it does seem to point to something with their audio tracks.

Your fixes look to have fixed the randomness of the issues, as now the errors for me are pretty much at exact points and you may be on to something with  that 20 minutes sync issue you mentioned, as when I originally reported this issue, I found that the audio glitch the RZ50 would do was basically every 20 minutes in.

[RedTwenty50]

@Draconix I am curious to know the timestamps of your audio drops to see if the points in mine are the same, as that may point to something too.

I otherwise did some more testing today using the same 5 minute section, making fresh MakeMKV and MKVMerge versions of Cars using their latest versions, alongside the disc files themselves and found that:

• MakeMKV: Same issues as my sample
  
• MKVMerge: Same cutoff's as jogal sample
  
• Disc files + 62 maxpassthroughoffsyncduration: No issues asides a one second drop at 3:23 when the blue car revs into frame
  

At first I was thinking the disc has an issue, or as jogal mentioned, maybe the bitstream generated is not compatible with some AVRs, but the disc files had none of those issues so that seems to rule those out.

VLC working in previous tests reminded me of Kodi's RAW passthrough option (which I am aware has it's own issues) this option however, even with my problematic sample, had none of the issues mentioned.

Not sure how this information helps yet, but it makes things more interesting. Where can I find more on the issues the RAW option is having as I would like to read more on that?

[Draconix]

Your fixes look to have fixed the randomness of the issues, as now the errors for me are pretty much at exact points

These are exactly my findings as well. This new test build has completely fixed the random additional dropouts, but I still have the dropouts that always happen in the exact same spot each time. As you said, it appears that Disney does some shenanigans with their Blu-ray tracks... because everything else plays perfectly.

[jogal]

This build is different: is the old TrueHD MAT packer code but with new error compensation and max Out-Of-Sync improvements.

For me, in Denon, works better the new MAT code buy maybe for others AVRs is at contrary...

Anyway old MAT code has improved a lot due error compensation. Seems more important issues due the error oscillation that MAT code itself. 

ARM64:
https://mirrors.kodi.tv/test-builds/andr...64-v8a.apk

ARM:
https://mirrors.kodi.tv/test-builds/andr...bi-v7a.apk

Windows x64:
https://mirrors.kodi.tv/test-builds/wind...ga-x64.exe


This is also a important test for backport (or not) the others fixes to Omega ...

[Draconix]

This build is different: is the old TrueHD MAT packer code but with new error compensation and max Out-Of-Sync improvements.

For me, in Denon, works better the new MAT code buy maybe for others AVRs is at contrary...

This is definitely an improvement on my AVR, here's the log for Cars: https://paste.kodi.tv/xamubowiza.kodi

This is the first time that I didn't have the usual dropout right after the Cars logo! However there were still a couple dropouts towards the end.
I also tested Avatar... before it always had 2 dropouts (in the same spots) within the first 4 minutes, with this build there's only 1 dropout.

[earlgrey_44]

Another data point:

Haven’t learned to do logs yet, but a copy of Avatar TrueHD, running on Shield 2019 and Pioneer 503, shows no dropouts or stutters.

This with the latest version of 21.0.1 posted above three days ago.

[fritsch]

Another data point:

Haven’t learned to do logs yet, but a copy of Avatar TrueHD, running on Shield 2019 and Pioneer 503, shows no dropouts or stutters.

This with the latest version of 21.0.1 posted above three days ago.

Yes, that is the old packer with the relaxed "supervising" code. This will be in upcoming 21.1 stable version. It was already merged here: https://github.com/xbmc/xbmc/pull/25238

[RedTwenty50]

An improvement on my end as well, here is my log.

Got passed the Cars logo with the MKVMerge files (Jogal's and my own) this time too. Issues are still at exact points like with the new MAT packer build, so the randomness didn't return.

My new findings are as follows:
MakeMKV: No changes to previous build, still drops into the glitchy sound at 4:22 minutes in and then comes back to normal at 4:35 minutes in

MKVMerge: No longer a cutoff at the Cars logo, and the audiio keeps going now, but did get two drops, coinciding with the MakeMKV glitchy sound issue above, with a very short drop around 13:21:18 / 4:22 minutes in, and a normal drop around 13:21:30 / 4:34 minutes in on the log / in the movie respectively. The second drop has that glitch sound for the tiniest time right before the drop as well, so seems that drop is more problematic.

Disc files: Passes 3:23 minutes in with no issues too now, but rather than a one second drop, the audio cuts out where rewinding won't fix it at 3:53 minutes in

EDIT: The cutout for the disc occurs at the point 106/156.m2ts kicks in from the playlist, and the dropout for the MKVMerge files happens on the switch from 106/156.m2ts to 60.m2ts

[etgecata]

NVIDIA SHIELD pro 2019, Soundbar Samsung HW-Q950A

testing-Cars:
With the latest nightly (v21/Omega nightly)  build I don't have any outages.
With the previous test versions, I always had one break at the same place.

[jogal]

Updated the build of first post:

Is the NEW packer + a/v sync improvements in Omega branch.

v22 nightly is NEW packer + a/v sync improvements.

v21/Omega nightly is OLD packer + a/v sync improvements.

So, a/v sync improvements are merged and backported because improves both NEW and OLD packer. But the NEW packer code is not planned to backport to Omega because at least for 2 users seems is causing regressions. Those who are in this same situation can now use regular Omega nightlies.

In fact, the old packer seems to work fine with everything except Cars (2006), at least I don't have any other sample that fails. And the new packer fixes this (*) but not for everyone...

(*)

NVIDIA SHIELD pro 2019, Soundbar Samsung HW-Q950A

testing-Cars:
With the latest nightly build I don't have any outages.

[MrMagic]

@jogal I'm a little confused.

You're saying that the new packer code is not planned to be backported to Omega, but all three APKs in the OP are called MAT packer and have Omega in the name. Or do you mean that there is both old and new MAT packer code?