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:
Track converted successfully.
Total encoding time: 0:06.396, 16.88x realtime
foobar2000 v1.2 beta 1:
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:
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:
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:
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.
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.
Not sure, but it's the decoder that's changed.
Yes:
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.
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.
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.
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.
Thanks - I re-did the comparison at 32-bit; the result (second file):
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.
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.
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 (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.
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...
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)
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.
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).
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 (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:
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:
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.
FFmpeg can decode TAK so why not support it out of the box?
Atom N2600.
LC-AAC ~128 kbps
single thread mode for both versions.
1.1.18 - 54x
1.2b1 - 171x
Nice speed up.
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.
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).
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.)
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.
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.