LameXP v4.21 Final · Build #2382 (2023-12-29) [Archive] - Page 8

manolito

7th August 2011, 01:50

Here's the log file:

LameXP v4.03 (Build #625), compiled on 2011-08-06 at 21:24:07

-------------------------------

E:/DOKUME~1/Achim/LOKALE~1/Temp/6f584c110cec4c36b708dbaf1de36f90/tool_valdec.exe I:\test.ac3 -w E:\DOKUME~1\Achim\LOKALE~1\Temp\6f584c110cec4c36b708dbaf1de36f90\9c6a9d668efc4fe78d1f38463de837f7.wav

Opening audio output PCM16 3/2.1 (5.1) 48000...
---------------------------------------
Frames/errors: 172143/0
System time: 775065ms
Process time: 576308ms
Approx. 10.46% realtime CPU usage

Exited with code: 0x0000

-------------------------------

E:/DOKUME~1/Achim/LOKALE~1/Temp/6f584c110cec4c36b708dbaf1de36f90/tool_sox.exe -V3 -S --guard --temp . E:\DOKUME~1\Achim\LOKALE~1\Temp\6f584c110cec4c36b708dbaf1de36f90\9c6a9d668efc4fe78d1f38463de837f7.wav E:\DOKUME~1\Achim\LOKALE~1\Temp\6f584c110cec4c36b708dbaf1de36f90\2b50bdf89a474dfca93de87ea139c569.wav remix 1,3,4,5,7,9 2,3,4,6,8,9

E:\DOKUME~1\Achim\LOKALE~1\Temp\6f584c110cec4c36b708dbaf1de36f90\tool_sox.exe: SoX v14.3.2
E:\DOKUME~1\Achim\LOKALE~1\Temp\6f584c110cec4c36b708dbaf1de36f90\tool_sox.exe INFO formats: detected file format type `wav'
E:\DOKUME~1\Achim\LOKALE~1\Temp\6f584c110cec4c36b708dbaf1de36f90\tool_sox.exe INFO wav: EXTENSIBLE
Input File : 'E:\DOKUME~1\Achim\LOKALE~1\Temp\6f584c110cec4c36b708dbaf1de36f90\9c6a9d668efc4fe78d1f38463de837f7.wav'
Channels : 6
Sample Rate : 48000
Precision : 16-bit
Duration : 01:31:48.16 = 264391680 samples ~ 413112 CDDA sectors
File Size : 42949672.08G
Bit Rate : 42949672.542949672.08G
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
E:\DOKUME~1\Achim\LOKALE~1\Temp\6f584c110cec4c36b708dbaf1de36f90\tool_sox.exe INFO sox: Overwriting `E:\DOKUME~1\Achim\LOKALE~1\Temp\6f584c110cec4c36b708dbaf1de36f90\2b50bdf89a474dfca93de87ea139c569.wav'
Output File : 'E:\DOKUME~1\Achim\LOKALE~1\Temp\6f584c110cec4c36b708dbaf1de36f90\2b50bdf89a474dfca93de87ea139c569.wav'
Channels : 2
Sample Rate : 48000
Precision : 16-bit
Duration : 01:31:48.16 = 264391680 samples ~ 413112 CDDA sectors
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
Comment : 'Processed by SoX'
E:\DOKUME~1\Achim\LOKALE~1\Temp\6f584c110cec4c36b708dbaf1de36f90\tool_sox.exe FAIL remix: too few input channels

Exited with code: 0x0002

-------------------------------

Copy file "E:/DOKUME~1/Achim/LOKALE~1/Temp/6f584c110cec4c36b708dbaf1de36f90/2b50bdf89a474dfca93de87ea139c569.wav" to "I://test.wav"

Exited with code: 0x0000

Cheers
manolito

LoRd_MuldeR

7th August 2011, 02:51

Argh, it seems we need different parameters for each number of input channels :rolleyes:

SoX doesn't ignore no-existent channels in the remix mapping, as I had assumed. Instead it will error out, if there are too few channels.

manolito

7th August 2011, 07:17

Alright, the channel mapping of this latest test build works for me...:)

I tested it with several 5.1 AC3 files and also with a 6ch DTS file. No problems, the resulting 2ch files sounded real good, the default sox downmix algorithms seem to work well.

I could not even break it by using a 2ch AC3 source file and still have the downmix option ticked. LameXP seemed to intercept it and did not invoke sox at all.

For a while I thought that it might be a good idea to avoid sox for downmixing and use the decoder downmix capabilities instead. Valdec and Faad both have a command line switch for downmixing which would already cover AC3, DTS and AAC. No idea about the other decoders. Could be faster in many cases. But then again using sox certainly is more "universal".

Anyways, it works for me as it is right now..:cool:

Thanks again

Cheers
manolito

SeeMoreDigital

7th August 2011, 11:35

Out of interest...

Does SoX offer the ability to generate discrete multi-channel encodes from 2-channel "pro logic" encoded sources?

LoRd_MuldeR

7th August 2011, 12:29

Alright, the channel mapping of this latest test build works for me...:)

Thanks for confirming. At last a working solution.

I tested it with several 5.1 AC3 files and also with a 6ch DTS file. No problems, the resulting 2ch files sounded real good, the default sox downmix algorithms seem to work well.

If with "default sox downmix algorithm" you mean the "channels" filter (or "-c" option), then it does not work very well!

It gives an unexpected downmix result. For example, the center would be mixed into left, but not into right.

Here is a good sample to test:
http://www.mediafire.com/file/1c3oobrcnc9nkba/multichannel.wma

With the "remix" filter we can get the desired result, but only if we manually define a channel mapping for each number of input channels.

And it will only work correctly as long as the input uses "Default Channel Ordering" for multiple channel WAVE files...

I could not even break it by using a 2ch AC3 source file and still have the downmix option ticked. LameXP seemed to intercept it and did not invoke sox at all.

Yup, the Downmixing filter isn't invoked for Stereo and Mono sources.

For a while I thought that it might be a good idea to avoid sox for downmixing and use the decoder downmix capabilities instead. Valdec and Faad both have a command line switch for downmixing which would already cover AC3, DTS and AAC. No idea about the other decoders. Could be faster in many cases. But then again using sox certainly is more "universal".

Indeed I need a solution that works will arbitrary decoders. However a shortcut for decoders with "native" downmix support could be implemented.

...as it currently is done with the "resample" filter for encoders that provide "native" re-sampling support.

Does SoX offer the ability to generate discrete multi-channel encodes from 2-channel "pro logic" encoded sources?

Not that I am aware of. But shouldn't we leave "pro logic" decoding to the playback device anyway?

Doesn't make much sense to store 5.1 discrete channels with "pseudo" surround, if we can generate the same "effect" from only 2 discrete channels at playback time.

Amplifiers with more than two discrete speakers generally provide "pro logic" support. And on your computer you can use ffdshow audio decoder, for example.

LoRd_MuldeR

7th August 2011, 14:17

LameXP v4.03 Alpha-9:

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this (http://forum.doom9.org/showthread.php?t=140273) thread for details) and removed all remnants of "old" decoder
* Updated Qt runtime libraries to v4.8.0 Beta-1 (2011-07-19), compiled with MSVC 10.0
* Updated MediaInfo to v0.7.47 (2011-07-27), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed Cue Sheet import for tracks with certain characters in the title
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)

SeeMoreDigital

7th August 2011, 15:42

LoRd_MuldeR

7th August 2011, 16:11

Bummer...

I recently re-encoded my old 1997 DVD version of Blade Runner The Directors Cut to a cropped and re-sized high bit-rate AVC video stream.

Unfortunately all the DVD releases of this movie were encoded with a 2-channel Dolby Digital Pro logic audio track.

I was hoping I could convert this 2-channel Dolby Digital Pro logic audio track to a 5.1 channel Dolby Digital discrete track at 640Kbps.

Why not decode the Digital Pro at playback time?

If you play your DVD's on a PC, you can use your favorite DShow-based player (e.g. MPC-HC) with ffdshow as audio decoder.
Ffdshow has a Dolby Pro Logic (even version "II") decoder "built-in", so you can output discrete 5.1 channels.

And, if you use a "stand alone" player, it probably is connected to a multi-channel amplifier with Pro Logic support. Isn't it?

SeeMoreDigital

7th August 2011, 16:37

Why not decode the Digital Pro at playback time?

And, if you use a "stand alone" player, it probably is connected to a multi-channel amplifier with Pro Logic support. Isn't it?I pump the bit-stream audio from my XtreamerPro hardware media player to my Onkyo surround sound amplifier via HDMI.

Although the Onkyo amplifier has many DSP modes including some THX surround sound modes, it's a case of more buttons to press... And I hate having to go through the ritual of pressing loads of buttons at the start of a movie ;)

manolito

7th August 2011, 18:43

If with "default sox downmix algorithm" you mean the "channels" filter (or "-c" option), then it does not work very well!

No, I was talking about this:
By default, where an output channel is mixed from multiple (n) input channels, each input channel
will be scaled by a factor of ¹/n. Custom mixing volumes can be set by following a given input
channel or range of input channels with a vol-spec (volume specification).
Normally I would assume that the rear channels should be mixed into the stereo file at a lower volume than the front channels. But as I said, the result sounds pretty good to me even without specifying the volume (letting sox use an even scaling factor for each channel).

BTW I cannot download the latest build from SourceForge ATM. Something is wrong with the links, it sends me into a loop.

Cheers
manolito

LoRd_MuldeR

7th August 2011, 20:31

Normally I would assume that the rear channels should be mixed into the stereo file at a lower volume than the front channels. But as I said, the result sounds pretty good to me even without specifying the volume (letting sox use an even scaling factor for each channel).

You are right. Giving the same weight to all channels probably isn't the optimal choice. Mixing the "center" input channel into the "left" and "right" output channels with the same weight as the the "right" or "left" input channels gives a bias towards "center". More correct would be 2/3 left + 1/3 center for the left channel and 2/3 right + 1/3 center for the right channel, I think. We can give that a try. Still the question is how much weight the back/side channels should get, compared to main (left/right) and center. I am open for suggestions here...

BTW I cannot download the latest build from SourceForge ATM. Something is wrong with the links, it sends me into a loop.

I can confirm. Looks like a problem at SourceForge.net. The file was uploaded hours ago, but is only available from one single mirror ("Waix") at this time.

And even that mirror doesn't seems to work, it just redirects to the "Files" page. Anyway, you can use Auto-Update for now...

manolito

7th August 2011, 21:38

Anyway, you can use Auto-Update for now...Thanks...

Luckily the correct values for different downmix scenarios have already been established...:) Tebasuna and Selur seem to be the guys to talk to.

Here is a link to a corresponding thread:
http://forum.doom9.org/showthread.php?p=1362794#post1362794

For stereo downmix this post is the one to look at:
http://forum.doom9.org/showthread.php?p=1363496#post1363496

Hope this helps...

Cheers
manolito

LoRd_MuldeR

7th August 2011, 23:02

I can't really follow these posts, but I tweaked the channels weights for the downmix filter some more:
https://github.com/lordmulder/LameXP/commit/35e80de71d00b21a427f116236f2e17307986199#src/Filter_Downmix.cpp

Basic idea: If we first create a Stereo downmix and later downmix further to Mono from there, then Center and LFE should have the same volume as Left/Right in the final mix. This means that the Center and LFE channels have to be reduced to 50% (compared to the Left/Right main channels) in the Stereo mix, because Center and LFE are mixed into both, the Left and the Right output channels. So the reduction to 50% will avoid the bias towards Center/LFE in the downmix. Moreover the Back (Surround) channels will also be reduced compared to the main channels. Sample attached.

manolito

7th August 2011, 23:31

According to Selur's post the sox remix values for stereo downmix of a 6ch source should be:

1v0.3694+3v0.2612+4v0.3694 2v0.3694+3v0.2612+5v0.3694

Note that only channels 1,3,4 are used for the left channel, 2,3,5 for the right channel.

Your channel assignment for a 6ch source is 1,3,4,5 and 2,3,4,6 which is somewhat different...:confused:

Anyways, your stereo mix sounds pretty good.

Cheers
manolito

LoRd_MuldeR

7th August 2011, 23:51

According to Selur's post the sox remix values for stereo downmix of a 6ch source should be:

1v0.3694+3v0.2612+4v0.3694 2v0.3694+3v0.2612+5v0.3694

Note that only channels 1,3,4 are used for the left channel, 2,3,5 for the right channel.

These numbers can not refer to the Default Channel Ordering (http://msdn.microsoft.com/en-us/windows/hardware/gg463006) for WAVE files!

Otherwise he would be mixing "LFE" into the Left channel only, mixing "Back Left" into the Right channel only and not using "Back Right" at all - which wouldn't make much sense ;)

Instead I assume he is mixing "Back Left" into Left, "Back Right" into Right and leaving out the LFE channel completely.

Except for the LFE and the different weights (it seems he is using the same weight for "main" and "back" plus some bias to the "center"), that is identical to my choice.

Romario

8th August 2011, 02:09

LoRd_MuldeR

8th August 2011, 02:17

Latest Beta on http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2011-08-07/ is BROKEN. When I click to download files, nothing happened, just redirects me on other page...please fix it or give us others links.

Please read the comment above:
http://forum.doom9.org/showpost.php?p=1518317&postcount=362

There are more reports of problems with the SourceForge file release system:
http://sourceforge.net/apps/trac/sourceforge/ticket/21078

manolito

8th August 2011, 02:17

This is old news...
I can confirm. Looks like a problem at SourceForge.net. The file was uploaded hours ago, but is only available from one single mirror ("Waix") at this time.

And even that mirror doesn't seems to work, it just redirects to the "Files" page. Anyway, you can use Auto-Update for now...

Just use Auto-Update

Cheers
manolito

//Edit
Oops. MuldeR was faster than me...

LoRd_MuldeR

8th August 2011, 12:28

Please read the comment above:
http://forum.doom9.org/showpost.php?p=1518317&postcount=362

There are more reports of problems with the SourceForge file release system:
http://sourceforge.net/apps/trac/sourceforge/ticket/21078

Seems like the problem has been fixed.

Works for me:
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2011-08-07/LameXP.2011-08-07.Release-Static.Build-628.exe/download

LoRd_MuldeR

8th August 2011, 21:13

LameXP v4.03 Alpha-10:

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this (http://forum.doom9.org/showthread.php?t=140273) thread for details) and removed all remnants of "old" decoder
* Added a menu for bookmarking "favorite" output folders to the "output folder" tab
* Updated Qt runtime libraries to v4.8.0 Beta-1 (2011-07-19), compiled with MSVC 10.0
* Updated MediaInfo to v0.7.47 (2011-07-27), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed Cue Sheet import for tracks with certain characters in the title
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)

Romario

9th August 2011, 01:25

Ok,it's work now. Thank you for your explanation.

manolito

9th August 2011, 04:16

Some more thoughts about downmixing:

http://ac3filter.net/wiki/Mixing_matrix
According to this the downmix volumes should be "normalized" to avoid clipping.

http://www.surroundassociates.com/tapeprep.html
http://www.ocularstudio.com/why-surround-better-stereo-or-quadro

According to these two links channel assignment for DTS is often different.

What do we do when downmixing DTS sources? Valdec decodes DTS in LameXP, does it reassign the channels to the "standard" assignment?

Cheers
manolito

LoRd_MuldeR

9th August 2011, 11:41

Some more thoughts about downmixing:

http://ac3filter.net/wiki/Mixing_matrix
According to this the downmix volumes should be "normalized" to avoid clipping.

That's what SoX does by default. When mixing together n channels, the volume of each channel is reduced to 1/n.

So in sum the volume cannot exceed 1.0, which prevents clipping.

When using "custom" weights you have to take care that the sum of all weights (per channel) is 1.0 or below. Otherwise clipping is possible.

Of course I tried to choose weights that exactly match 1.0 in sum ;)

According to these two links channel assignment for DTS is often different.

What do we do when downmixing DTS sources? Valdec decodes DTS in LameXP, does it reassign the channels to the "standard" assignment?

Well, when implementing a "downmix" filter some channel mapping has to be assume.

As said before, LameXP now assumes the "Default Channel Ordering" for multiple channel WAVE files.

I think any decoder which outputs WAVE files is supposed to use that channel mapping...

(In theory different channel mappings could be used/assumed, depending on the individual input format or decoder of the current file.
But at the moment the "dowmix" filter doesn't know about input formats. And, in a well-designed system, it shouldn't have to!)

LoRd_MuldeR

15th August 2011, 22:15

LameXP v4.03 Alpha-12:

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this thread for details) and removed all remnants of "old" decoder
* Added a menu for bookmarking "favorite" output folders to the "output folder" tab
* Updated Qt runtime libraries to v4.8.0 Beta-1 (2011-07-19), compiled with MSVC 10.0
* Updated MediaInfo to v0.7.47 (2011-07-27), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed Cue Sheet import for tracks with certain characters in the title
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)
* Restored Windows 2000 support with Visual Studio 2010 (this is experimental!)

Seems like I finally figured out a feasible way to make Visual Studio 2010 binaries run on Windows 2000:
http://mulder.googlecode.com/svn/trunk/Utils/EncodePointerLib/README.txt

(And yes, I am well aware that the EncodeDecodePointer substitute function does not provide the extra "protection" of the original implementation)

LoRd_MuldeR

19th August 2011, 15:55

LameXP v4.03 Alpha-13:

This version adds experimental support for the FHG AAC Encoder that is included with latest Winamp.
You will need the Add-in to enable the FHG AAC Encoder in LameXP. See the included instructions!

manolito

19th August 2011, 22:07

Just out of curiosity:
Do you think that the FHG AAC encoder has an edge over Nero?
(HydrogenAudio is conducting a listening test, but no results so far...)

Cheers
manolito

LoRd_MuldeR

19th August 2011, 22:15

Just out of curiosity:
Do you think that the FHG AAC encoder has an edge over Nero?

I will leave that decision up to the users. Haven't done any comprehensive tests yet.

LoRd_MuldeR

21st August 2011, 14:54

LameXP v4.03 Alpha-14:

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this (http://forum.doom9.org/showthread.php?t=140273) thread for details) and removed all remnants of "old" decoder
* Added optional support for the FHG AAC Encoder (see the FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for install instructions!)
* Added a menu for bookmarking "favorite" output folders to the "output folder" tab
* Updated Qt runtime libraries to v4.8.0 Beta-1 (2011-07-19), compiled with MSVC 10.0
* Updated MediaInfo to v0.7.48 (2011-08-17), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed Cue Sheet import for tracks with certain characters in the title
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)
* Restored Windows 2000 support with Visual Studio 2010 (this is experimental!)

Brazil2

22nd August 2011, 11:21

LameXP v4.03 Alpha-14:
* Added optional support for the FHG AAC Encoder (see the FAQ doc for install instructions!)
You may want to check this wrapper which is only 18KB, compared to the 398KB of the one you link to, and source code is included:
http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=89518&view=findpost&p=763079

And in your FAQ (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) you provide a direct link to a version of Winamp which is the German only version. You may want to link either to the English version (http://download.nullsoft.com/winamp/client/winamp5621_full_emusic-7plus_en-us.exe) and/or to the international version (http://download.nullsoft.com/winamp/client/winamp5621_full_emusic-7plus_all.exe) which includes German, Dutch, French, Italian, Polish, Russian, Spanish, Swedish, Korean, Japanese, Chinese, Turkish, Portuguese and Romanian languages.

Just my two cents :)

LoRd_MuldeR

22nd August 2011, 12:08

You may want to check this wrapper which is only 18KB, compared to the 398KB of the one you link to, and source code is included:
http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=89518&view=findpost&p=763079

That's exactly the one I use ;)

(As you may have noticed, I linked 'libsndfile' in a static way in order to get rid of another DLL dependency, which explains the different size of the EXE file)

And in your FAQ (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) you provide a direct link to a version of Winamp which is the German only version. You may want to link either to the English version (http://download.nullsoft.com/winamp/client/winamp5621_full_emusic-7plus_en-us.exe) and/or to the international version (http://download.nullsoft.com/winamp/client/winamp5621_full_emusic-7plus_all.exe) which includes German, Dutch, French, Italian, Polish, Russian, Spanish, Swedish, Korean, Japanese, Chinese, Turkish, Portuguese and Romanian languages.

You are right. I will change the link to point to the 'international' version.

b66pak

22nd August 2011, 18:55

LoRd_MuldeR

22nd August 2011, 19:01

hi, by any chance did you modify the sources to add support for stdout? (for adts CBR)?
_

I don't know if output to 'stdout' is possible with their encoder API :confused:

Output as MP4 probably requires random access to the output file, which isn't possible when writing to stdout. ADTS might work though (in theory).

Also I think the CBR limitation of ADTS mode is a limitation of the encoder library, not of the CLI front-end...

nik33134

24th August 2011, 14:21

Hi I have an old Athlon 64 3200+ running WinXP 32bit, and find the old version of LameXP (LameXP v3.18 Hotfix-2 Build 88) to be twice as fast when encoding 320kb constant bitrate mp3s, vs the 4.02 build 578. My only complaint is that the old version keeps bugging me that the code is more than a year old and I have to update (by the way, the check for updates is disabled). If I choose cancel, the program closes, and if I choose "yes", it goes online and checks for updates. Please tell me there's a way to disable this, because it's driving me nuts. I want to stick with the old version. Thanks

LoRd_MuldeR

24th August 2011, 19:51

Hello, nik33134.

Hi I have an old Athlon 64 3200+ running WinXP 32bit, and find the old version of LameXP (LameXP v3.18 Hotfix-2 Build 88) to be twice as fast when encoding 320kb constant bitrate mp3s, vs the 4.02 build 578.

That's a quite surprising result :eek:

My only complaint is that the old version keeps bugging me that the code is more than a year old and I have to update (by the way, the check for updates is disabled). If I choose cancel, the program closes, and if I choose "yes", it goes online and checks for updates.

It's intentional. Most users simply refuse to update and stick with archaic versions. So we need to help them a bit ;)

Please tell me there's a way to disable this, because it's driving me nuts.

Not without compiling your own "custom" build from the sources :o

I want to stick with the old version. Thanks

The old 3.xx is version has been deprecated and it's highly recommended to update to 4.xx now!

There are just too many nasty restrictions in the old version (no support of Unicode file names or tags !!!) and the audio tools that were used in the old version are outdated too.

So would you please run the following benchmark on your system and post the results, then we might be able to find out what is going wrong:
http://www.mediafire.com/file/ct5yk2144j5wixn/benchmark.2011-08-24.rar

(This includes the LAME build that was used in LameXP v3.18 Hotfix-2 Build 88, the build that is used in the current version as well as another build for comparison).

Here are my results:
vendor_id : GenuineIntel
cpu family : 6
model : 15
stepping : 7
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm nx lm lahf_lm
cpu MHz : 2398.008
model name : Intel(R) Core(TM)2 Quad CPU @ 2.40GHz

[VBR MODE]
lame-3.98.4-GEN.exe 8 2.113739 0.006455 D:\SVN\Tools\LAME\benchmark\\bin\lame-3.98.4-GEN.exe -h -V2 --nohist D:\SVN\Tools\LAME\benchmark\\etc\Input.wav NUL
lame-3.99.0-ICC.exe 8 2.151387 0.012290 D:\SVN\Tools\LAME\benchmark\\bin\lame-3.99.0-ICC.exe -h -V2 --nohist D:\SVN\Tools\LAME\benchmark\\etc\Input.wav NUL
lame-3.99.0-MSC.exe 8 2.318193 0.011178 D:\SVN\Tools\LAME\benchmark\\bin\lame-3.99.0-MSC.exe -h -V2 --nohist D:\SVN\Tools\LAME\benchmark\\etc\Input.wav NUL

[CBR MODE]
lame-3.98.4-GEN.exe 8 3.770149 0.076191 D:\SVN\Tools\LAME\benchmark\\bin\lame-3.98.4-GEN.exe -h --cbr -b 320 --nohist D:\SVN\Tools\LAME\benchmark\\etc\Input.wav NUL
lame-3.99.0-ICC.exe 8 3.257647 0.038184 D:\SVN\Tools\LAME\benchmark\\bin\lame-3.99.0-ICC.exe -h --cbr -b 320 --nohist D:\SVN\Tools\LAME\benchmark\\etc\Input.wav NUL
lame-3.99.0-MSC.exe 8 3.556128 0.003099 D:\SVN\Tools\LAME\benchmark\\bin\lame-3.99.0-MSC.exe -h --cbr -b 320 --nohist D:\SVN\Tools\LAME\benchmark\\etc\Input.wav NUL
Concision for my system:
The "old" build was slightly faster in VBR mode and significant slower in CBR mode, compared to the "up-to-date" build.

b66pak

24th August 2011, 20:24

Here are my results:
vendor_id : AuthenticAMD
cpu family : 15
model : 47
stepping : 2
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 pni syscall nx mmxext fxsr_opt lm 3dnowext 3dnow lahf_lm
cpu MHz : 2380.318
model name : AMD Athlon(tm) 64 Processor 3800+

[VBR MODE]
lame-3.98.4-GEN.exe 8 2.653358 0.005877 F:\benchmark.2011-08-24\\bin\lame-3.98.4-GEN.exe -h -V2 --nohist F:\benchmark.2011-08-24\\etc\Input.wav NUL
lame-3.99.0-ICC.exe 8 2.942623 0.006475 F:\benchmark.2011-08-24\\bin\lame-3.99.0-ICC.exe -h -V2 --nohist F:\benchmark.2011-08-24\\etc\Input.wav NUL
lame-3.99.0-MSC.exe 8 3.315548 0.007737 F:\benchmark.2011-08-24\\bin\lame-3.99.0-MSC.exe -h -V2 --nohist F:\benchmark.2011-08-24\\etc\Input.wav NUL

[CBR MODE]
lame-3.98.4-GEN.exe 8 5.171427 0.012839 F:\benchmark.2011-08-24\\bin\lame-3.98.4-GEN.exe -h --cbr -b 320 --nohist F:\benchmark.2011-08-24\\etc\Input.wav NUL
lame-3.99.0-ICC.exe 8 4.843703 0.006763 F:\benchmark.2011-08-24\\bin\lame-3.99.0-ICC.exe -h --cbr -b 320 --nohist F:\benchmark.2011-08-24\\etc\Input.wav NUL
lame-3.99.0-MSC.exe 8 5.425726 0.004313 F:\benchmark.2011-08-24\\bin\lame-3.99.0-MSC.exe -h --cbr -b 320 --nohist F:\benchmark.2011-08-24\\etc\Input.wav NUL

Wed 08/24/2011 - 22:23:11.17
_

LoRd_MuldeR

24th August 2011, 20:31

b66pak, interesting results. Even though you have an AMD processor, the ICL build (as used in current LameXP) still is significant faster than the MSVC build.

Also your results confirm that the "old" build was a bit faster in VBR mode (although the difference is bigger than on my system) and slower in CBR mode, compared to the "up-to-date" build.

However this doesn't explain what nik33134 is reporting. He claims that the "old" build was faster in CBR mode. And he uses a very similar CPU :confused:

nik33134

24th August 2011, 23:08

So here are the results I got:

vendor_id : AuthenticAMD
cpu family : 15
model : 47
stepping : 0
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 pni syscall nx mmxext fxsr_opt lm 3dnowext 3dnow lahf_lm
cpu MHz : 1995.039
model name : AMD Athlon(tm) 64 Processor 3200+

[VBR MODE]
lame-3.98.4-GEN.exe 8 3.203830 0.031366 "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\bin\lame-3.98.4-GEN.exe" -h -V2 --nohist "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\etc\Input.wav" NUL
lame-3.99.0-ICC.exe 8 3.548249 0.112188 "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\bin\lame-3.99.0-ICC.exe" -h -V2 --nohist "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\etc\Input.wav" NUL
lame-3.99.0-MSC.exe 8 4.010275 0.228478 "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\bin\lame-3.99.0-MSC.exe" -h -V2 --nohist "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\etc\Input.wav" NUL

[CBR MODE]
lame-3.98.4-GEN.exe 8 6.203974 0.026840 "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\bin\lame-3.98.4-GEN.exe" -h --cbr -b 320 --nohist "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\etc\Input.wav" NUL
lame-3.99.0-ICC.exe 8 5.810394 0.007591 "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\bin\lame-3.99.0-ICC.exe" -h --cbr -b 320 --nohist "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\etc\Input.wav" NUL
lame-3.99.0-MSC.exe 8 6.503573 0.004490 "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\bin\lame-3.99.0-MSC.exe" -h --cbr -b 320 --nohist "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\etc\Input.wav" NUL

Thu 08/25/2011 - 1:00:20.28

LoRd_MuldeR

24th August 2011, 23:22

This shows that the "new" version encodes a bit slower (but certainly not two times!) in VBR mode and encodes quite a bit faster in CBR mode, compared to the "old" version.

I can't see how this matches your previous report :confused:

How exactly did you measure the speed of LameXP v4.03 against v3.18 on your system before? And are you absolutely sure that you got the latest build of LameXP v4.03 (build #664 at this moment) ???

Also: Is your processor single or dual core? And how many encoder instances are you running in parallel? How is the CPU usage - encoder process(es) -vs- LameXP main process - while encoding?

nik33134

24th August 2011, 23:53

LoRd_MuldeR

25th August 2011, 00:04

Ok, I just encoded a 7:26 flac to mp3 with the old version (constant bitrate 320, max quality, at 44100Hz, auto select channel mode) and the encoding took 1:12:34. Then I used the new version 4.02 build 578 (320 CBR, best quality, 44100Hz, auto select), and got 2:18:36. The new version created an mp3 of 17,886,730 bytes, and the old version a 17,858,745 bytes mp3 file.

Is this the time for encoding only or including the decoding of the input file? BTW: What is the format of the input file?

Oh, and can you please update to the latest v4.03 build? Enable "Tools" -> "Configuration" -> "Check for Beta Updates" and then check for updates!

I have a single core and use only one instance at a time. My observations have been empirical, and this is the first time that I used a stopwatch while encoding. But it's always been like this for me when I compared with the eye (how fast he percentage numbers change). Now either the benchmark does not fit the situation, or I don't know what...

Well, the benchmark compares the encoder binary used by LameXP v4.03 against the one that was used v3.18.

And your results clearly show that the difference in pure encoding speed is rather small. Also it shows that the "new" version encodes even faster in CBR mode.

There are still two scenarios I can think of:
(a) The encoding parameters are different between v4.03 and v3.18 in some way. If slower/faster settings were used, this would explain the difference.
(b) The LameXP v4.03 front-end process uses significantly more CPU time than v3.18 on your system and this way slows down the encoder process.

Can you please check both things with the help of ProcessExplorer (http://technet.microsoft.com/en-us/sysinternals/bb896653) ???

nik33134

25th August 2011, 00:29

My original file is a FLAC, and the times that I state are only the encoding time, without the initial decoding time. I have not updated to the latest beta yet. I just run another test with the same file with ABR 192kbps. Results are 2:06:43 with the new stable version, and 1:16:54 with the old version. I will try to use the process explorer and see if I can see anything. My XP has 2 Gigs of memory and is pretty slimmed down (few services, and no unnecessary programs running, only Avira and firefox).

LoRd_MuldeR

25th August 2011, 00:33

My original file is a FLAC, and the times that I state are only the encoding time, without the initial decoding time. I have not updated to the latest beta yet.

Can you please update to the latest build now?

I just run another test with the same file with ABR 192kbps. Results are 2:06:43 with the new stable version, and 1:16:54 with the old version. I will try to use the process explorer and see if I can see anything. My XP has 2 Gigs of memory and is pretty slimmed down (few services, and no unnecessary programs running, only Avira and firefox).

Please check the CPU usage of "LameXP.exe" (front-end process) and "lame.exe" (encoder process) in ProcessExplorer while encoding. Do that for version 3.18 as well as for version 4.03.

Also in the properties of the "lame.exe" process check the "command line" field - again for both versions. If there is a difference in the command-line arguments, it may explain the difference.

nik33134

25th August 2011, 00:58

Ok, I updated to the latest beta. I run process explorer and got CPU usage at 98.44% to 100% for both the old, and the new versions (ool_lame.exe and ool_lameenc.exe). The lameXP.exe showed no CPU usage at all in either version. In the new version I had a console running that displayed "This OS doesn't support ItaskbarList3 interface".

The times for the encode this time were 1:12:39 for the old version, and 2:17:79 for the new beta, for the same 52.7MB Flac file.

LoRd_MuldeR

25th August 2011, 01:08

Ok, I updated to the latest beta. I run process explorer and got CPU usage at 98.44% to 100% for both the old, and the new versions (ool_lame.exe and ool_lameenc.exe). The lameXP.exe showed no CPU usage at all in either version.

Good. So 'LameXP.exe' eating too much CPU time is not the problem :)

In the new version I had a console running that displayed "This OS doesn't support ItaskbarList3 interface".

That message is normal on pre-Win7 systems. Nothing to worry about.

(The debug console is shown for all Beta versions)

The times for the encode this time were 1:12:39 for the old version, and 2:17:79 for the new beta, for the same 52.7MB Flac file.

Did you check the "Command line" for 'tool_lame(enc).exe' for both versions? You find it by right-click and Properties in the ProcessExplorer.

nik33134

25th August 2011, 01:23

LoRd_MuldeR

25th August 2011, 01:42

Yes, the parameter for the new version is:
tool_lame.exe --nohist -q 0 --cbr -b 320 --resample 44100 --tt "Theme from 'Antarctica'" --ta Vangelis --tl "The Best Of Instrumental Works" --tg Instrumental --tc "Encoded with LameXP" --ty 2008 --tn 1 --ti

For the old version, it's:
tool_lameenc.exe" --nohist -q 0 -b 320 --resample 44.1 --add-id3v2 --tt "Theme from 'Antarctica'" --ta "Vangelis" --tl "The Best Of Instrumental Works" --ty 2008 --tc "Encoded with LameXP" --tn 1 --tg "Instrumental"

So you are using ultra slow placebo encoder settings and then you complain about speed? :devil:

I can re-produce that the "new" version indeed is noticeably slower than the "old" version when using these ultra slow placebo settings!

Of course both versions are SLOW with such settings. So try to use something more sane, like "-q 2", which is equivalent to "-h".

(It is the "LAME Algorithm Quality" slider that you want to adjust)

Is the 100% CPU usage normal?

Yes, normal and desirable ;)

CPU usage is the percentage of time that your CPU is working, i.e. not sleeping (waiting for I/O).

When encoding, you want your CPU to sleep as few as possible, right? ^^

nik33134

25th August 2011, 01:54

I see now. But how do I set the q to not be zero. Is it from the "Advanced Options" menu, the Lame Algorithm Quality? I've always set it to "best" in the past, should I set it to high quality instead? Anyways, thank you for your help.

LoRd_MuldeR

25th August 2011, 02:02

I see now. But how do I set the q to not be zero. Is it from the "Advanced Options" menu, the Lame Algorithm Quality?

Exactly :)

I've always set it to "best" in the past, should I set it to high quality instead?

Well, tweaking an encoder for "speed -vs- quality" always is a trade-off.

So if you want to squish out more quality at the same bitrate, then you have to accept a slower encoding speed. That's live.

However there always is a point where using even slower settings only gives a very minor additional improvement (if at all) for a significant additional speed cost.

Obviously you would only use such "placebo" settings, if you don't care about speed at all ;)

The LAME manual says:

-q 0: use slowest & best possible version of all algorithms. -q 0 and -q 1 are slow and may not produce higher quality.
-q 2: recommended. Same as -h.
-q 5: default value. Good speed, reasonable quality.
-q 7: same as -f. Very fast, ok quality.

Anyways, thank you for your help.

No problem.

LoRd_MuldeR

27th August 2011, 19:46

LameXP v4.03 Beta-1:
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2011-08-27/

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined naming pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this (http://forum.doom9.org/showthread.php?t=140273) thread for details) and removed all remnants of "old" decoder
* Added optional support for the FHG AAC Encoder included with Winamp 5.62 (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added a menu for bookmarking "favorite" output folders to the "output folder" tab
* Updated Qt runtime libraries to v4.8.0 Beta-1 (2011-07-19), compiled with MSVC 10.0
* Updated MediaInfo to v0.7.48 (2011-08-17), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed Cue Sheet import for tracks with certain characters in the title
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)
* Restored Windows 2000 support with Visual Studio 2010 builds (this is experimental!)
* The "Open File(s)" and "Open Folder" dialogs will now remember the most recent directory
* Miscellaneous bugfixes