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 decoding differences (Read 12046 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

MP3 decoding differences

foobar2000 v1.2 has switched to using FFmpeg for decoding MP3s (and other codecs). I believe before (v1.1.18 and earlier) it used mpg123 for decoding.

I thought I'd compare the decoded WAV files from an MP3 file (AFAIK FhG encoder) created using v1.1.18 and v1.2 beta 1, respectively.

foobar2000 v1.1.18:
Code: [Select]
Track converted successfully.
Total encoding time: 0:06.396, 16.88x realtime

foobar2000 v1.2 beta 1:
Code: [Select]
Track converted successfully.
Total encoding time: 0:00.593, 182.08x realtime

That's quite a notable speed change  (next test was only 2x as fast though).

However doing a bit compare yields:
Code: [Select]
Differences found: 14232 sample(s), starting at 1.1842404 second(s), peak: 0.0000305 at 1.1842404 second(s), 2ch

Is this normal/to be expected? My understanding is that mpg123 is the/one of the most accurate decoders.

I tried it on another file (LAME 3.98r -V 0 encoded) and that also failed the bit compare test. Decoding speeds:
Code: [Select]
v1.1.18:
Track converted successfully.
Total encoding time: 0:02.964, 112.78x realtime

v1.2 beta 1:
Track converted successfully.
Total encoding time: 0:01.435, 232.96x realtime

^So about 2x as fast - could be due to FFmpeg being multi threaded.

Bit comparing:
Code: [Select]
Differences found: 76491 sample(s), starting at 0.5605442 second(s), peak: 0.0000305 at 0.5605442 second(s), 2ch

My question is why is FFmpeg's MP3 decoding different, and is it more or less accurate than mpg123?

Cheers, Arite.

MP3 decoding differences

Reply #1
Not sure, but it's the decoder that's changed.
The encoder is the same, or does it affect as well?

Decoder = Playback.
Encoder = Converting.

Windows 10 Pro x64 // foobar2000 1.3.10

MP3 decoding differences

Reply #2
Not sure, but it's the decoder that's changed.

Yes:
Quote
FFmpeg is now used for MP3, AAC and Vorbis decoding


The encoder is the same, or does it affect as well?

No, encoding is the same - LAME is used (I used a custom profile with lame.exe anyway).

To clarify, I didn't encode any MP3 files - just decompressed the same MP3 file(s) to WAV using v1.1.18 and then v1.2 beta 1 and did a bit compare on the uncompressed files.

Arite.

MP3 decoding differences

Reply #3
My question is why is FFmpeg's MP3 decoding different, and is it more or less accurate than mpg123?

Same results here.
My guess would be rounding differences due optimizations at code or compiler level.
It´s probably nothing to worry about.

MP3 decoding differences

Reply #4
Don't know why you would decompress an MP3 to WAV, in any case as it's not lossless.
But great that it's faster now.
Windows 10 Pro x64 // foobar2000 1.3.10

MP3 decoding differences

Reply #5
At 16 bit integer precision, the peak difference you measured is confined to the least significant bit. I suggest you try again, decoding to 32 bit (floating point) WAV files, you should find that the difference is a lot smaller.

MP3 decoding differences

Reply #6
Thanks - I re-did the comparison at 32-bit; the result (second file):
Code: [Select]
Differences found: 28403558 sample(s), starting at 0.0000000 second(s), peak: 0.0000030 at 238.6302495 second(s), 1ch

The peak is ~1 order of magnitude lower.

I'm presuming by the responses this is to be expected and there's nothing to worry about, and the differences are due to e.g. compiler-based rounding differences as mezenga says?

Cheers, Arite.

MP3 decoding differences

Reply #7
Looks like channel mapping of 6.1ch AAC is incorrect: [attachment=7252:6.1ch.m4a]
Both of ffmpeg and avconv (correctly) decode this file as L R C LFE BL BR BC, but fb2k seems to decode it as L R LFE BL BR FLC FRC.
Is that due to version difference of libavcodec/libavutil, or some other reason? In my environment libavutil-52.dll was being used.

MP3 decoding differences

Reply #8
I'm presuming by the responses this is to be expected and there's nothing to worry about, and the differences are due to e.g. compiler-based rounding differences as mezenga says?


Yes. Not only due to the compiler, also due to the decoder structure/optimizations.

There are some rules for what defines a "correct/compliant" MP3 decoder, see for example:
http://www.underbit.com/resources/mpeg/audio/compliance

Both the old and new fb2k decoder should pass at full compliance. (Your 24-bit test confirms this)

Vorbis and AAC should give similar results.

MP3 decoding differences

Reply #9
By the way, when decoding to disk your disk is going to be a limiting factor, not the decoder itself. Try foo_benchmark.

The speedup also differs depending on the generation of your CPU. Having AVX is a lot faster, failing that having SSE is still a lot faster, failing that 3DNow, etc...

MP3 decoding differences

Reply #10
Looks like channel mapping of 6.1ch AAC is incorrect: [attachment=7252:6.1ch.m4a]
Both of ffmpeg and avconv (correctly) decode this file as L R C LFE BL BR BC, but fb2k seems to decode it as L R LFE BL BR FLC FRC.
Is that due to version difference of libavcodec/libavutil, or some other reason? In my environment libavutil-52.dll was being used.

Bug fixed for beta 2, thanks for reporting.
(Bug wasn't even new to fb2k 1.2 it seems)
Microsoft Windows: We can't script here, this is bat country.

MP3 decoding differences

Reply #11
MP3 decoding speed via foo_benchmark. Test file: 221kbps (LAME 3.97 -V2, stereo, 44.1k). Test CPU: Intel Core2,  SSE up tp 4.1.

1.1.18: 210x realtime; 1.2 b1: 463x realtime.

MP3 decoding differences

Reply #12
Thanks for quick fix.
In my environment (Core i5 mobile), MP3 decoding speed is around 560x-580x or so, and now it's faster than Apple's decoder (410x or so).

MP3 decoding differences

Reply #13
I'm presuming by the responses this is to be expected and there's nothing to worry about, and the differences are due to e.g. compiler-based rounding differences as mezenga says?


Yes. Not only due to the compiler, also due to the decoder structure/optimizations.

There are some rules for what defines a "correct/compliant" MP3 decoder, see for example:
http://www.underbit.com/resources/mpeg/audio/compliance

Both the old and new fb2k decoder should pass at full compliance. (Your 24-bit test confirms this)

Vorbis and AAC should give similar results.

OK, thanks .

By the way, when decoding to disk your disk is going to be a limiting factor, not the decoder itself. Try foo_benchmark.

The speedup also differs depending on the generation of your CPU. Having AVX is a lot faster, failing that having SSE is still a lot faster, failing that 3DNow, etc...

Cheers - my results using foo_benchmark:

v1.1.18:
Code: [Select]
Total length: 5:34.307
Info Read time: 0:00.001
Opening time: 0:00.003
Decoding time: 0:01.736
192.349x realtime

v1.2 beta 1:
Code: [Select]
Total length: 5:34.307
Info Read time: 0:00.000
Opening time: 0:00.092
Decoding time: 0:00.768
434.987x realtime

Still over 2x .

Arite.

MP3 decoding differences

Reply #14
FFmpeg can decode TAK so why not support it out of the box?

MP3 decoding differences

Reply #15
Atom N2600.

LC-AAC ~128 kbps

single thread mode for both versions.

1.1.18 - 54x
1.2b1 -  171x

Nice speed up.

MP3 decoding differences

Reply #16
FFmpeg can decode TAK so why not support it out of the box?

Because it is a reverse engineering work developed without format specification guidance and released just a few months ago.

Discussion [a href='index.php?act=findpost&pid=810363']here[/a]

ITOH, foosion´s TAK Decoder is a mature, fully compilant component based on the official tak decoding library.

MP3 decoding differences

Reply #17
While I understand why 1.2 may choose to not use ffmpeg for new codecs like TAK, I'm curious as to why it does't use it for, e.g., FLAC.  Perhaps there as simply no performance benefit?  foobar2000's decoding is already quite fast for me (> LAME decoding in 1.1.18).

MP3 decoding differences

Reply #18
My question is why is FFmpeg's MP3 decoding different, and is it more or less accurate than mpg123?


Two different possibilities: roundoff and non-conforming files. In the first case, the differences are unlikely to be audible. In the second case, there is AFAIK no standardized workaround files that do not really conform to the MP3 specification. (That is not to say that one will not produce more annoying artifacts than the other.)

MP3 decoding differences

Reply #19
BTW fb2k 1.2b2 decodes SBR part of HE-AAC files differently than 1.1.18.

foo_bitcompare shows that 1.1.18 is closer to e.g. Winamp. But from spectrograms, 1.2b2 is closer to Winamp.

 

MP3 decoding differences

Reply #20
While I understand why 1.2 may choose to not use ffmpeg for new codecs like TAK, I'm curious as to why it does't use it for, e.g., FLAC.  Perhaps there as simply no performance benefit?  foobar2000's decoding is already quite fast for me (> LAME decoding in 1.1.18).


IIRC this was tested and ffmpeg is no faster than the official FLAC decoder.