Skip to main content

Topic: Multi-threaded LAME 3.97beta2 Out! (Read 15234 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • johnsonlam
  • [*][*][*]
Multi-threaded LAME 3.97beta2 Out!
LAME MT Project:

Turning LAME into a Multi-Threaded Engine,
and to be 1:1 bit compatible with the
original version.

http://www.lame-mt.com
Hong Kong - International Joke Center (after 1997-06-30)

  • Gabriel
  • [*][*][*][*][*]
  • Developer
Multi-threaded LAME 3.97beta2 Out!
Reply #1
I do not know about this version, but previous versions provided LOWER QUALITY than default Lame, as they required to disable bit reservoir.

  • CiTay
  • [*][*][*][*][*]
  • Administrator
Multi-threaded LAME 3.97beta2 Out!
Reply #2
Quote
I do not know about this version, but previous versions provided LOWER QUALITY than default Lame, as they required to disable bit reservoir.
[a href="index.php?act=findpost&pid=371518"][{POST_SNAPBACK}][/a]


Right, it still requires that, i just tested lame-mt.3.97b2.cl_32.exe on an A64 X2:

Quote
WARNING: Multi-Threaded Encoder is DISABLED - please add '--nores' to enable Multi-Threading !


Inverse mix-pasting showed that the resulting file was a lot different from the normal output. The ICL compile didn't seem to run multi-threaded at all, i guess that's because of the A64.

  • johnsonlam
  • [*][*][*]
Multi-threaded LAME 3.97beta2 Out!
Reply #3
Quote
Right, it still requires that, i just tested lame-mt.3.97b2.cl_32.exe on an A64 X2:

Quote
WARNING: Multi-Threaded Encoder is DISABLED - please add '--nores' to enable Multi-Threading !


Inverse mix-pasting showed that the resulting file was a lot different from the normal output. The ICL compile didn't seem to run multi-threaded at all, i guess that's because of the A64.
[a href="index.php?act=findpost&pid=371532"][{POST_SNAPBACK}][/a]


You mean the encoded MP3 less quality than the normal binary? If it's true (can somebody double check?) Need to tell the author about this.

How about MS's binary?
Hong Kong - International Joke Center (after 1997-06-30)

  • Gabriel
  • [*][*][*][*][*]
  • Developer
Multi-threaded LAME 3.97beta2 Out!
Reply #4
Of course the MT version is of lesser quality if you want to use it in MT, as it requires to disable bit reservoir. (the author is aware of this)
*single thread-> same quality, but also same speed
*multithread -> reduced quality, faster

Practically, multiple Lame instances of a "regular" version would provide about the same speed as this MT version, with an higher quality. However, running 2 instances is reducing ease of use.

  • wisodev
  • [*][*][*]
  • Developer
Multi-threaded LAME 3.97beta2 Out!
Reply #5
Quote
The output of this multi-threaded version, based on LAME 3.97 alpha, is 1:1 bit compatible with the original version and it gains ~1.16x speedup when Constant Bit Rate (CBR) or Average Bit Rate (ABR) models are used and ~1.30 speedup when Variable Bit Rate (VBR) mode is used on SMT platforms and >1.45x on SMP systems.


taken from Description

then this statement is not true and the project goal is not reached ??

this is confusing for me
and I do not have hardware to test the app myself
would be nice to get some test results
  • Last Edit: 16 March, 2006, 06:42:32 AM by wisodev

  • Gabriel
  • [*][*][*][*][*]
  • Developer
Multi-threaded LAME 3.97beta2 Out!
Reply #6
Quote
then this statement is not true and the project goal is not reached ??

This statement is incomplete.
It is true only if you disable bit reservoir, and that will reduce quality.

  • Klyith
  • [*][*][*][*]
  • Members (Donating)
Multi-threaded LAME 3.97beta2 Out!
Reply #7
Quote
Quote
The output of this multi-threaded version, based on LAME 3.97 alpha, is 1:1 bit compatible with the original version and it gains ~1.16x speedup when Constant Bit Rate (CBR) or Average Bit Rate (ABR) models are used and ~1.30 speedup when Variable Bit Rate (VBR) mode is used on SMT platforms and >1.45x on SMP systems.
then this statement is not true and the project goal is not reached ??

this is confusing for me
"Bit compatible" does not mean the same as "bit identical".

The output of the MT encoder has the same headers, block structure, etc as other lame mp3s. It will be identified as a lame produced file by any scanner utility. It might even be bit identical to the output of the normal lame encoder with --nores. But because the bit resevoir is not useable, quility is reduced in small but signifigant ways.

Quote
and I do not have hardware to test the app myself
would be nice to get some test results
[a href="index.php?act=findpost&pid=371905"][{POST_SNAPBACK}][/a]
You can get the same result by using "--nores" on a standard lame encoder. That is the flag to disable the resevoir.

  • wisodev
  • [*][*][*]
  • Developer
Multi-threaded LAME 3.97beta2 Out!
Reply #8
Quote
The output of the MT encoder has the same headers, block structure, etc as other lame mp3s.


well it is obvious that headers and blocks structure should be the same
  • Last Edit: 17 March, 2006, 03:53:13 AM by wisodev

  • johnsonlam
  • [*][*][*]
Multi-threaded LAME 3.97beta2 Out!
Reply #9
Quote
The output of the MT encoder has the same headers, block structure, etc as other lame mp3s. It will be identified as a lame produced file by any scanner utility. It might even be bit identical to the output of the normal lame encoder with --nores. But because the bit resevoir is not useable, quility is reduced in small but signifigant ways.

I'm asking the MT version's author to confirm.
Hong Kong - International Joke Center (after 1997-06-30)