HydrogenAudio

Hosted Forums => foobar2000 => General - (fb2k) => Topic started by: Arite on 2012-12-17 19:54:20

Title: MP3 decoding differences
Post by: Arite on 2012-12-17 19:54:20
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.
Title: MP3 decoding differences
Post by: Andreasvb on 2012-12-17 21:43:32
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.

Title: MP3 decoding differences
Post by: Arite on 2012-12-17 22:48:48
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.
Title: MP3 decoding differences
Post by: mezenga on 2012-12-17 22:50:05
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.
Title: MP3 decoding differences
Post by: Andreasvb on 2012-12-18 00:08:01
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.
Title: MP3 decoding differences
Post by: kode54 on 2012-12-18 01:25:37
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.
Title: MP3 decoding differences
Post by: Arite on 2012-12-18 01:43:12
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.
Title: MP3 decoding differences
Post by: nu774 on 2012-12-18 03:13:49
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.
Title: MP3 decoding differences
Post by: Garf on 2012-12-18 08:21:12
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.
Title: MP3 decoding differences
Post by: Garf on 2012-12-18 08:26:30
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...
Title: MP3 decoding differences
Post by: Peter on 2012-12-18 12:15:15
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)
Title: MP3 decoding differences
Post by: lvqcl on 2012-12-18 14:58:20
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.
Title: MP3 decoding differences
Post by: nu774 on 2012-12-18 15:10:16
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).
Title: MP3 decoding differences
Post by: Arite on 2012-12-18 18:49:20
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:
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.
Title: MP3 decoding differences
Post by: PHOYO on 2012-12-18 22:44:59
FFmpeg can decode TAK so why not support it out of the box?
Title: MP3 decoding differences
Post by: IgorC on 2012-12-18 23:30:15
Atom N2600.

LC-AAC ~128 kbps

single thread mode for both versions.

1.1.18 - 54x
1.2b1 -  171x

Nice speed up.
Title: MP3 decoding differences
Post by: mezenga on 2012-12-19 02:40:46
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.
Title: MP3 decoding differences
Post by: Heliologue on 2012-12-22 03:58:48
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).
Title: MP3 decoding differences
Post by: Porcus on 2012-12-22 12:03:49
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.)
Title: MP3 decoding differences
Post by: lvqcl on 2012-12-22 14:07:03
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.
Title: MP3 decoding differences
Post by: Garf on 2012-12-23 10:06:46
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.