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 (http://www.lame-mt.com)
I do not know about this version, but previous versions provided LOWER QUALITY than default Lame, as they required to disable bit reservoir.
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:
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.
Right, it still requires that, i just tested lame-mt.3.97b2.cl_32.exe on an A64 X2:
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?
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.
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
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.
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.
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.
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
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.