-
Notifications
You must be signed in to change notification settings - Fork 297
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
consider a default behavior of reading mkv tags after the first cluster if indexed in the seekhead #252
Comments
Similar may also happen for MP4 "moov atom". See also: |
Hi @MasterInQuestion, I agree that storing the tags at the front adds more advantages. I've been working with a lot of large files where the metadata will be edited. When the tags become larger, the editors will void the tags element at the beginning and rewrite it at the end (that's a lot faster than rewriting the entire file). So most matroska files that have been edited will have metadata (or chapters or attachments, etc) at the end. To partly work around this I may add more header space to the beginning of mkv by default to reduce the need to edit tags to the end. |
Low-level in the storage, perhaps not much difference. (implementation dependent) [1] Personally I tend to avoid metadata at all. (deeming which hardly interoperable; and at many times merely as side-channel of privacy leak) |
This is a good suggestion, but was a fair bit of work to implement. ExifTool 12.87 will seek past the first Cluster to read from the start of the Tags element if it is referenced in the SeekHead.
|
I understand that perhaps for speed that exiftool stops parsing at the first cluster; however as mkv is a fairly editable format, often chapters and tags are found at the end of the file.
Here are two samples:
tags_after_clusters.mkv.zip
tags_before_clusters.mkv.zip
With
exiftool tags_before_clusters.mkv
I can see the embedded metadatabut not in
exiftool tags_after_clusters.mkv
. I've been using-ee
as a workaround, but I think the tags element is pretty critical to a matroska file and if its position is clarified by the SeekHead so a parser doesn't need to do a long search for it, then I'd suggest including it in a preliminary parse on default.Thanks
The text was updated successfully, but these errors were encountered: