You are here

Tools Creating Bogus Files

mkvmerge produce good files. It's using the second part of the Meta Seek to define each Cluster entry. But it is putting Attachments at the front, which is not necesseraly good for streamed files (to avoid skipping over or reading a lot of unnecessary data like fonts).

FFmpeg both produce good files. It's using the second part of the Meta Seek to define each Cluster entry. Since it doesn't support Tags, Chapters and Attachments, it doesn't fail to place them in the optimum space...

Files created with the DivX Converter (libDivXMediaFormat 3.4.1.0004) has numerous issues:

The Meta Seek is referencing an entry with the ID [00][2A][D1][D3] which is an invalid EBML ID ([2A][D1][D3] would be the correct one) placed after the Cues, at the end of the file.

The video and audio track entries contain an EBML element with ID [C6] and a binary value of [00]. That EBML element is not part of Matroska.

The video and audio track entries contain a CueCodecState EBML element with ID [EA] which is not only is deprecated but is not part of the Track Entry but the Cues, the binary value is [00].

The video track has a StereoMode entry which is a deprecated element.

The muxer is only using the v1 version of the Matroska specs. Meaning there is no support for SimpleBlock that helps saving space for audio frames.

The muxer doesn't use lacing for audio frames, resulting in a lot of space wasted.

The EBML Master element sizes are always written using 8 bytes, where 1 or 2 may be enough.

The [2A][D1][D3] element at the end of the file is undocumented but appears to be valid EBML content.

When the same 6 MB file is remuxed with mvkmerge, it's 53 KB smaller. And it doesn't take in account the 4 KB of padding that mkvmerge is using for tag/chapters editing at the beginning of the file.

This article will be updated as we analyze more files or muxers are tuned to produce better files. This article was last updated on 2010-04-30