www.makemkv.com

So I just got Attack of the Clones on 4K, and I can't get the 7.1 TrueHD audio stream to work. First I noticed it won't play at all in any media players, which i have never experienced with any of my other 4K films with Atmos audio. So I used Eac3to to extract the audio stream, only to get this error:

[21:49:47] The libav decoder reported error -1094995529 while decoding.a02
[21:49:49] Aborted at file position 1875116032.
[21:49:49] Error: [truehd @ 02543900] End of stream indicated.
[21:49:49] Error: [truehd @ 02543900] Lossless check failed - expected 00, calculated 87.
[21:49:49] Error: [truehd @ 02543900] End of stream indicated.
[21:49:49] Error: [truehd @ 02543900] restart header sync incorrect (got 0x180b)
[21:49:49] Error: [truehd @ 02543900] too many audio samples in frame
[21:49:49] Stream Extraction Completed

^I know that part in particular has nothing to do with MakeMKV, but I was hoping perhaps someone here would understand what this means. I also did get an error message in MakeMKV, saying something like "AV synchronization issues detected"... I read that that is just a bug in the latest version, but it's possible that there was an actual issue in this instance.

Did you use version 1.15.1 to make MKV file?

mike admin wrote: ↑

Thu Apr 16, 2020 9:32 am

Did you use version 1.15.1 to make MKV file?

Nope, but someone mentioned that right after I posted this yesterday in another thread; I'll be using 1.15.1 today to re-rip!

OK, so does this mean that potentially every MKV file created with the older version 1.15.0 has a corrupted TrueHD/Atmos audio track? Something like this is mentioned in the 1.15.1 bug fixes, afterall.



Can we please get some more info about this *very concerning* issue from mike admin? Which streams exactly are affected? And how can this be checked or even repaired afterwards?

Thanks in advance.

Hello Mike,

Do you know if this issue was only present in more recent disks, or should all UHD disks with Atmos be ripped again?
Is there a way to know whether Atmos is properly ripped or not?

Thanks!

Deihnyx wrote: ↑

Sun Apr 19, 2020 9:59 am

Hello Mike,

Do you know if this issue was only present in more recent disks, or should all UHD disks with Atmos be ripped again?
Is there a way to know whether Atmos is properly ripped or not?

Thanks!

It will only happen on discs with seamless branching

Billycar11 wrote: ↑

Sun Apr 19, 2020 10:07 am

Deihnyx wrote: ↑

Sun Apr 19, 2020 9:59 am

Hello Mike,

Do you know if this issue was only present in more recent disks, or should all UHD disks with Atmos be ripped again?
Is there a way to know whether Atmos is properly ripped or not?

Thanks!

It will only happen on discs with seamless branching

Got it, so a UHD like Zootopia will have it. Pretty much a lot of Disney movies then.
Thanks!

How can be checked if a certain MKV file/TrueHD track is affected by this issue? Can this be corrected afterwards?

If you hear glitches at scene changes when playing Atmos audio, the MKV has the problem.

No, it cannot be corrected after the fact. You have to re-rip it.

No other, less time consuming way to check? Like a tool that checks for errors in the TrueHD stream?

I’ve been having issues with the new Star Wars discs Atmos tracks. Makemkv seems to have problems dropping the correct duplicate frames at segment boundaries.


I’ve been testing with the UHD of Rogue One. I’m using 1.15.1 to process, and it seems to be alternating between not dropping the repeated frame at one boundary, and then dropping both repeated frames at the next segment boundary. The overall track length is correct, but there are pops at all 20 of segment boundaries.


I’m having the same issues with the wrong repeated frames being dropped or retained for both the eac3 and standard ac3 tracks as well.

Maybe it's better to use v1.14.7 for now?

@mike_admin:

Can you confirm that this issue was introduced with version 1.15.0 or was this already present in older 1.14 versions as well? In other words, is v1.14.7 safe to use for seamless branching titles?

samtroy wrote: ↑

Fri Apr 24, 2020 2:16 pm

@mike_admin:

Can you confirm that this issue was introduced with version 1.15.0 or was this already present in older 1.14 versions as well? In other words, is v1.14.7 safe to use for seamless branching titles?

its not fixed in any version but 1.15.1

1.14.7 will have the problem

schorman (4 posts above) claims very detailled that he still has the issue with 1.15.1.

Hopefully mike can clear this situation up..