Duplicate/incorrect StreamSize reported for a second audio track mapped from the same TrueHD/Atmos source stream

[sushiat]

Description

When a Matroska file contains two audio tracks that were both derived from the same original TrueHD/Atmos stream — one kept as a lossless copy, one transcoded to a lossy companion codec (E-AC-3 in this case) — MediaInfo reports the exact same StreamSize for both tracks, even though they are structurally and numerically nothing alike (one is a lossless multi-GB stream, the other a small fixed-bitrate CBR stream).

In the real-world file below:

• Track 1 (TrueHD/Atmos, VBR, ~4420 kb/s average): StreamSize = 4518312588 (4.21 GiB)
• Track 2 (E-AC-3, CBR, 1536 kb/s): StreamSize = 4518312588 (4.21 GiB) — byte-for-byte identical to track 1

The E-AC-3 track's real size is trivial to compute independently since it's fixed CBR: 1536000 bps × 8178.671 s / 8 ≈ 1,570,304,887 bytes (≈1.46 GiB), nowhere near 4.21 GiB. The file's own reported overall size only reconciles correctly if the E-AC-3 track really is ~1.46 GiB, not 4.21 GiB, confirming the E-AC-3 figure is wrong (and not, say, the TrueHD figure being wrong instead).

Both tracks also share an identical Title tag ("Atmos 7.1") and identical FrameCount (9814405) — the title collision is expected (both tracks were -map'd from the same source stream via ffmpeg, which copies per-stream metadata onto every output derived from that source index, regardless of codec), but I initially suspected it might be causing the StreamSize bug. I've since ruled that out — see reproduction notes below.

Environment

• MediaInfoLib v26.05 (MediaInfo Command line)
• File produced by ffmpeg version 8.1.2-full_build-www.gyan.dev
• Container: Matroska (MKV)

Reproduction

The two audio tracks are produced by a single ffmpeg invocation that maps the same source stream index twice — once as a straight copy, once transcoded:

ffmpeg -i source.mkv -map 0:1 -map 0:1 -c:0 copy -c:1 eac3 -b:1 1536k -strict -2 out.mkv

(0:1 being the TrueHD/Atmos source stream in this case.)

I could not reproduce the bug with a synthetic, non-Atmos TrueHD source generated via ffmpeg's own experimental truehd encoder, at matching duration and bitrate:

ffmpeg -f lavfi -i "sine=frequency=1000:duration=600" -channel_layout "5.1(side)" -c:a truehd -strict -2 source.mka
ffmpeg -i source.mka -map 0:0 -map 0:0 -c:0 copy -c:1 eac3 -b:1 1536k -strict -2 repro.mkv

Against this synthetic file, MediaInfo reports a StreamSize for the E-AC-3 track only, and it's correctly computed (matches bitrate × duration almost exactly), while the TrueHD copy gets no StreamSize at all — no duplication, no bug.

This makes me suspect the trigger is specific to genuine Dolby-encoded Atmos/object-audio TrueHD streams (the real file's TrueHD track carries NumberOfDynamicObjects/BedChannelCount/BedChannelConfiguration extra fields that a plain ffmpeg-encoded TrueHD stream doesn't have), not simply "two audio tracks mapped from the same source." I don't have a way to produce a genuinely Atmos-encoded synthetic test file myself, so I can't offer a fully minimal, shareable repro — but I'm happy to run any specific test/build against the real file privately if that would help narrow it down, since I can't share the original copyrighted disc audio here.

Relevant MediaInfo --Output=JSON --Full excerpt (both Audio track objects, real file)

{
  "@type": "Audio", "@typeorder": "1",
  "StreamOrder": "1",
  "Format": "MLP FBA",
  "Format_Commercial": "Dolby TrueHD with Dolby Atmos",
  "CodecID": "A_TRUEHD",
  "Duration": "8178.671000000",
  "BitRate_Mode": "VBR",
  "BitRate": "4419605",
  "Channels": "8",
  "Compression_Mode": "Lossless",
  "StreamSize": "4518312588",
  "StreamSize_String": "4.21 GiB (12%)",
  "Title": "Atmos 7.1",
  "FrameCount": "9814405",
  "extra": {"NumberOfDynamicObjects": "11", "BedChannelCount": "1", "BedChannelConfiguration": "LFE"}
},
{
  "@type": "Audio", "@typeorder": "2",
  "StreamOrder": "2",
  "Format": "E-AC-3",
  "CodecID": "A_EAC3",
  "Duration": "8178.671000000",
  "BitRate_Mode": "CBR",
  "BitRate": "1536000",
  "Channels": "6",
  "Compression_Mode": "Lossy",
  "StreamSize": "4518312588",
  "StreamSize_String": "4.21 GiB (12%)",
  "Title": "Atmos 7.1",
  "FrameCount": "9814405"
}

Note the identical StreamSize/StreamSize_String between the two tracks despite completely different BitRate_Mode/BitRate/Compression_Mode — a CBR 1536 kb/s track simply cannot be the same size as a VBR ~4420 kb/s lossless track over an identical duration.

Expected behavior

Each audio track's StreamSize should reflect its own actual byte content, independent of any other track sharing the same source stream, title tag, or frame count.

[cjee21]

FFmpeg is known not only not to compute/write the bitrate and stream size when muxing MKVs, but also to copy these metadata from the original file if present, even when they are no longer valid after remuxing or re-encoding. The issue may be related to this as MediaInfo may obtain such metadata from the file and not compute them when not doing a full parse of the entire bitstream.