Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: MP3 not bit-identical with MP3 in MKV/A (Read 3476 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

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.

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.
It's only audiophile if it's inconvenient.

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.

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.

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.

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.