Certainly this sample file produces dropouts but it is not normal in other files: it must have something incorrect or very unusual.

Found it has many padding at beginning and triggers seek condition. This maybe can be improved but anyway MKV's must be created with proper tools that full supports seamless branching Blu-Ray's.

The thing is: in seamless branching Blu-Ray's TrueHD tracks can have an overlapping frame at the segment boundary. You cannot only joint segments to obtain correct file. Is need proper parse and remove repeated (overlapped) audio frames.

See this: https://github.com/domyd/mlp#faq

In any case, I don't know if the the problem in this file is due this because the padding is at very beginning of file although then there is also more padding than usual on 4 or 5 occasions but it does not reach the condition:

paddingRem >= MAT_FRAME_SIZE * 2

Seems for this particular file things are improved with this small change: thexai@7d4e4fc

I don't want to create false expectations, the problem still exists, the only thing that can be done is to make the gap less noticeable and instead of a long dropout it may be an almost inaudible click...

Test builds:

Windows x64
https://mirrors.kodi.tv/test-builds/windows/win64/KodiSetup-20240407-7d4e4fc9-thd-Omega-x64.exe

Android ARM64
https://mirrors.kodi.tv/test-builds/android/arm64-v8a/kodi-20240407-7d4e4fc9-thd-Omega-arm64-v8a.apk

Android ARM
https://mirrors.kodi.tv/test-builds/android/arm/kodi-20240407-7d4e4fc9-thd-Omega-armeabi-v7a.apk

Thanks thexai, I will definitely test this build and report back. I was aware of the TrueHD issues MLP solved and was under the impression MakeMKV's latest version fixed these problems and works similarly, which is what this source file is from. If you know a proper/better way to get the audio off the disc then it would be of great help to know so I can fix my backups accordingly.

Tried this fix very quickly, the RZ50 still gets the glitchy noise (likely still picking up the problem you mention still exists) but my other AVR seemed to play without dropouts, so initial findings seem positive, but also seems I need to find the correct way to produce the file as well.

2nd quick test went much the way of the first, except I had a dropout this time, but it does seem to be rarer.

Best I fix the file and try again so we can know for sure, albeit I did try latest MakeMKV/DGDemux about 2 weeks ago and that didn't help, so I don't know what to try next for that

There are many factors to take into account and at this moment I am not sure if our MAT packer implementation (which is the same as FFmpeg) covers all possibilities or in some cases (0.01%) it may generate a non-compliant bitstream. Assuming this happens, it must also be taken into account that some AVRs may accept it as correct and others may not.

In the next few days, I will do a deeper investigation and try to implement the cases that (I think) are missing. Basically, generating padding frames when the input time stamps indicate that there is a jump/gap in time. This can happen if the "bitrate is extremely low": that is, a few bytes of data have to generate audio that occupies several frames of 61440 bytes (20 ms).

In the sample file there are 4 or 5 occasions with padding of ~113000 bytes, this means that an input from an audio unit ~2560 bytes has to generate more than one MAT frame of 61440 bytes.

In other words: the AVR must continually be receiving data at the same rate even if there is no data in the compressed input to fill 24 audio units (or audio units are served "at low speed").

The standard case is just the opposite: 24 audio units of 2560 bytes generate a MAT frame of 61440 bytes. When some of the 24 audio units have less than 2560 bytes, padding is inserted to complete up to 61440 bytes (one MAT frame len).

The complexity is that padding is not inserted at end but distributed between TrueHD audio units…

700 bytes | padding | 250 | padding | 1500 | padding | 2560 | padding | …up to 24 audio units.

The final size is always 61440.

Yes there's always those fringe cases sadly that no ones knows about until it's encountered. Thank you for taking such an in-depth look into this issue though. I will keep using this test build until you have something else you want me to try.

If I have understood correctly, these tracks are having large amounts of padding in place of audio units, meaning one audio unit is having to make up for all of those missing units, and in this case the padding exceeds one frame length, so it is having to make up for more than one frame as well.

Not all seamless branched titles seem to have this issue, so I am wondering if it is due to the sheer amount of branches on Disney titles that causes them to be more problematic, or if they're doing something different with their audio files that causes issues.

New test builds based on open PR (totally different TrueHD MAT packer implementation):

Windows x64:
KodiSetup-20240414-c7606d4a-mat-packer-Omega-x64.exe

Android ARM64:
kodi-20240415-cf25cc4a-mat-packer-Omega-arm64-v8a.apk

Android ARM:
kodi-20240415-cf25cc4a-mat-packer-Omega-armeabi-v7a.apk

Note that sample file still have some small issue BUT I have played same movie Cars (2006) directly from UHD Blu-Ray structure .m2ts in Shield (TrueHD English track) and in same first minutes not has any issue (cut / dropout). Then my conclusion is that specific sample has something wrong, at least depending how AVR handles it.

Anyway the new MAT packer is an improvement because this same UHD Blu-Ray (Cars 2006) has issues with current MAT packer in master or Omega branch.

Thanks very much thexai, while there is still the occasional drop in my quick testing, it is much faster (almost unnoticable), and the RZ50 does not go into that glitchy sound at the usual points in Cars (2006) / Elemental (2023).

I expect the remaining problem is with the file itself, and I will try to run it via UHD Blu-Ray structure like you've mentioned to see if there's any luck there, as it seems current tools to MKV are still having some issues.

Small Update, curiosity led me to try using tsMuxer to change the MKV to a M2TS, and that M2TS did still cause issues for the RZ50 at the usual point, however after changing back to the original MKV, it got that glitch much earlier (where he says "I am speed" early).

In the above I tried those two MKVs back to back and it was fine, and when I closed Kodi fully and reloaded the original MKV first, it worked good again like the above, so seems other extensions / swapping extensions may be producing an issue as well

Using the UHD Blu-Ray structure as suggested also seems to run smoothly, given you've mentioned this UHD gave issues with the original implementation, it seems it was a combination of a Kodi and a file issue being experienced.

Thanks again for looking into this, and also so quickly, especially for a task as large as a whole new MAT implementation, truly amazing stuff. I think I may forward this onto MakeMKV forums to hopefully fix the file side of the problem.

More updated test builds in this forum thread (sync with final PR code):

https://forum.kodi.tv/showthread.php?tid=377117

Quick test still looks to work well, I have posted the issue on MakeMKV forums as well here: https://forum.makemkv.com/forum/viewtopic.php?f=6&t=33890