LameXP v4.21 Final · Build #2382 (2023-12-29)

[LoRd_MuldeR]

Beta-2 is out :)

This version contains a few minor improvements and completes the "Advanced Options" tab. The "normalization", "resampling" and "bass/treble adjustment" filters should be working now.

Furthermore this version introduces a "true" portable mode, which will keep the configuration (INI file) in the same folder where the EXE file is located.

In order to enable the "portable" mode, simply rename the 'LameXP.exe' to 'LameXP-Portable.exe'. However you have to make sure that the application folder is writable for non-elevated processes!

(Therefore using LameXP with "portable" mode from a location in 'C:\Program Files' or 'C:\Program Files (x86)' will not work correctly on Vista/Win7)

[SeeMoreDigital]

I'm lovin' it. Great work :)

[LoRd_MuldeR]

Beta-3 is out :)

This version adds shell integration (explorer context menu) + support for additional input formats + ability to import playlist files.

I also created a poll, so people can vote for their favorite UI style now:
http://mulder.brhack.net/temp/style_poll/

(If enough people vote, I will the make the most popular UI style the new default style)

[cengizhan]

i like your program but one thing. every time i open the program, in metatag tab i have to change position and comment to (not specified). please do not reset this settings with every run. why are not these settings saved?

[LoRd_MuldeR]

i like your program but one thing. every time i open the program, in metatag tab i have to change position and comment to (not specified). please do not reset this settings with every run. why are not these settings saved?

I do not reset these settings. I simply do not save their current value on program exit ;)

That's because I consider the "Meta Data" fields as something that you'll have to update (re-enter) for every album/collection you convert anyway. If I would save these information, there is the danger that the user forgets to look at the "Meta Data" tab and thus some old and completely unrelated meta information that were saved from a previous encode long time ago will be embedded...

(BTW: I see you are from Turkey. Would you like to translate (http://mulder.brhack.net/public/doc/lamexp_translate.html) the software to Turkish language? ^^)

[cengizhan]

then can you set track field to (not specified) instead of generate from list position? also comment field from encoded with lamexp to blank? Because it overwrites previous comments.

And i can help to translate.

[mariush]

Mulder, I like the Cleanlooks design, except the dropdown list double arrow thing, which is easily confused with the up-down select thingie. I don't know if you can combine them but if you could it would be great.

[LoRd_MuldeR]

then can you set track field to (not specified) instead of generate from list position? also comment field from encoded with lamexp to blank? Because it overwrites previous comments.

I'm not planning to change the defaults for "Comment" and "Position" options.

However, in contrast to the other fields in the "Meta Data" tab, it might make sense to save/restore these two fields on program exit/launch.

So that will probably be the way to go...

And i can help to translate.

Nice. Then please see the LameXP translator's guide here:
http://mulder.brhack.net/public/doc/lamexp_translate.html

If you have any questions, feel free to PM me at any time...

Mulder, I like the Cleanlooks design, except the dropdown list double arrow thing, which is easily confused with the up-down select thingie. I don't know if you can combine them but if you could it would be great.

Sorry, that is not possible. The "style" is setup up globally, for the QApplication object. AFAIK you can't change the style for individual widgets (or individual widget classes).

I probably could create my own QStyle class, mixing aspects from QPlastiqueStyle and QCleanlooksStyle, but that's something I'm not currently planning...

(It would probably require digging into a lot of "low level" implementation details of Qt)

[manolito]

Just tried to test the current beta3, but no luck here...:confused:

I just get the debug console, CPU load stays at 90%, no other window appears. My system is WinXP SP3 with all current updates. I have full admin rights, and all compatibility options also make no difference. I do have a couple of VC++ redistributables installed (from 2005 to 2008).

Do I need to install some other libraries first? If so, could you provide download links for them?


Cheers
manolito

[LoRd_MuldeR]

I just get the debug console, CPU load stays at 90%, no other window appears.

It's normal and expected to the see the console window, as the console is enabled by default in all Beta builds (will be disabled by default in the "Final" version).

So what does the console say? At which point it stops proceeding?

And are you sure you aren't in "Mark" mode ("Edit -> Mark" or a simple left-click with QuickEdit enabled) in the console? As long as you are in "Mark" mode, the application will be frozen!

Also: In my experience poor "Anti Virus" software can slow-down the start-up process significantly! It's quite possible that you just have to wait a little longer...

(In my personal experience Avira Antivir is pretty fast, Microsoft Security Essentials is slower but still okay and NOD32 is slow like hell)

My system is WinXP SP3 with all current updates.

Windows XP with Service-Pack 3 is one of my test platforms. And I have not experienced any problems so far...

I have full admin rights, and all compatibility options also make no difference.

Please keep all compatibility options disabled. LameXP even would refuse to continue with compatibility mode enabled ;)

I do have a couple of VC++ redistributables installed (from 2005 to 2008).

Well, that's nice :p

But the pre-compiled LameXP binaries have been linked against the static MSVCR libraries, so you do not need to install the VC++ Redistributables.

(It certainly doesn't hurt to have them installed, but the pre-compiled LameXP binaries simply won't be effected)

Do I need to install some other libraries first? If so, could you provide download links for them?

Nope. The pre-compiled binaries of LameXP are fully self-contained and work "out-of-the-box".

All dependencies have been linked statically for maximum ease of use. Still you might want to verify this with Dependency Walker, if you don't trust me ;)

http://img94.imageshack.us/img94/8048/lamexpdepends.th.jpg (http://img94.imageshack.us/img94/8048/lamexpdepends.jpg)

[nitinpushpan]

Hi,
Firstly, Thank you for such a nice software. I've been using it for few days and I think it is one of the best audio encoding software. Secondly, I'd like to address an issue that I noticed. I'm not sure whether its only happening to me. I'm using v4.00 Beta-3 (Build 290) on Windows 7 Home Premium (x64). While encoding flac files to AAC using Nero AAC v1.5.4 (Quality level 0.50) I get an error and the log reads as follows:

The format of this file is NOT supported:
C:/Users/Nitin/Desktop/The Black Eyed Peas - 01 - The Time (The Dirty Bit).flac

Container Format:
Audio Format:

Now this happened when I disabled the option "Write meta information to encoded files" under the Meta Data tab. I works fine when it the option is enabled.

Keep up the good work!

[LoRd_MuldeR]

Hi,
Firstly, Thank you for such a nice software. I've been using it for few days and I think it is one of the best audio encoding software. Secondly, I'd like to address an issue that I noticed. I'm not sure whether its only happening to me. I'm using v4.00 Beta-3 (Build 290) on Windows 7 Home Premium (x64). While encoding flac files to AAC using Nero AAC v1.5.4 (Quality level 0.50) I get an error and the log reads as follows:



Now this happened when I disabled the option "Write meta information to encoded files" under the Meta Data tab. I works fine when it the option is enabled.

Keep up the good work!

I can reproduce the problem. Thank you for reporting this serious bug! I will look for a fix as soon as possible...

[LoRd_MuldeR]

I can reproduce the problem. Thank you for reporting this serious bug! I will look for a fix as soon as possible...

A new build is now available via auto-update. This (hopefully) fixes the issue :)

Can you please test with and without having "write meta tags" enabled? Can you also test with "write meta tags" enabled and having some custom tags specified on the "meta data" tab?

:thanks:

[manolito]

It's normal and expected to the see the console window, as the console is enabled by default in all Beta builds (will be disabled by default in the "Final" version).

So what does the console say? At which point it stops proceeding?

It stops right after the disclaimer. The last words are "ABSOLUTELY NO WARRANTY". After this there is a blinking cursor, and that's it.

And are you sure you aren't in "Mark" mode ("Edit -> Mark" or a simple left-click with QuickEdit enabled) in the console? As long as you are in "Mark" mode, the application will be frozen!

No, I am not in "Mark" mode. I tried each and every console option, no difference.

Also: In my experience poor "Anti Virus" software can slow-down the start-up process significantly! It's quite possible that you just have to wait a little longer...

(In my personal experience Avira Antivir is pretty fast, Microsoft Security Essentials is slower but still okay and NOD32 is slow like hell)

I do not have any of the usual resident AV scanners installed, they slow down my system too much. I use ThreatFire, and just to make sure that it is not to blame, I uninstalled it completely. No difference, though...


So far the only other time that a program window just refuses to appear on my system is the Windows version of Devede. It uses the Python GTK library, and it just won't run on my machine. But according to their forum I am not the only one. Maybe the Qt library does not like my system, too.

I should mention that my machine is quite ancient. My graphics card is an ATI Rage Pro Turbo AGP 2x, DX9 is installed, and according to DXDiag everything works without problems.


Cheers
manolito

[LoRd_MuldeR]

It stops right after the disclaimer. The last words are "ABSOLUTELY NO WARRANTY". After this there is a blinking cursor, and that's it.

Strange :confused:

Best solution, of course, would be debugging LameXP on your system. But if you don't know how to do that, I could send you a "special" build with more debugging output.

Maybe we could locate the exact line where it stops responding...

I do not have any of the usual resident AV scanners installed, they slow down my system too much. I use ThreatFire, and just to make sure that it is not to blame, I uninstalled it completely. No difference, though...

Indeed I had some trouble with ThreatFire myself.

It injects its own DLL into the address space of any running process, which reproducible caused MSYS to crash for me :rolleyes:

I assume you did a clean reboot after uninstalling ThreatFire?

So far the only other time that a program window just refuses to appear on my system is the Windows version of Devede. It uses the Python GTK library, and it just won't run on my machine. But according to their forum I am not the only one. Maybe the Qt library does not like my system, too.

Well, GTK+ and Qt both are cross-platform GUI frameworks. But that's it. They are two completely separate projects.

So your problems with Qt- and GTK+-based programs are most likely unrelated. However did you try other Qt-based software on your machine?

For example SMPlayer or Avidemux 2.5?

Also: Did you make a clean "format + re-install" of your system recently? This sometimes works wonders with "unexplainable" Windows bugs ;)

I should mention that my machine is quite ancient. My graphics card is an ATI Rage Pro Turbo AGP 2x, DX9 is installed, and according to DXDiag everything works without problems.

Qt fully supports Windows XP and it doesn't need any special 3D hardware. There is some support for OpenGL in Qt, but I don't use that in LameXP.

After all, LameXP works fine even on my Windows 2000 machine, although Windows 2000 is not officially supported by Qt 4.7. It even works under Linux/Wine.

http://img651.imageshack.us/img651/8990/screenshotwine.th.png (http://img651.imageshack.us/img651/8990/screenshotwine.png)

[LoRd_MuldeR]

Build #298 fixes a bug in the CPU detection code that could lead to an infinite loop on some systems. Thanks to manolito for the report!

(Unfortunately people who are effected by this bug will have to update manually, because the application will stall before auto-update gets a chance to run)

[nitinpushpan]

A new build is now available via auto-update. This (hopefully) fixes the issue :)

Can you please test with and without having "write meta tags" enabled? Can you also test with "write meta tags" enabled and having some custom tags specified on the "meta data" tab?

:thanks:

Sorry for the late reply. It works fine now with and without "write meta tags" enabled and with custom tabs specified. I'm using the v4.00 Beta-4, Build 300 [2011-02-09].

I'd like to make 2 suggestions also.

It would be nice if the entire tags from the source file got copied to the encoded file (Like the album art, album artist, composer, etc.).
I would like to Normalize the files to the peak volume of 0 db please. I'm not sure why you have restricted it to -0.50 db.

:thanks:

[LoRd_MuldeR]

Sorry for the late reply. It works fine now with and without "write meta tags" enabled and with custom tabs specified. I'm using the v4.00 Beta-4, Build 300 [2011-02-09].

Good to know :)

I'd like to make 2 suggestions also.

It would be nice if the entire tags from the source file got copied to the encoded file (Like the album art, album artist, composer, etc.).
I would like to Normalize the files to the peak volume of 0 db please. I'm not sure why you have restricted it to -0.50 db.


1. I can only copy (re-embed) tags that (a) MediaInfo retrieves from the original input file and (b) the individual encoder (e.g. LAME) can embed. It seems LAME can embed "album art" (jpeg/png/gif file, 128KB max), but I don't know of an easy way to extract the "art" from the original input. Moreover I never understood why people want to have JPEG/PNG's stored in their audio files, especially when it's the very same picture stored redundantly in all files of the album. Why not simply put the cover image as a separate JPEG/PNG file into the album folder once? I guess this is some kind of useless "iPod" gimmick...

2. Normalization is restricted to -0.5 db in order to protect against clipping. I think pushing the normalization up to the maximum amplitude isn't a good idea.

[nitinpushpan]

I totally agree with you on the iPod gimmick part. Unfortunately this gimmick is now followed by most of the companies. Honestly I really never care for the album art before but now it really bugs me out when I see a stupid headphone symbol or an empty square in my pmp. I usually don't add the entire album to my pmp so I add album art to each of the files. Its like they have enforced something cool which we really never cared for in the first place.

And about Normalization, by definition, applies a constant gain to the selected part or the entire track without exceeding 0.0 dBFS, or 100% (0 dB). For example in Audacity, it analyses the track for the peak amplitude and then applies the normalization filter ensuring that this peak amplitude does not cross 0 dB, hence no clipping.

[mariush]

Mulder, images should be embedded in an ID3v2 tag, so you should be able to read and write them relatively easily: http://www.id3.org/Developer_Information The link has plenty of information and I think there's even a GPL library that reads and writes id3v2 tags easily so you don't have to reinvent the wheel.

[LoRd_MuldeR]

And about Normalization, by definition, applies a constant gain to the selected part or the entire track without exceeding 0.0 dBFS, or 100% (0 dB). For example in Audacity, it analyses the track for the peak amplitude and then applies the normalization filter ensuring that this peak amplitude does not cross 0 dB, hence no clipping.

"If you’re planning to put normalized audio on CD, you might want to normalize the waveforms to no more than 96% as some audio compact disc players have problems accurately reproducing bits that have been processed to 100% (maximum) amplitude." – Cool Edit Pro (predecessor of Adobe Audition) manual

"Specifically, normalization applies a constant amount of gain to the selected region of the recording to bring the highest peak to a target level, usually to -1.0, or to -6.0 dB, in order to allow for addition of two channels without exceeding 0.0 dBFS, or 100% (0 dB)" – http://en.wikipedia.org/wiki/Audio_normalization


Mulder, images should be embedded in an ID3v2 tag, so you should be able to read and write them relatively easily: http://www.id3.org/Developer_Information The link has plenty of information and I think there's even a GPL library that reads and writes id3v2 tags easily so you don't have to reinvent the wheel.

Well, they are embedded in an ID3v2 Tag for MP3 files. The problem is that I have to support various input formats (MP3 is only one of them) as well as several encoders. So I would need to find a method that can detect/extract the "album art" from all supported input formats (or at least from those, that potentially contain "album art" of some kind). Moreover the "album art" would have to be extracted in a format that can be accepted for embedding by all supported encoders. Implementing a separate path for each "input format + encoder" combination won't be possible to accomplish with reasonable effort...

[johnsonlam]

Great! Thanks!
Glad to know a lot of improvements in the new version!

[LoRd_MuldeR]

RC-1 is out :)

This is the first release candidate. The final v4.00 release is scheduled for 2011-02-20.

If you have any showstoppers to report, please do now ;)

[mariush]

Stumbled on some bug when updating from 290 (or maybe 268...i'm not sure) something to 316, went check for updates, download, next and then the wma thing kept popping from behind and I couldn't close LameXP due to that, had to close it using Process Explorer (yeah task manager would have worked too).

See http://www.youtube.com/watch?v=_xKTDJs9TCk

note that window saying "Download failed" but I never selected to download and installed the wma codecs/tools.

[LoRd_MuldeR]

Stumbled on some bug when updating from 290 (or maybe 268...i'm not sure) something to 316, went check for updates, download, next and then the wma thing kept popping from behind and I couldn't close LameXP due to that, had to close it using Process Explorer (yeah task manager would have worked too).

See http://www.youtube.com/watch?v=_xKTDJs9TCk

note that window saying "Download failed" but I never selected to download and installed the wma codecs/tools.

Thanks for the report :)

I was able to reproduce the issue: It only happened when the auto-updater was launched by the update-reminder (i.e. not manually by the user) and a new update was available and the user chose to install the update and the WMA decoder component was not installed on the computer yet. I think I found the reason for this mess and it should be fixed by now in build #320. At least I hope so...

:thanks:

[manolito]

Hi MuldeR,

had some time today and gave Build #320 an extensive test run.
Results: Uneventful...:) Everything works as expected, absolutely stable.

Still I wish you had found the time to add AC3 output to LameXP. A complete rewrite would have been the perfect occasion. ;)


And I also found the time to explore a real bug which had already been present in v. 3.18. Remember my old post?

Quote:Originally Posted by manolito
And now my question which concerns AC3 to WAV conversion:
Whenever I convert a 2-channel AC3 to WAV with LameXP, this WAV file plays OK in MPC, WaveLab also has no problems with it. But when I try to use this file with MuxMan to author a DVD, MuxMan rejects the file.

Might be a WAVE_FORMAT_PCM -vs- WAVE_FORMAT_EXTENSIBLE issue. See for details:
http://www.microsoft.com/whdc/device...ultichaud.mspx

Anyway, I think mpucoder would be the man to ask about MuxMan issues...

No, it has nothing to do with the EXTENSIBLE format. I googled the specs, bytes 21 and 22 in the header would clearly indicate the extensible format, and this is not the case here. And it certainly is not a MuxMan issue. When MuxMan rejects a file then you can be 100% sure that this file has a compatibility problem. Period.

The error only happens when the source is AC3, when the source is MP3 everything is fine.


Scenario:

Source is a 2-channel AC3 file, 48 kHz sampling rate, 16 bit.
(Just to make sure that the error is not with the source, I used a couple of different source files created either with Aften or with AC3Enc)

My goal was to convert the AC3 to a Wave file with the same depth and sampling rate.

Load the AC3 into LameXP, select WAVE as output format, under advanced options leave sampling rate on "Automatic".
Resulting file is 48 kHz 16 bit WAVE, and it is rejected by MuxMan.

Second test: Same source file, the only difference is that under advanced I set the sampling rate to 48 kHz instead of automatic. Resulting file is also 48 kHz 16 bit Wave, but this time MuxMan accepts it. Open the two files in a hex editor and notice that they have very different headers.

These two files should be bit by bit identical. Why aren't they? The fact that MuxMan refuses to open the file which was created with the "automatic" sample rate setting is enough to tell me that the header of this file is corrupt.


I hope you can fix this without delaying the final release too much...:p

Cheers
manolito

[LoRd_MuldeR]

had some time today and gave Build #320 an extensive test run.
Results: Uneventful...:) Everything works as expected, absolutely stable.

Still I wish you had found the time to add AC3 output to LameXP. A complete rewrite would have been the perfect occasion. ;)

Maybe in the next release (I know that I said this before ^^).

I won't add new features right before the 4.00 release, so translators can finish up their work...


And I also found the time to explore a real bug which had already been present in v. 3.18. Remember my old post?

No, it has nothing to do with the EXTENSIBLE format. I googled the specs, bytes 21 and 22 in the header would clearly indicate the extensible format, and this is not the case here. And it certainly is not a MuxMan issue. When MuxMan rejects a file then you can be 100% sure that this file has a compatibility problem. Period.

How can you be so sure about it? I don't think MuxMan is the offical reference application for the Wave/RIFF format :p

As long as MuxMan is really the only application that complains, I would suspect the problem there...


The error only happens when the source is AC3, when the source is MP3 everything is fine.

Scenario:

Source is a 2-channel AC3 file, 48 kHz sampling rate, 16 bit.
(Just to make sure that the error is not with the source, I used a couple of different source files created either with Aften or with AC3Enc)

My goal was to convert the AC3 to a Wave file with the same depth and sampling rate.

Load the AC3 into LameXP, select WAVE as output format, under advanced options leave sampling rate on "Automatic".
Resulting file is 48 kHz 16 bit WAVE, and it is rejected by MuxMan.

So MuxMan obviously doesn't like the Wave/RIFF files created by ValibDec from AC3FilterTools (the AC3/DTS decoder used by LameXP).

But that doesn't necessarily mean that there is a problem with those files. It needs further investigation...


Second test: Same source file, the only difference is that under advanced I set the sampling rate to 48 kHz instead of automatic. Resulting file is also 48 kHz 16 bit Wave, but this time MuxMan accepts it. Open the two files in a hex editor and notice that they have very different headers.

Well, enabling the "Resampling" filter means that the decoded Wave file will be piped through SoX at least once, regardless of whether the new sample rate is identical to the input or not.

Obviously MuxMan likes the Wave/RIFF files written by SoX better.


These two files should be bit by bit identical. Why aren't they? The fact that MuxMan refuses to open the file which was created with the "automatic" sample rate setting is enough to tell me that the header of this file is corrupt.

I don't know what the difference between the Wave files written by ValibDec and those written by SoX is.

But just because one single application (i.e. MuxMan) refuses the files written by ValibDec, this doesn't necessarily mean that ValibDec's files are corrupt.

I will have a look, but can't grantee anything. In case it turns out ValibDec really writes invalid files, the AC3Filter developer would need to fix it...

[manolito]

How can you be so sure about it? I don't think MuxMan is the offical reference application for the Wave/RIFF format :p
Well, IMO you can look at MuxMan as the Ultimate unofficial DVD compliance checker.

Another strong indication that ValibDec is to blame is that if you open and resave these problematic files in a wave editor (I tried WaveLab, Nero Wave Editor and Audacity), MuxMan has no problems with the resaved files.


Cheers
manolito

[LoRd_MuldeR]

Well, IMO you can look at MuxMan as the Ultimate unofficial DVD compliance checker.

That doesn't matter. Wave files can't be DVD compliant, or not DVD complaint. That's because there's no such thing as a Wave file on a Video-DVD ;)

Whether the DVD authoring software accepts a specific Wave/RIFF file or not is a complete different question. And it has nothing to do with "DVD compliance".

It's the actual PCM audio data - may it be stored in a Wave container or in some other container - that can be DVD compliant (or not) in this case.


Another strong indication that ValibDec is to blame is that if you open and resave these problematic files in a wave editor (I tried WaveLab, Nero Wave Editor and Audacity), MuxMan has no problems with the resaved files.

That's not a proof that anything with the Wave files written by the ValibDec tool is wrong. Tough it doesn't indicate the opposite either.

I will try to have a look. Please give me a moment...

[LoRd_MuldeR]

manolito,

I can reproduce your issue. MuxMan rejects the Wave file written by ValibDec, but piping the file through SoX once makes it accept the file.

Unfortunately MuxMan doesn't give any information on WHY it did reject the file. Or do I miss something ???

Anyway, while it is obvious that the files are not bit-identical, I have so far been unable to find a reason that would justify accepting the one file, but rejecting the other.

All the analysis tools I tried seem to indicate that format of the files is identical:
http://pastie.org/private/n6uyrwqo3nqgihsjidyoa

Moreover I tried various applications (Audacity, CoolEdit Pro, Winamp, Foobar2000, MPlayer, VLC Player) and not a single one complained about the file written by ValibDec.

Last but not least encoding to FLAC from both Wave files individually results in two 100% bit-identical FLAC files. So the content is identical!

Consequently there currently is NO indication that there is anything wrong with the file. I will assume that this is a problem of MuxMan, unless more info is provided...

[Taurus]

@manolito
@LoRd_MuldeR

mano, I can feel the pain your in:p
Some time ago I tried to import wave files into Wavelab (famous wav editor).
They were rejected with some kind of stupid error message.
Loaded in any mediaplayer or other wav editors they were doing right.
So I fired up a hex editor to see the differences between Wavelabs angels and beasts.
There were definitly different header informations and rewriting the header
of the non working file solved the import failure in Wavelab.
Dont ask me how I solved it, it happened a long time ago in the past.
I changed my whole workflow since then.
Cant even remember the program or binary which wrote the wav's....

[LoRd_MuldeR]

Again: You can't compare the Wave files byte-by-byte (e.g. in a Hex-Editor) and then conclude that one of the files is "broken", just because the files are different at some point.

Actually there may be various reasons why the files are different and still both files can be perfectly valid. The one and only thing that matters: Is the file "valid" with respect to the RIFF/Wave specifications?

If the file is valid with respect to the specifications, then the reading-application must accept it. And if it doesn't, then it's the reading-application (not the writing-application) that must be fixed.

Only if it turns out that the file is "invalid" with respect the the specifications, then the writing-application is to blame...

I just downloaded a Demo version of Wave Lab 5 and finally got it to work on my Windows XP VM. And it turns out that Wave Lab opens the Wave file written by ValibDec flawlessly

[manolito]

I posted the issue to the MuxMan thread:
http://forum.doom9.org/showthread.php?p=1479439#post1479439

Let's see if mpucoder comes up with something....


Cheers
manolito

[lethedoom]

I have been using the 3.18 on my Windows intel core i5 cpu 650@3.2ghz pc and find it runs 8 threads simultaneously when encoding flac files to mp3. I tried the 4.0 build 324 today and it only ran 4 threads simultaneously and was obviously slower. When you release a final 4,0 stable version will it be similarly restricted to 4 threads ?

[SeeMoreDigital]

I posted the issue to the MuxMan thread:
http://forum.doom9.org/showthread.php?p=1479439#post1479439

Let's see if mpucoder comes up with something....In the meantime, you can always run your 2Ch PCM in .WAV files through WaveWizard ;)

[Taurus]

Again: You can't compare the Wave files byte-by-byte (e.g. in a Hex-Editor) and then conclude that one of the files is "broken", just because the files are different at some point.

Actually there may be various reasons why the files are different and still both files can be perfectly valid. The one and only thing that matters: Is the file "valid" with respect to the RIFF/Wave specifications?

If the file is valid with respect to the specifications, then the reading-application must accept it. And if it doesn't, then it's the reading-application (not the writing-application) that must be fixed.

Only if it turns out that the file is "invalid" with respect the the specifications, then the writing-application is to blame...

I just downloaded a Demo version of Wave Lab 5 and finally got it to work on my Windows XP VM. And it turns out that Wave Lab opens the Wave file written by ValibDec flawlessly
Sorry, if my post was a bit misleading.
I didn't assume that your program is writing wrong headers or content in wav files.
Wavelab 3.0 and 5.0 are opening the files made by your program just fine.
It was an older program (dont remember which one) which modified the header so wavelab could not read it.
Wavelab is the defacto standard for wav editing.
Just wanted to point it out that maybe the information in the header is bringing muxman to its knees.

[LoRd_MuldeR]

I have been using the 3.18 on my Windows intel core i5 cpu 650@3.2ghz pc and find it runs 8 threads simultaneously when encoding flac files to mp3. I tried the 4.0 build 324 today and it only ran 4 threads simultaneously and was obviously slower. When you release a final 4,0 stable version will it be similarly restricted to 4 threads ?

The number of parallel instances is limited, because running too many instances in parallel could easily result in HDD trashing and thus would actually slow down the process.

With Hexacore processors and Hyperthreading, PC's can have 12 or more (logical) cores nowadays. So I think we definitely need a limit here. Though four was chosen a bit arbitrarily.

[LoRd_MuldeR]

LameXP v4.00 Final has been released :)

Changes between v3.18 and v4.00:
* Complete re-write of LameXP in the C++ programming language
* Switched IDE from Delphi 7.0 to Visual Studio 2008 + Qt Framework v4.7.1 (GNU Toolchain not yet)
* Added cross-plattfrom support - only Windows and Wine for now, native Linux version planned
* Added full Unicode support for file names, meta tags and translations (no more Codepage headaches!)
* Added support for Qt Linguist tool, which makes creating/updating translations much easier
* Added support for multiple user interface styles, including "Plastique" and "Cleanlooks" themes
* Added support for user-defined encoder parameters (please use with care!)
* Added support for a true "portable" mode, which will store the configuration in the program folder
* Added resampling filter for all encoders, based on SoX
* Added simple tone adjustment filter, based on SoX
* Added an option to prepend the relative source file path to the output file path
* Updated all command-line tools to support Unicode file names, mostly required custom patches
* Updated LAME encoder to v3.99.0.11 (2011-02-11), compiled with ICL 11.1.065
* Updated OggEnc v2.87 using libvorbis v1.3.2 (2010-11-06), compiled with ICL 11.1 and MSVC 9.0
* Updated mpg123 decoder to v1.13.2 (2011-02-19), compiled with GCC 4.5.2
* Updated MediaInfo to v0.7.41 (2011-01-24), compiled with ICL 11.1.065
* Updated SoX to v14.3.1 (2010-04-11), compiled with MSVC 9.0
* Updated GnuPG to v1.4.11, compiled with GCC 4.5.2
* Updated language files (big "thank you" to all contributors !!!)
* Removed TAK support for now, as their CloseSource(!) tools don't support Unicode file names yet
* Removed Volumax tool, as we are using SoX for normalization from now on
* Countless minor fixes and improvements (hopefully not too many regressions ^^)

[SeeMoreDigital]

Many thanks... I've just downloaded it :)

[Taurus]

Many thanks... I've just downloaded it :):p

[tipsypenguin]

for some reason my antivirus is blocking tool_flac.exe as Suspicious.MH690.A every time I start LameXP

[LoRd_MuldeR]

for some reason my antivirus is blocking tool_flac.exe as Suspicious.MH690.A every time I start LameXP

Please check the file again at http://www.virustotal.com/, just to be sure, and then report the FALSE POSITIVE to the developer of the a/v software.

[lethedoom]

Thank you for this excellent free tool--you are my benefactor.

I see no reason to choose to use the slower 4.0 ( I did install and try the final version today ) when I have had no problems at all using the much faster 3.18--the same resources are used (100% cpu) and no hard drive problems ever occurred on my pc while using 3.18 running 8 simultaneous processes. As I am just a pedestrian computer user--neither expert nor a programmer--your arbitrary limit makes no sense to me in light of my usage experience.

[LoRd_MuldeR]

I see no reason to choose to use the slower 4.0 ( I did install and try the final version today ) when I have had no problems at all using the much faster 3.18--the same resources are used (100% cpu) and no hard drive problems ever occurred on my pc while using 3.18 running 8 simultaneous processes. As I am just a pedestrian computer user--neither expert nor a programmer--your arbitrary limit makes no sense to me in light of my usage experience.

I do not have a machine with more than 4 cores available for testing. And I doubt there currently are many users that do ;)

While I still doubt that running zillions of instances in parallel is a very good idea, I can add an option to configure the maximum number of instances in one of the future versions...

[manolito]

Latest findings about these funny Wave files created by ValibDec:

I just downloaded a Demo version of Wave Lab 5 and finally got it to work on my Windows XP VM. And it turns out that Wave Lab opens the Wave file written by ValibDec flawlessly
I never said otherwise. See my previous posts:
And now my question which concerns AC3 to WAV conversion:
Whenever I convert a 2-channel AC3 to WAV with LameXP, this WAV file plays OK in MPC, WaveLab also has no problems with it. But when I try to use this file with MuxMan to author a DVD, MuxMan rejects the file.
Another strong indication that ValibDec is to blame is that if you open and resave these problematic files in a wave editor (I tried WaveLab, Nero Wave Editor and Audacity), MuxMan has no problems with the resaved files.


In the meantime I found that two other audio converters I frequently use also reject these Wave files:

BeLight 0.2.2.0 (this is the latest version) by Kurtnoise simply refuses to load the file without any error message.

HeadAC3he 0.24 a13 by Dark Avenger also does not accept these files. But it displays the following error message: "Could not find fmt chunk!"


I also found an old app called StripWav which can strip extra information from a Wave file header and convert the header to the "canonical" format. This app determines: "Extra chunks: JUNK". Needless to say that the stripped file does work with MuxMan, BeLight and HeadAC3he.


My conclusion: Even if these files created by ValibDec may not be technically illegal, they certainly have a very unusual header leading to an incompatibility with a couple of other applications.


Cheers
manolito

[LoRd_MuldeR]

HeadAC3he 0.24 a13 by Dark Avenger also does not accept these files. But it displays the following error message: "Could not find fmt chunk!"

I also found an old app called StripWav which can strip extra information from a Wave file header and convert the header to the "canonical" format. This app determines: "Extra chunks: JUNK".

Well, I can confirm that the Wave file written by ValibDec contains a 'JUNK' chunk before the 'fmt' chunk. The file that has been piped through SoX (and is accepted by MuxMan) does not ;)

However this is not "unusual" at all: RIFF files often contain 'JUNK' chunks for padding. And, by definition of the RIFF format, a reading application must ignore/skip all the 'JUNK' chunks that it encounters!

Some applications might not implement a real RIFF parser and instead expect the 'fmt' chunk ("Wave header") to be located at a hard-coded position; may it be for simplicity, laziness or nescience.

But it is obvious that such applications are prone to fail on certain valid RIFF/Wave files. Consequently I think we really can't/shouldn't blame the writing application here...

[Taurus]

I also found an old app called StripWav which can strip extra information from a Wave file header and convert the header to the "canonical" format. This app determines: "Extra chunks: JUNK". Needless to say that the stripped file does work with MuxMan, BeLight and HeadAC3he.


Thank you for this suggestion, something for my audio toolbox...:p

[lethedoom]

I do not have a machine with more than 4 cores available for testing. And I doubt there currently are many users that do ;)

While I still doubt that running zillions of instances in parallel is a very good idea, I can add an option to configure the maximum number of instances in one of the future versions...

I will be grateful when you do that. When any version of LameXP is running and using up the available cpu capacity on my pc the cpu core temperatures rise. The slower 4.0 iteration of LameXP exposes the cpu cores and mainboard to the elevated temperature for a longer time which I surmise is undesirable in regard to maximizing their useful lifetimes. My pc is only dual core, but it also creates two virtual cores and each of the four cores runs two processes totalling eight concurrently using 3.18. That is what I would want 4.0 to do as well.

[mariush]

lethedoom you don't have to worry about that... both the motherboard and the cpu are designed to work at elevated temperatures for a long time, it really won't make a difference to their lives whether the cpu warms up the components or not. In fact it's better to keep the cpu at a higher yet steady temperature rather than just oscillate between cold and warmer cycles.

But it's all statistical anyway, the "life" of a cpu will drop due to temperature cycles from a few million hours to a few million hours - a few thousand - the difference is so small your cpu would be antique before it dies.

ps. The majority of components sensitive to heat on a motheboard (capacitors) are rated 85-105 C - so in order for a motherboard to fail, the temperature inside your computer case would have to be around 60-70C for days (capacitors get "older" faster as temperature is closer to their highest rating) in order to weaken these components. At the normal 30-40C temperature inside the case, these last for at least 5-10 years. By that time, you'll probably change several computers.

[LoRd_MuldeR]

I will be grateful when you do that. When any version of LameXP is running and using up the available cpu capacity on my pc the cpu core temperatures rise. The slower 4.0 iteration of LameXP exposes the cpu cores and mainboard to the elevated temperature for a longer time which I surmise is undesirable in regard to maximizing their useful lifetimes.

Now that is nonsense, really ;)

I've got my Intel Q6600 for more than four years now. And this machine is running like 8-12 hours every single day. I also use this machine for video encoding, so often the CPU's is running with 100% load on all four cores for several hours! That all is with the crappy "boxed" cooler. And, as you can see, I'm still online. So the machine has not exploded yet.

Moreover, running more instances in parallel in order to increase the CPU load would produce even more heat. So with your argumentation this would be the exact opposite of what you want...

My pc is only dual core, but it also creates two virtual cores and each of the four cores runs two processes totalling eight concurrently using 3.18. That is what I would want 4.0 to do as well.

That makes even less sense. If you really have a Dual Core processor (two physical cores), then even with Hyperthering enabled you have at most four (logical) cores available.

On such a machine running four instances in parallel is sufficient to fully utilize the CPU. Running even more instances than (logical) cores in parallel is pointless if not counterproductive.