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: 64 Bit LAME Encoder (Read 9984 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

64 Bit LAME Encoder

Just curious, and I did try to do a search for any relevant info, but unfortunately the stupid forum Search feature doesn't like anything less than 4 characters long - doesn't that seem really idiotic on a forum with acronyms like AAC, MP3, etc. which are all 3 characters long? I understand that doing a search for "mp3" would definitely get some serious CPU activity going on the server since practically every post probably has it, but since I wanted to look for "64" and "bit" both fall under the minimum of 4; that's pretty drastic.

Anyway, with the influx of AMD Opteron processors (fully 64 bit), AMD Athlon64 and Turion64 (single and dual core) and Intel Core Duo and Core 2 Duo (C2D has 64 bit support for EM64T, not "true" 64 bit but it can make a noticeable difference in processing power), I wonder if anyone will ever code a version of LAME that might meet one of the three following situations:

- A pure 64 bit LAME encoder
- A pure multithreaded LAME encoder
- A pure 64 bit multithreaded LAME encoder

The first would be awesome for those of us running 64 bit operating systems (like myself), the second would kick for those of us running dual core machines (like myself) or even dual processor dual core machines, and the third would just kick some serious butt for those of us... well... you get the point.

So I'm just asking if anyone knows if development is under way for such a LAME encoder in any of the those three variations. I've been using it a for a long long time, and like most anyone else around here, I know it's the best there is. But I'd like to know if a possible 64 bit adaptation might appear someday.

To all the LAME developers over the years: my heartfelt thanks for your efforts. Your work has allowed me (and millions of others I think) to enjoy our CDs on the go in mp3 format where we can carry a lot more with us than CDs would allow.

Thanks, and have fun, always...

bb

EDIT: Duh. After posting this I realized it probably belongs in MP3 Tech, my apologies. If a Mod can move it over to that subforum I'd appreciate it.
The difference between genius and stupidity?

Genius has limits.

64 Bit LAME Encoder

Reply #1 –
IIRC multithreading LAME would prevent the use of 'bit reservoir' which in turn would mean lower quality MP3's.

The use of multiple simultaneous instances of the LAME encoder is a solution though. Some programs already do this and I assume it will become standard in a while. Encoding a single MP3 still takes just as long but a whole CD will be done in roughly half the time.
Every night with my star friends / We eat caviar and drink champagne
Sniffing in the VIP area / We talk about Frank Sinatra
Do you know Frank Sinatra? / He's dead

64 Bit LAME Encoder

Reply #2 –
Quote from: br0adband on
Anyway, with the influx of AMD Opteron processors (fully 64 bit), AMD Athlon64 and Turion64 (single and dual core) and Intel Core Duo and Core 2 Duo (C2D has 64 bit support for EM64T, not "true" 64 bit but it can make a noticeable difference in processing power),


EMT64 and AMD64 are essential identical.  They're just AMD and Intel's branding for the x86-64 variant supported by MS.  Both can be considered "true" 64 bit.

Quote from: br0adband on
- A pure 64 bit LAME encoder


http://hilltop.bradley.edu/~aneebel/lame-3.97-x64.zip

Don't expect much though.  LAME already uses SSE for much of it's computations in 32 bit mode, so there is not much advantage to 64 mode as there is with other apps which use x87 in 32 bit mode (IE Cinebench vs. Cinebench64).  The other changes don't really matter for lame either.

Quote from: br0adband on
- A pure multithreaded LAME encoder
- A pure 64 bit multithreaded LAME encoder


LAME-MT.  However quality is reduced, and it is not recommended.  MP3 parallelism is best exploited by running two encoders at once, not trying to multithread one encoder (since the MP3 standard implies serial execution).

Actually, even if quality were not reduced, it would be fairly pointless.  EAC has supported multiple lame threads since what, 2002?  Its in the options menu, and it will be much faster anyway.

64 Bit LAME Encoder

Reply #3 –
Theoretically, at least, a multi-threaded lame is perfectly doable. LAME-MT (AFAIK) just encodes each frame in a separate thread, which is why the bit reservoir (which is shared between frames) must be disabled. A better way would be to build an assembly line of threads, so that one does quantization, one does huffman coding, one assembles the bitstream etc. Since CPUs aren't really getting faster anymore (at least in MHz), if we want quicker encodes this is how things will have to work down the road. Codecs can be fantastically parallel. Many video codecs already are.

64 Bit LAME Encoder

Reply #4 –
Current Lame versions (3.98) can be compiled in 64bits mode, that is how I am using it most of the time.
Using VC8 as a compiler, it increases encoding speed by about 20% compared to 32bits mode.

Quote from: Jebus on
Theoretically, at least, a multi-threaded lame is perfectly doable. LAME-MT (AFAIK) just encodes each frame in a separate thread, which is why the bit reservoir (which is shared between frames) must be disabled. A better way would be to build an assembly line of threads, so that one does quantization, one does huffman coding, one assembles the bitstream etc. Since CPUs aren't really getting faster anymore (at least in MHz), if we want quicker encodes this is how things will have to work down the road. Codecs can be fantastically parallel. Many video codecs already are.


Expect that huffman coding is done over quantized values, and that bitstream formatting is done on huffman coded values, and you usually need to know the final size of the previous frame in order to select quantization values.

Most video encoders are using multithreading by slicing input data, not by functionnal decomposition parallelism.

64 Bit LAME Encoder

Reply #5 –
Quote
Current Lame versions (3.98) can be compiled in 64bits mode, that is how I am using it most of the time.
Using VC8 as a compiler, it increases encoding speed by about 20% compared to 32bits mode.
Are there any binaries available? I use 64-bit windows at work.

I guess that slicing input data would be fairly easy to do, i.e. simply splitting the input data in two or four, depending on number of cores on your system, and then internally joining the encoded parts gaplessly. Could be nice if you are encoding CD images to mp3. But in general I think it is just as easy to use multiple instances of lame instead, which has been pointed out several times.

Add: Just a thought. Could the GPU be utilized for any parts of the encoding? This would speed up things even on a single core system.

64 Bit LAME Encoder

Reply #6 –
Quote from: tycho on
there any binaries available? I use 64-bit windows at work.

Don't know, usually we (Lame project) do not provide binaries ourselves.

Quote from: tycho on
Add: Just a thought. Could the GPU be utilized for any parts of the encoding? This would speed up things even on a single core system.

Sorry, but GPU is not a magic thing that would automatically provide speed up, as it's not suitable to all kind of tasks. You have issues like low precision, huge latency, very low efficiency for computations that are not higly parallels,...
Resampling is likely to work well, but other than that I am not sure if it would help with audio lossy codecs.

64 Bit LAME Encoder

Reply #7 –
I'm sure you're right. I have only programmed the GPU for its primary usage - with OpenGL 2.0.
Quote
Don't know, usually we (Lame project) do not provide binaries ourselves.
Sure, I forgot. I can compile it up myself when I find the time - thanks.