{"action":"closed","issue":{"url":"https://api.github.com/repos/mbunkus/mkvtoolnix/issues/2091","repository_url":"https://api.github.com/repos/mbunkus/mkvtoolnix","labels_url":"https://api.github.com/repos/mbunkus/mkvtoolnix/issues/2091/labels{/name}","comments_url":"https://api.github.com/repos/mbunkus/mkvtoolnix/issues/2091/comments","events_url":"https://api.github.com/repos/mbunkus/mkvtoolnix/issues/2091/events","html_url":"https://github.com/mbunkus/mkvtoolnix/issues/2091","id":255798982,"number":2091,"title":"mkvextract extracts strange relative position","user":{"login":"mkver","id":18448094,"avatar_url":"https://avatars1.githubusercontent.com/u/18448094?v=4","gravatar_id":"","url":"https://api.github.com/users/mkver","html_url":"https://github.com/mkver","followers_url":"https://api.github.com/users/mkver/followers","following_url":"https://api.github.com/users/mkver/following{/other_user}","gists_url":"https://api.github.com/users/mkver/gists{/gist_id}","starred_url":"https://api.github.com/users/mkver/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mkver/subscriptions","organizations_url":"https://api.github.com/users/mkver/orgs","repos_url":"https://api.github.com/users/mkver/repos","events_url":"https://api.github.com/users/mkver/events{/privacy}","received_events_url":"https://api.github.com/users/mkver/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2017-09-07T02:49:51Z","updated_at":"2017-09-07T11:40:29Z","closed_at":"2017-09-07T11:40:28Z","author_association":"CONTRIBUTOR","body":"Hello,\r\n\r\nas you know, the relative position should be counted from the position in the referenced cluster immediately following the cluster EBML-element (id+length) so that the position 0 is usually occupied by the EBML-id for the cluster timestamp.* That's how mkvmerge writes the cues in the file. But when one extracts them with mkvextract, it seems that mkvextract uses the position of the cluster as its reference point. Consequently the extracted numbers are bigger than the ones stored in the file. Is this intentional? (It might well be, after all the cluster position is relative to the segment start in the file and relative to the beginning of the file in the extracted cues.)\r\n\r\nGrüße\r\nAndi\r\n\r\n*: Except if there are CRC-32 elements. I actually don't know what the zero point is in this case."}}
{"actor":{"display_login":"mbunkus"}}