A Chapter too far?

[ndjamena]

This was my first post on the MakeMKV Forum:

http://www.makemkv.com/forum2/viewtopic.php?f=1&t=5997

Dan corrected MetaX to properly handle chapters without End Times, so on the surface the fix would seem to be superfluous. However, if one person encounters a problem it's likely someone else will encounter the same problem as well. Personally, I've found this feature to be a godsend. I've written a powershell script to get MKV chapters via MKVExtract and convert them to a .ttxt I can feed to MP4box, without the End Time on the final chapter I'd have been forced to find the running time of the file myself and enter it manually. I've only recently discovered how to get that sort of file information into scripts automatically. Being the first time I'd been on the forum I mistakenly believed the responses I received were from the developers, it turns out Mike didn't participate in the discussion at all, yet apparently read it and realised the value of the request as it was implemented in the next update. I'm glowing at the moment so I'll hold back. It's nice when things work out.

Anyway, I noticed an addition long after I'd left 'ensures that chapter start times point to an I-frame'

I just ripped Buffy and have been entering the chapter names. I know Matroska doesn't allow for negative 'Audio Delays' and apparently the audio for the episodes begin BEFORE the Video. The result being rather then truncating the audio to fit Matroska Specs the delay is instead applied to the Video, meaning the first I-Frame for the video I'm currently looking at is at 80ms and according to MediaInfo and MKVMerge Chapter Editor the first Chapter starts at 80ms as well, rather than absolute Zero (0). It's something I can live with and I don't really mind, but I'm wondering if that's entirely necessary (for those of us with obsessive personalities).

[ndjamena]

Turning this into a more practical request, it seems if you set the first chapter to start at non-zero ie even just 00:00:00.080, and then attempt to play the resulting file in VLC, when you press the 'next chapter' button, rather than jumping to the next chapter from current playing position, VLC will instead restart the video (presumably at 80ms). This happens no matter how far into the video you've gone. That makes sense, 0-80ms exists outside the chapter system, since that's where VLC will start playback it can't track the chapters from there (without making 0-80ms a chapter in and of itself).

Edit: Is it obvious this thread is asking for the first chapter to always start at '00:00:00.000' (Absolute Zero)?????

[mike admin]

Edit: Is it obvious this thread is asking for the first chapter to always start at '00:00:00.000' (Absolute Zero)?????

This is configurable via profile, please see advanced subforum.

[ndjamena]

Ah!

I'm assuming your talking about this line:

Code: Select all

insertFirstChapter00IfMissing="true"

which isn't actually mentioned in the 'Conversion Profiles' thread. I had to look at my actual profile file to find it. If I set this to false that would just make things worse, no?

I have a tendency to add too much detail and confuse people so I'll try to summarise:

The Problem is this: MakeMKV is setting the beginning of the first chapter to the first I-frame of the video stream, yet sometimes the video stream has a delay on it so the first I-frame is not always at absolute zero in context to the file as a whole...

This confuses VLC.

[ndjamena]

I'm having trouble finding time-codes to put chapters on at the moment. AVIDemux is giving me time-codes that are 200ms off and FFInfo's output doesn't seem to match my understanding of what's happening so:

The Chapters from the First Episode of Buffy as shown by MediaInfo taken from a MakeMKV rip of the original Australian DVD release:

Code: Select all

Menu
00:00:00.080                             : en:Chapter 01
00:02:13.480                             : en:Chapter 02
00:03:03.200                             : en:Chapter 03
00:10:27.480                             : en:Chapter 04
00:12:02.640                             : en:Chapter 05
00:15:04.600                             : en:Chapter 06
00:18:34.360                             : en:Chapter 07
00:20:11.200                             : en:Chapter 08
00:24:30.520                             : en:Chapter 09
00:33:31.400                             : en:Chapter 10
00:35:22.720                             : en:Chapter 11
00:40:46.800                             : en:Chapter 12

Note the 80ms start time for the first chapter.

This is what MediaInfo says about the first Audio Track:

Code: Select all

Audio #1
ID                                       : 2
Format                                   : AC-3
Format/Info                              : Audio Coding 3
Format profile                           : Dolby Digital
Mode extension                           : CM (complete main)
Format settings, Endianness              : Big
Codec ID                                 : A_AC3
Duration                                 : 41mn 30s
Bit rate mode                            : Constant
Bit rate                                 : 192 Kbps
Channel(s)                               : 2 channels
Channel positions                        : Front: L R
Sampling rate                            : 48.0 KHz
Bit depth                                : 16 bits
Compression mode                         : Lossy
Delay relative to video                  : -80ms
Stream size                              : 57.0 MiB (3%)
Title                                    : Stereo
Language                                 : English
Default                                  : Yes
Forced                                   : No

Note the 80ms negative delay, which means it starts 80ms before the video.

This is how the cues start as seen through MKVInfo:

Code: Select all

(MKVInfo) |+ Cues at 1744274449 size 74494
(MKVInfo) | + Cue point at 1744274456 size 14
(MKVInfo) |  + Cue time: 0.080s at 1744274458 size 3
(MKVInfo) |  + Cue track positions at 1744274461 size 9
(MKVInfo) |   + Cue track: 1 at 1744274463 size 3
(MKVInfo) |   + Cue cluster position: 3770 at 1744274466 size 4
(MKVInfo) | + Cue point at 1744274470 size 16
(MKVInfo) |  + Cue time: 0.680s at 1744274472 size 4
(MKVInfo) |  + Cue track positions at 1744274476 size 10
(MKVInfo) |   + Cue track: 1 at 1744274478 size 3
(MKVInfo) |   + Cue cluster position: 136969 at 1744274481 size 5

The first cue point is at 80ms, which I believe would be the first I-Frame.

This is how the Clusters start as seen through MKVInfo:

Code: Select all

(MKVInfo) |+ Cluster at 3822 size 133199
(MKVInfo) | + Cluster timecode: 0.000s at 3830 size 3
(MKVInfo) | + Block group at 3833 size 8053
(MKVInfo) |  + Block (track number 1, 1 frame(s), timecode 0.080s = 00:00:00.080) at 3836 size 8047
(MKVInfo) |   + Frame with size 8040
(MKVInfo) |  + Block duration: 40.000000ms at 11883 size 3
(MKVInfo) | + Block group at 11886 size 17358
(MKVInfo) |  + Block (track number 1, 1 frame(s), timecode 0.000s = 00:00:00.000) at 11890 size 17348
(MKVInfo) |   + Frame with size 17340
(MKVInfo) |  + Block duration: 40.000000ms at 29238 size 3
(MKVInfo) |  + Reference block: 80.000000ms at 29241 size 3
(MKVInfo) | + SimpleBlock (key, track number 2, 3 frame(s), timecode 0.000s = 00:00:00.000) at 29244 size 2312
(MKVInfo) |  + Frame with size 768
(MKVInfo) |  + Frame with size 768
(MKVInfo) |  + Frame with size 768
(MKVInfo) | + SimpleBlock (key, track number 3, 3 frame(s), timecode 0.008s = 00:00:00.008) at 31556 size 2312
(MKVInfo) |  + Frame with size 768
(MKVInfo) |  + Frame with size 768
(MKVInfo) |  + Frame with size 768
(MKVInfo) | + Block group at 33868 size 14768
(MKVInfo) |  + Block (track number 1, 1 frame(s), timecode 0.040s = 00:00:00.040) at 33871 size 14759
(MKVInfo) |   + Frame with size 14752
(MKVInfo) |  + Block duration: 40.000000ms at 48630 size 3
(MKVInfo) |  + Reference block: 40.000000ms at 48633 size 3
(MKVInfo) | + SimpleBlock (key, track number 2, 3 frame(s), timecode 0.096s = 00:00:00.096) at 48636 size 2312
(MKVInfo) |  + Frame with size 768
(MKVInfo) |  + Frame with size 768
(MKVInfo) |  + Frame with size 768
(MKVInfo) | + SimpleBlock (key, track number 3, 3 frame(s), timecode 0.104s = 00:00:00.104) at 50948 size 2312
(MKVInfo) |  + Frame with size 768
(MKVInfo) |  + Frame with size 768
(MKVInfo) |  + Frame with size 768
(MKVInfo) | + Block group at 53260 size 596
(MKVInfo) |  + Block (track number 1, 1 frame(s), timecode 0.200s = 00:00:00.200) at 53263 size 587
(MKVInfo) |   + Frame with size 580
(MKVInfo) |  + Block duration: 40.000000ms at 53850 size 3
(MKVInfo) |  + Reference block: -120.000000ms at 53853 size 3

The frame at 80ms is inserted first, then the 0ms frame, then the 40ms frame.

I'm not sure what that means, I thought it was an open GOP but I've been told even open GOPs start with an I-frame. 0 and 40 might be null frames, but I'm not sure why they'd be inserted AFTER the first I-Frame. But, if I load this file into VLC, let it play a minute or so, then press the [Next Chapter] button playback will jump to the beginning of the video.

Skins had much the same problem, but the first season discs had all their episodes combined into single titles. I thought I'd be smart and split all the discs at once with MKVMerge by writing a powershell script the read the chapters, calculate which ones were most likely to be the start of a new episodes, then append all the discs together and split the entire thing so that they'd all have names ready for MediaCenterMaster to scrap with without me having to rename them. That grand idea fell to pieces when MKVMerge added the 2 leading frames to the end of the previous episode rather than keeping it with the episode it originally came with, and 3 frames of audio went with it. If that was an open GOP, then there was a major bug in MKVMerge, which is why I assume they must be null frames. I tried recreating the process more recently and it appeared MKVMerge kept the two leading frames this time, but cut the audio at the 80ms mark, maybe I just misunderstood what actually happened the first time.

I'd like to know what 0 and 40 are. FFInfo says the frame at 00:00:00.000 is an I-frame and the frame at 00:00:00.080 is a B-Frame, but if MakeMKV only sets chapters at I-Frames then that can't be right. If I remux the file with MKVMerge the first cue point remains at 80ms, I doubt both MKVMerge AND MakeMKV would both have the such an obvious bug, so it's possible FFInfo is either mixing up the Encoded order and display order or it's ignoring the 80ms delay and deciding the frame at 80ms marks absolute zero. Couple that with whatever the hell AVIDemux is doing and I'm left with no way of finding the actual time-code of any particular frame in the episodes affected by this anomaly, which means I can't correct my chapters and since I need to tell X264 to set I-Frames at the chapter points I can't re-encode them until I figure this out.

In any case, the first chapter starting at 80ms is confusing the latest version of VLC and making navigation via chapters difficult. But for now I'm stumped and can only try to find something else to do.