Fast multi threaded MP3 decoding?, Processing single CBR/VBR encoded files on a quadcore Options

[binrapt]

Hello,

I have trouble finding a library which can decode MP3s efficiently on multi core processors. I tried all kinds of builds of LAME (including x86/x64 builds from http://lame.bakerweb.biz/) but they all appeared to be using a single core of my E6600 only. The hard disk definitely isn't the bottleneck in this case.
I intend to keep the decoded data in memory so I can generate wave forms and spectrograms on the fly. Several people suggested that I should simply run 4 instances of LAME or mpg123 (which is used by the decoder in LAME anyways?) simultaneously but that is not as efficient. I don't know how MP3 compression works at a low level. Is it difficult to perform multi threaded decoding of a single CBR/VBR file? Are there any libraries which can already do this? How difficult will implementing this using a library like mpg123 be?

Thanks.

[Sunhillow]

MP3 format is not designed for multithreaded encoding and decoding.
You might run several processes simultaneously, but the your WAV output files will become heavily fragmented

Ed.: OK you don't want to write the decoded data to files. Multithreaded operations are impossible IMHO especially because of usage of bitreservoir

This post has been edited by Sunhillow: May 2 2009, 23:29

[binrapt]

MP3 format is not designed for multithreaded encoding and decoding.
You might run several processes simultaneously, but the your WAV output files will become heavily fragmented

Ed.: OK you don't want to write the decoded data to files. Multithreaded operations are impossible IMHO especially because of usage of bitreservoir

How do audio players start playing at a random offset then? Surely they don't decode everything up to that position then. Don't you just need to scan for something and then you can continue decoding? Surely you can multi thread this process.

This post has been edited by binrapt: May 2 2009, 23:53

[Sunhillow]

you don't have to decode every single frame while scanning. Frame header information is enough and very fast to read

[Mike Giacomelli]

I have trouble finding a library which can decode MP3s efficiently on multi core processors.

The only one I know of is the one I adapted for Rockbox based on MAD.

Several people suggested that I should simply run 4 instances of LAME or mpg123 (which is used by the decoder in LAME anyways?) simultaneously but that is not as efficient. I don't know how MP3 compression works at a low level. Is it difficult to perform multi threaded decoding of a single CBR/VBR file? Are there any libraries which can already do this? How difficult will implementing this using a library like mpg123 be?

Its not too difficult, you can run the synthesis filter bank for frame X in parallel with huffman/requant/imdct from frame X+1. Doing this is really uncommon though since its more efficient to just run 2 instances of the decoder as was suggested to you. For rockbox, we needed a parallel decoder in order to reduce the CPU clock (and thus battery power) needed to decode MP3.

[WonderSlug]

Hello,

I have trouble finding a library which can decode MP3s efficiently on multi core processors. I tried all kinds of builds of LAME (including x86/x64 builds from http://lame.bakerweb.biz/) but they all appeared to be using a single core of my E6600 only. The hard disk definitely isn't the bottleneck in this case.
I intend to keep the decoded data in memory so I can generate wave forms and spectrograms on the fly. Several people suggested that I should simply run 4 instances of LAME or mpg123 (which is used by the decoder in LAME anyways?) simultaneously but that is not as efficient. I don't know how MP3 compression works at a low level. Is it difficult to perform multi threaded decoding of a single CBR/VBR file? Are there any libraries which can already do this? How difficult will implementing this using a library like mpg123 be?

Thanks.

Last year, I helped someone who was trying to do a similar thing with his Quad-Core setup, using multiple instances of foobar2000 to transcode a bunch of files.

We determined that the hard drive became the bottleneck when he tried to use all 4 cores simultaneously. The process slowed down to a crawl after several seconds, as the files all resided on the same drive and he was reaching bandwidth saturation of the hard drive interface.

Using only 3 cores kept things at near maximum speed for nearly the entire process time.


I would recommend you seek to only use 3 of the 4 cores for encoding/decoding. Leave one core alone for any additional background Windows/OS/application processing that may arise at the same time.