IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
Multi-threaded LAME 3.97beta2 Out!
johnsonlam
post Mar 14 2006, 14:51
Post #1





Group: Members
Posts: 226
Joined: 12-January 03
From: Kowloon, Hong Kong
Member No.: 4533



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)
Go to the top of the page
+Quote Post
Gabriel
post Mar 14 2006, 15:35
Post #2


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



I do not know about this version, but previous versions provided LOWER QUALITY than default Lame, as they required to disable bit reservoir.
Go to the top of the page
+Quote Post
CiTay
post Mar 14 2006, 16:29
Post #3


Administrator


Group: Admin
Posts: 2378
Joined: 22-September 01
Member No.: 3



QUOTE (Gabriel @ Mar 14 2006, 03:35 PM)
I do not know about this version, but previous versions provided LOWER QUALITY than default Lame, as they required to disable bit reservoir.
*


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.
Go to the top of the page
+Quote Post
johnsonlam
post Mar 16 2006, 10:31
Post #4





Group: Members
Posts: 226
Joined: 12-January 03
From: Kowloon, Hong Kong
Member No.: 4533



QUOTE (CiTay @ Mar 14 2006, 11:29 PM)
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.
*



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)
Go to the top of the page
+Quote Post
Gabriel
post Mar 16 2006, 12:04
Post #5


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



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.
Go to the top of the page
+Quote Post
wisodev
post Mar 16 2006, 12:42
Post #6





Group: Developer
Posts: 123
Joined: 31-January 06
Member No.: 27439



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

This post has been edited by wisodev: Mar 16 2006, 12:42


--------------------
http://code.google.com/p/wavtoac3encoder/
Go to the top of the page
+Quote Post
Gabriel
post Mar 16 2006, 15:19
Post #7


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



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.
Go to the top of the page
+Quote Post
Klyith
post Mar 17 2006, 03:47
Post #8





Group: Members (Donating)
Posts: 352
Joined: 10-July 04
From: Albany NY USA
Member No.: 15259



QUOTE (wisodev @ Mar 16 2006, 07:42 AM)
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
*
You can get the same result by using "--nores" on a standard lame encoder. That is the flag to disable the resevoir.
Go to the top of the page
+Quote Post
wisodev
post Mar 17 2006, 09:52
Post #9





Group: Developer
Posts: 123
Joined: 31-January 06
Member No.: 27439



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

This post has been edited by wisodev: Mar 17 2006, 09:53


--------------------
http://code.google.com/p/wavtoac3encoder/
Go to the top of the page
+Quote Post
johnsonlam
post Mar 21 2006, 07:03
Post #10





Group: Members
Posts: 226
Joined: 12-January 03
From: Kowloon, Hong Kong
Member No.: 4533



QUOTE (Klyith @ Mar 17 2006, 10:47 AM)
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)
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 16th September 2014 - 04:55