Tracing a Matroska file that contains an attached text file replaces the entire trace with a single block representing the attachment's content:
<media ref="broken.mkv" parser="Matroska">
<block offset="0" name="Unknown" size="63">
</block>
</media>
63 is exactly the byte size of the attached text file. Only the trace feature is affected, the regular report for the same file is correct.
Steps to reproduce
ffmpeg -f lavfi -i sine=duration=60 -ar 48000 -ac 2 -c:a pcm_s24le sine48k.mkv
echo "hello world, this is a plain text log file" > t.txt
mkvmerge -o broken.mkv --attach-file t.txt sine48k.mkv
mediainfo --Details=1 --Output=XML sine48k.mkv # full trace (expected)
mediainfo --Details=1 --Output=XML broken.mkv # collapses to one "Unknown" block
Attaching via mkvpropedit --add-attachment also reproduces
Reproduced with MediaInfoLib 26.05 (macOS arm64, Homebrew). Same signature in traces from 25.07 and 26.01 (macOS) on real files, so it appears long-standing...?
I did some digging with some assistance in the source and perhaps the issue is in File_Mk::Segment_Attachments_AttachedFile_FileData() (File_Mk.cpp). When trace is active, a nested MediaInfo_Internal is created to parse the attachment's bytes, and its trace is merged back in with TraceNode.TakeChilrenFrom(...). In files that trace correctly, the attachment's sub-trace appears properly nested inside FileData — in the broken ones, that same node shows up alone as the entire trace.
One thing that made this confusing to track down: it doesn't fail consistently. Out of five captures from the same vrecord setup (same machine, MediaInfo 26.05), a 3.8 GB and a 22.4 GB file traced fine, while a 4.7 GB and a 21.6 GB file collapsed. So it seems to depend on where the attachment bytes land in the file rather than on the attachment itself? Might be worth testing a fix against attachments at the front and at the end, and on both small and multi-GB files?
Impact
Digital-preservation QC workflows (e.g. NMAAHC's AV Spex) parse the MediaTrace XML to verify Matroska tags. Files with attached capture logs (standard vrecord practice) randomly produce unusable traces, causing false QC failures.
@dericed @eddycolloton
Tracing a Matroska file that contains an attached text file replaces the entire trace with a single block representing the attachment's content:
63is exactly the byte size of the attached text file. Only the trace feature is affected, the regular report for the same file is correct.Steps to reproduce
Attaching via
mkvpropedit --add-attachmentalso reproducesReproduced with MediaInfoLib 26.05 (macOS arm64, Homebrew). Same signature in traces from 25.07 and 26.01 (macOS) on real files, so it appears long-standing...?
I did some digging with some assistance in the source and perhaps the issue is in
File_Mk::Segment_Attachments_AttachedFile_FileData()(File_Mk.cpp). When trace is active, a nestedMediaInfo_Internalis created to parse the attachment's bytes, and its trace is merged back in withTraceNode.TakeChilrenFrom(...). In files that trace correctly, the attachment's sub-trace appears properly nested insideFileData— in the broken ones, that same node shows up alone as the entire trace.One thing that made this confusing to track down: it doesn't fail consistently. Out of five captures from the same vrecord setup (same machine, MediaInfo 26.05), a 3.8 GB and a 22.4 GB file traced fine, while a 4.7 GB and a 21.6 GB file collapsed. So it seems to depend on where the attachment bytes land in the file rather than on the attachment itself? Might be worth testing a fix against attachments at the front and at the end, and on both small and multi-GB files?
Impact
Digital-preservation QC workflows (e.g. NMAAHC's AV Spex) parse the MediaTrace XML to verify Matroska tags. Files with attached capture logs (standard vrecord practice) randomly produce unusable traces, causing false QC failures.
@dericed @eddycolloton