2013-12-20, 09:41
Hello. I speak for MakeMKV developers.
I believe the problem is how lacing frames are handled. In MKV audio tracks usually use lacing - several frames are packed together in a single block in order to save metadata overhead. Matroska spec doesn't regulate the maximum size per lacing block. mkvtoolnix has a hardcoded limit of 8 frames per block, while MakeMKV can produce much longer runs, up to 180 frames per block, limiting the block duration at 0.1 sec. Could it be that the splitter has an optimization that reads entire lacing block as a single packet when handling LPCM streams, as opposed to (correct) splitting a lacing block into hunderds of frames? If yes, then splitter could output a very long frames, and we could see the timecode drift up to 100 ms. Still, nowere near the reported 200ms though. The long lacing runs is the only problem I can think on top of my head. I've requested additional information on our forum.
I believe the problem is how lacing frames are handled. In MKV audio tracks usually use lacing - several frames are packed together in a single block in order to save metadata overhead. Matroska spec doesn't regulate the maximum size per lacing block. mkvtoolnix has a hardcoded limit of 8 frames per block, while MakeMKV can produce much longer runs, up to 180 frames per block, limiting the block duration at 0.1 sec. Could it be that the splitter has an optimization that reads entire lacing block as a single packet when handling LPCM streams, as opposed to (correct) splitting a lacing block into hunderds of frames? If yes, then splitter could output a very long frames, and we could see the timecode drift up to 100 ms. Still, nowere near the reported 200ms though. The long lacing runs is the only problem I can think on top of my head. I've requested additional information on our forum.
