Skip to main content

Topic: MP3 not bit-identical with MP3 in MKV/A (Read 2487 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • Soulvomit
  • [*]
MP3 not bit-identical with MP3 in MKV/A
The number of samples of MP3 files are a few thousand shorter than in MKV/A. The audio starts a few milliseconds early and/or gets cut at the end. I'm using version 1.1.11.

  • Kohlrabi
  • [*][*][*][*][*]
  • Global Moderator
MP3 not bit-identical with MP3 in MKV/A
Reply #1
I see the same behaviour regarding MP3 in MKV/MKA files, foobar2000 reports 2844 more samples for an MKA muxed from VBR MP3, 2340 for a CBR MP3. Maybe thse numbers are somewhat random and it always ends up at about 2400 samples. Extracting the MP3 stream using MKVExtractGUI-2 gives me a MP3 file which again is bit-identical (and has the same no. of samples) to the original source.
  • Last Edit: 13 April, 2012, 03:09:59 AM by Kohlrabi
It's only audiophile if it's inconvenient.

  • Soulvomit
  • [*]
MP3 not bit-identical with MP3 in MKV/A
Reply #2
I notice when opening an MP3 MKV with Audacity, it has the same number of samples as it does with fb2k. GraphEdit also gives the same number of samples when opening the MP3 directly with the graph looking like File.mp3>MPEG-1 Stream Splitter>MP3 Decoder DMO>WAV Dest VEM>File Write. However, if you open the MP3 directly with Audacity, the sample count is shorter. The number doesn't even match fb2k when opening the MP3 directly. Winamp has the same problem.
  • Last Edit: 13 April, 2012, 05:57:28 PM by Soulvomit

  • kode54
  • [*][*][*][*][*]
  • Administrator
MP3 not bit-identical with MP3 in MKV/A
Reply #3
Is the difference of samples in the plain MP3 file between Audacity and foobar2000 exactly 529? Or is it some other odd number? Maybe they're adding the decoder delay to the encoder delay and padding, which is incorrect. The decoder delay is included in the padding.

The extra length in the MKA sounds like it's not only missing the gapless encoding information, but that it's decoding the gapless info header as sample data. This may be the fault of the Mastroska multiplexing tool.

For reference, encode your own track directly with lame.exe and compare Audacity's reported length to the original file. foobar2000 should be correct in this regard.

  • Soulvomit
  • [*]
MP3 not bit-identical with MP3 in MKV/A
Reply #4
No, I have compared other files and it isn't a fixed number.

I tried a file of my own and foobar2000 decodes the LAME MP3 identical to the source—same sample count and alignable waveforms. However, not in the Matroska container; the padding at both ends is introduced. I also tried the latest iTunes MP3 encoder and fb2k missed the last 85 of the 12,568,500 samples (4:45) directly.

So, basically, MP3 within Matroska is inaccurate. Output also varies depending on what encoder and decoder is used. I've noticed this with AAC as well.
  • Last Edit: 16 April, 2012, 08:50:33 PM by Soulvomit

  • kode54
  • [*][*][*][*][*]
  • Administrator
MP3 not bit-identical with MP3 in MKV/A
Reply #5
This is apparently because the multiplexing tool is not aware of gapless information when it produces the Matroska file. It just inserts the MP3 or AAC bitstream as-is.

  • Kohlrabi
  • [*][*][*][*][*]
  • Global Moderator
MP3 not bit-identical with MP3 in MKV/A
Reply #6
I have since reported this on the mkvtoolnix bug tracker. Please feel free to add additional information or correct me.
  • Last Edit: 17 April, 2012, 08:21:12 AM by Kohlrabi
It's only audiophile if it's inconvenient.