LameXP - Frequently Asked Questions (FAQ)


Table of contents:


What is LameXP ???

LameXP is a graphical user-interface for a number of audio encoders. It was developed to support a huge
number of input formats. File formats are detected reliably using MediaInfo. Compressed audio formats are
decoded to uncompressed Wave files using suitable CLI audio decoders. Furthermore LameXP allows batch
processing of multiple audio files. Multi-threading is implemented by processing several audio files
concurrently. All the third-party tools incorporated in LameXP are listed in the "About" dialog. The Nero AAC
encoder cannot be redistributed due to licensing issues; it is available as a free download from the public
Nero web-site. Note: LameXP does NOT use/need any "external" audio decoders. It neither requires nor supports
any ACM Codecs or DirectShow/DMO filters! And it will NOT install anything of that kind on your system.



What platforms does LameXP run on?

LameXP is currently being developed and tested on the following platforms:

The following platforms should work as well, but aren't tested extensively:

The following platforms are NOT supported any longer:


What output formats (encoders) does LameXP support?

Currently the following output formats are supported by LameXP:


What input formats (decoders) does LameXP support?

Currently the following input formats are supported by LameXP:


My anti-virus program raises an alarm when I try to download/install/launch LameXP. Why is that?

Occasionally your anti-virus program may mistakenly(!) detect "malware" (e.g. virus, trojan horse or worm) in
LameXP. This is called a "false positive" and the file is actually innocent/clean. It's an error in your
specific anti-virus software. So in case you encounter such problems, please use http://www.virustotal.com/,
http://www.virscan.org/ or a similar online-service to check the file in question with multiple(!) anti-virus
engines. Especially take care with scan results like "suspicious", "generic" or "packed", as such results are
NOT confirmed malware detections and in almost any case they can be ignored/discarded safely!

Apparently anti-virus programs tend to suspect installers or uninstallers created with NSIS. Furthermore some
anti-virus programs blindly suspect all "packed" executables of being malware. Obviously that is a stupid
generalization, so please ignore these nasty warnings! Last but not least: Always keep in mind that LameXP is
OpenSource software. If you don't trust the provided pre-compiled binaries, simply download the source codes,
search the code for "malicious" functions (you won't find any!) and then compile your own binary.

Conclusion:

Who created LameXP?

LameXP was written from the scratch by LoRd_MuldeR <MuldeR2@GMX.de>. However it has to be noted that LameXP
uses a number of third-party tools, which have been created by the individual authors. Moreover various
people have contributed LameXP translations. Please see the "About" dialog for details!



What license is LameXP released under?

LameXP is free software. You can redistribute it and/or modify it under the terms of the GNU General Public
License (GPL) as published by the Free Software Foundation; either version 2 of the License, or (at your
option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

The licenses for most software and other practical works are designed to take away your freedom to share and
change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share
and change all versions of a program - to make sure it remains free software for all its users.

Please see the GNU General Public License for more details!



Do I have to pay for LameXP? / How can I donate to the authors of LameXP?

LameXP is free software, so you may use it for free and for any purpose. Moreover the authors of LameXP
currently do NOT accept any donations. Therefore you should NOT pay or donate any money in order to obtain
LameXP! However it was brought to our attention that some dubious third-party web-sites offer "payed"
downloads of LameXP and/or include Adware into the LameXP download. We do NOT cooperate with any of these
sites. So if you pay for the LameXP download, the authors of LameXP will not get a single cent! Instead you
should save your money and download LameXP from the official mirrors (see below), which is 100% free.

If you want to support the development of LameXP, you can do so by contributing translations or code :-)



MP3, AAC or Vorbis - What is the best compressed audio format?

This question can NOT be answered in general. The best audio format is the format that works best for you!

Having said that, there are a few things to consider. First of all: All output formats supported by LameXP,
except for FLAC and PCM/Wave, use a lossy(!) kind of compression. That applies to MP3 and AAC as well as
Vorbis. Consequently with these formats a certain quality loss is unavoidable when re-encoding/converting, no
matter what. This is called "generation loss". Nonetheless all three formats (MP3, AAC and Vorbis) are able
to retain an EXCELLENT audio quality, given that the chosen bitrate (quality level) is sufficient/reasonable.

Secondly, the audio quality does not depend on the audio format and the chosen bitrate only. It also depends
greatly on the encoder software that is being used. LameXP uses the LAME MP3 encoder, probably the most
sophisticated MP3 encoder out there, the Nero AAC encoder, one of the best AAC encoders available, and the
aoTuV Vorbis encoder, an improved/tuned version of the reference Vorbis encoder. Consequently LameXP provides
you with state-of-the-art encoders, which ensures maximum encoding quality for ALL supported output formats.

Another thing to consider is hardware support, i.e. support on stand-alone and portable players. The MP3
format still has the best support on hardware players, but support for AAC/MP4 has become widespread too -
especially on portable devices. Hardware support for Vorbis is more limited, but growing. So if portability
is a priority, then MP3 is a good choice. However the MP3 format does NOT support multi-channel audio, which
means that you will have to use AAC or Vorbis for multi-channel files. Last but not least, if you prefer a
truly "open" and patent-free audio format, then Vorbis will be the format of your choice!

Another resource you might find interesting are Sebastian's Public Listening Tests:
(However be aware that some of the results from these listening tests are not up-to-date anymore)



What is the difference between the CBR, VBR and ABR rate control modes?

CBR means "constant bitrate" and, as the name implies, CBR mode allocates the bits at a constant rate. This
means that each part of the audio will get the same amount of bits, regardless of its content. Obviously this
will waste bits in parts of the audio that are easy to compress. At the same time the quality of parts of the
audio that are hard to compress will be degraded. Consequently using CBR mode is NOT a very good idea, unless
you really have to for some reason. However CBR mode has the advantage that the final size of the compressed
file is perfectly predictable. The resulting file size is defined simply as "duration × fixed bitrate".

VBR means "variable bitrate" and, in contrast to CBR mode, VBR mode allows the bitrate to vary/fluctuate.
Thus the VBR mode enables the encoder to adapt the bitrate with respect to the content of the audio. Parts of
the audio that are easy to compress will get a lower bitrate in order to safe bits. Parts of the audio that
are hard to compress will get a higher bitrate in order to avoid quality degradation. Or in other words: VBR
mode "moves" the bits to the locations where they are actually needed. Therefore the VBR mode achieves a much
better compression efficiency than the CBR mode, i.e. with VBR mode you can get a better quality at the same
file size, or the same quality at a smaller file size (compared to CBR mode). One disadvantage of the VBR
mode is, however, that the final size of the compressed file can NOT be predicted. The resulting file size is
defined as "duration × average bitrate", but the average bitrate can NOT be known beforehand. That's
because the average bitrate for a specific VBR quality level can vary greatly, depending solely on the
complexity of the individual audio. Nonetheless VBR mode generally should be the preferred encoding mode.

ABR means "average bitrate". You can think of ABR mode as a compromise between the CBR and VBR mode. With ABR
mode the bitrate is allowed to vary/fluctuate, similar to VBR mode. However the ABR mode doesn't work with a
predefined/fixed quality level, as VBR mode does. Instead in ABR mode the encoder will continuously re-adjust
the quality level in order to hit the target average(!) bitrate. You can also think of ABR mode as a mode
that pre-allocates the bits in a CBR-like fashion and then redistributes the bits within a local neighborhood
as needed. Thus the ABR mode combines advantages of CBR mode (predictability) and VBR mode (good quality).
The final size of the encoded file is still defined as "duration × average bitrate", but with ABR mode the
average bitrate *is* known beforehand. So if you need to hit a specific file size, ABR mode is the solution.

Hint: The Nero AAC encoder supports a variant of the ABR mode, the so-called "2-Pass" mode. That mode scans
through the entire file once (first pass) before the actual encoding is performed (second pass). This way the
encoder is able to distribute the bits over the entire file and still hit the desired target average bitrate.
It should be obvious that the advantages of the "2-Pass" mode come at the cost of increased encoding time.

Hint: A common mistake done by people comparing rate control modes is choosing a bitrate that is too high. Of
course only files of an identical (average) bitrate can be compared by quality. But if that bitrate is chosen
too high, you won't be able to draw any conclusions from the test. That's because at a certain bitrate even
the CBR mode will retain excellent quality. In that situation VBR mode or ABR mode can't give an even better
quality for obvious reasons. But drawing the conclusion that there is no difference between CBR mode and the
VBR/ABR modes would be very wrong! The differences will become significant when using a reasonable bitrate.
Another mistake is starting with a low-quality source file and concluding that all modes perform equally bad.

Summary of rate control modes:


How do I enable AAC/MP4/M4A output (encoding) in LameXP?

LameXP uses the Nero AAC Encoder for creating AAC/MP4/M4A files. The Nero AAC Encoder is available as a free
download. However the license doesn't allow redistribution! Therefore we can NOT ship the Nero encoder along
with LameXP. Instead you will have to obtain the Nero encoder as a separate download from the official "Nero
Digital" web-site. Currently you'll find the latest Nero AAC Encoder version at this location:

After you have downloaded the Nero AAC Encoder as a ZIP file, you must "install" the encoder binaries, so
LameXP can use them. Simply unzip the files 'neroAacEnc.exe', 'neroAacDec.exe' as well as 'neroAacTag.exe' to
the same directory where your LameXP executable ('LameXP.exe') is located. For unzipping the ZIP file you can
use any suitable archiver, such as WinRAR or 7-Zip. Once the required Nero encoder binaries are located in
the LameXP directory, the AAC encoding option should be "enabled" on the next startup of LameXP.



Is there a way to output ".m4a" or ".aac" files with LameXP?

LameXP uses the Nero AAC Encoder for AAC encoding. And the Nero encoder always puts the AAC streams into an
MP4 (MPEG-4 Part 14) container - in almost any case that is exactly what you want/need! The one and only
"correct" file extension for MP4 files is '.mp4'. However sometimes the "incorrect" file extension '.m4a' is
used to indicate "audio-only" MP4 files. Even worse: There are some buggy (hardware) players that will
recognize MP4 audio file only with the "incorrect" .m4a extension, but NOT with the "correct" .mp4 extension.
Of course LameXP will save your MP4 files with the "correct" .mp4 extension. But if you need your MP4 files
with an .m4a extension for some reason, you can simply rename(!) these files. This isn't more or less
"incorrect" than saving the files as .m4a directly. After all, an MP4 file remains an MP4 file.

Having said that, you should NOT rename any .mp4 or .m4a files to .aac, because these are MP4 files and NOT
"raw" AAC streams. The Nero AAC encoder has NO option to output "raw" AAC streams and usually you don't need
such streams. Still, if you want to extract the "raw" AAC stream from an MP4 file, you can use MP4Box.



How do I enable WMA input (decoding) in LameXP?

WMA input requires the WMA decoder component to be installed on your local computer. Usually LameXP will show
a warning on startup, if the WMA decoder component could not be found. In that case you can simply choose
"Download & Install" in order to install the WMA decoder component on your system. Alternatively you can
also install the WMA decoder component manually by choosing "Install WMA Decoder" from the "Tools" menu. In
any case you must restart LameXP after the WMA decoder component has been installed.

It has to be noted that the WMA decoder component relies on the Windows Media Format Runtime. All supported
versions of Microsoft Windows should have the Windows Media Format Runtime installed out of the box. However
Wine does not! In case you encounter problems with the WMA decoder component, try downloading and installing
the Windows Media Format 11 Runtime manually. This should also work under Linux/Wine.



How can I use LameXP as a "portable" application?

LameXP always is "portable", in the sense that the application works out of the box: LameXP does NOT require
any additional software, such as codecs, encoders, decoders or runtime libraries, and it will NOT install
anything of that kind on your local computer! All the third-party tools used by LameXP are already built-in.
There currently are two notable exceptions: The Nero AAC encoder and the WMA decoder cannot be redistributed
along with LameXP for legal reasons. Therefore these tools have to be obtained as separate downloads.

Having said that, LameXP stores its configuration file in the %LOCALAPPDATA% folder on the local computer.
That's because on a modern multi-user operating this is the only "correct" folder to store user-specific
configuration files. Also it's one of the few folders where an application is guaranteed to get write-access,
even when the application was launched by a "normal" (non-admin) user and did not request elevated rights.
Storing the configuration file in the "install" folder is antiquated and highly error-prone.

Still some users may want to store the configuration file in the same folder as the LameXP executable file,
e.g. when launching LameXP directly from their USB stick on different computers. For this purpose LameXP now
offers a "true" portable mode. You can enable that mode simply by renaming the LameXP executable file to
"LameXP-Portable.exe". But be aware: When running LameXP in the "portable" mode, the user(!) must ensure that
write-access is granted to the directory where the LameXP executable is located.



Is there a way to use custom tools (binaries) with LameXP instead of the "built-in" ones?

LameXP uses a number third-party tools. All of these tools are already "built-in" (with a few exceptions) and
thus it is NOT required to provide separate binaries. Usually it will NOT be necessary to replace any of
the "built-in" tools with a custom (user-provided) binary. If, however, you need to replace/update/downgrade
one of the binaries for a good reason, the recommended method is re-building LameXP from the sources. If you
don't know how to build LameXP from the sources, then you probably shouldn't be trying to replace the binary.

Having said that, there now is a more convenient method for using a custom tool version (binary) instead of
the "built-in" one. This method works WITHOUT re-building LameXP. However note that the following is intended
for testing and debugging purposes only! Also note that LameXP was specifically designed to work with the
"built-in" versions of the tools. It may not work properly or may not work at all with custom tool versions!

In order to replace a "built-in" binary, simply put the user-provided binary to the following location:
<install_folder>\tools\<build_number>\<tool_name>.exe
If, for example, you want to replace 'lame.exe' in Build #666 of LameXP, you would put it to the this path:
C:\Path to your LameXP install folder\tools\666\lame.exe
(It is intended that the '<build_number>' part of the path has to be adjusted with every update of LameXP)



The LameXP startup (splash screen) takes very long on my system. What can I do?

Starting up LameXP shouldn't take longer than approximately 10 seconds. However it was brought to our
attention that badly optimized anti-virus software can slow down the startup procedure a lot! On our test
system (Windows 7 running on an Intel Core2 Q6600 with 4 GB of RAM) starting up LameXP takes about 3 seconds
without an anti-virus software and about 6 seconds with the "real-time protection" of Microsoft Security
Essentials enabled. With other anti-virus software the startup was delayed up to 20 seconds and more!

So if you think that LameXP is starting up too slow on your system, you should temporarily(!) disable or
uninstall your current anti-virus program and try again. Usually it should be sufficient to disable only the
"real-time protection", "file system protection" or "guard" feature of your anti-virus software. If it turns
out that the startup is significantly(!) faster WITHOUT the anti-virus software, please report the problem to
the developer of the anti-virus software. And, if they don't fix the problem, switch to a better product!



Is there a way to hide/show the LameXP console ("DOS Box") window?

It is common for many people to run an alleged "DOS" program inside Windows, using a so-called "DOS Box".
Everything works fine. But when you try to run such a program in DOS, you get an ugly message "This program
cannot be run in DOS mode". What's wrong? Well, the affected program is NOT a "DOS" one. It is a Windows
Console program. "DOS" is NOT a synonym of Console. And "Windows" is NOT a synonym of GUI (Graphical User
Interface). Both, DOS and Windows programs, can be either Console or GUI. Actually Windows programs can be
Console *and* GUI at the same time, i.e. a Windows GUI program can have a Console attached.

LameXP is a GUI program for Windows. However it can have a "Debug" console attached. The purpose of this
console is providing users an insight into what's happening behind the scenes. While the console is mainly
intended for developers, it may be helpful for "regular" users too. Nonetheless you usually will NOT need the
console, unless something is going wrong. Therefore the LameXP console is disabled by default in all
"release" builds. You can enable the console by passing the "--console" command-line parameter, if required.
At the same time the console is enabled by default in all "beta" (pre-release) builds of LameXP. You can
still disable the console by passing the "--no-console" command-line parameter, if you don't like it.



Why does application 'xyz' not open the Wave files created by LameXP?

Some of the decoders used in LameXP will insert an additional 'JUNK' chunk into the Wave/RIFF file, right
before the 'fmt' chunk ("Wave header"). There are technical reasons why this 'JUNK' chunk (placeholder) might
be needed at the beginning of the file. The 'JUNK' type is a standard RIFF type and, by definition of the
RIFF file format specification, any reading application must ignore/skip all 'JUNK' chunks it may encounter!
Evidently most reading applications do so and thus will correctly open the Wave file. Unfortunately it was
brought to our attention that there are a few broken(!) applications, which reject Wave/RIFF files with an
additional 'JUNK' chunk in front of the 'fmt' chunk. It seems that these applications make false assumptions
and expect the 'fmt' chunk to be located at a fixed position, rather than parsing the RIFF structure.

While it is evident that applications, which reject the Wave/RIFF file because of the extra 'JUNK' chunk, are
broken with respect to the RIFF specification and should be fixed by the respective author, there is an easy
workaround: Re-saving the Wave/RIFF file with SoX creates a file that even the broken applications seem to
accept, as SoX apparently doesn't insert any 'JUNK' chunks (although it would be free to do so!) Re-saving
your Wave file with SoX does NOT change the actual content at all, as long as no additional filters are used.

You can use a command-line like this:
sox.exe "c:\some path\input.wav" "c:\some path\output.wav"


Why does LameXP run only 'n' parallel instances/threads on my computer?

By default LameXP will detect the number of CPU cores that are available on your system and run as many
encoder/decoder instances in parallel as CPU cores are available. This is done in order to maximize the CPU
usage on modern multi-core processors and thus speed up the overall encoding process. However be aware that
the number of instances that can run in parallel is also limited by the number of files you are converting.
Consequently the number of instances that will run in parallel is the minimum(!) of the number of CPU cores
and the number of files to convert. Moreover the number of parallel instances is currently bounded at four!

Limiting the maximum number of parallel instances to exactly four might seem somewhat arbitrary. But the more
instances are running in parallel, the more instances will be competing for the hard disk. At some point this
will result in "HDD trashing" and actually slow down the encoding process! The limit will prevent this
situation on computers with a lot of CPU cores. If, however, you want to use even more (or fewer) instances,
then you can use LameXP's option to manually overwrite the maximum number of parallel instances/threads.

Also be aware that LameXP only controls the number of instances that will run in parallel, but it does NOT
control how many threads an individual instance will create! Some encoders use "built-in" multi-threading and
thus a single encoder instance may create several threads - LameXP has no control over that.



How can I force LameXP to create ID3 version 2 (ID3v2) tags?

The LAME encoder automatically chooses the proper ID3 tag version. By default it will create a version 1 tag,
if possible. Only if the information cannot be embedded into a version 1 tag (ID3v1), e.g. because the string
is too long or the string contains Unicode characters, a version 2 tag (ID3v2) will be added. This behavior
is advisable, because devices that support ID3v2 tags should also be able to read ID3v1 tags - but this
doesn't apply the other way around! Moreover embedding an ID3v1 and an ID3v2 tag at the same time, although
the information would have fit into a single ID3v1 tag, means an unnecessary redundancy!

If, however, you need to enforce the creation of an ID3v2 tag for some reason, you can use the "--add-id3v2"
parameter for that purpose. Simply add the parameter to the "Custom Encoder Parameters" for LAME.

That's what the LAME help says about ID3 tags:
A version 2 tag will NOT be added unless one of the input fields
won't fit in a version 1 tag (e.g. the title string is longer than 30
characters), or the '--add-id3v2' or '--id3v2-only' options are used,
or output is redirected to stdout.


Why does LameXP use LAME v3.99 rather than v3.98?

LAME v3.99 contains the latest improvements and bugfixes of the LAME mp3 encoder, but it's less tested than
the older 3.98 release series. The most important reason why LAME v3.99 is used in LameXP v4.xx is because
LameXP v4.xx focuses on proper Unicode support, but LAME v3.98 did NOT support Unicode filenames or Unicode
meta tags (through the CLI front-end, on the Windows platform). However LAME v3.99 finally does!

So far we have not encountered any noteworthy problems with LAME v3.99. If, however, you encounter a problem
with LAME v3.99, please report your finding to the LAME development team. Do NOT submit any LAME-specific bug
reports to the LameXP developers, as we generally cannot analyze/fix problems specific to the LAME encoder.



Can LameXP be used to convert/extract tracks from an Audio CD?

LameXP can be used to convert audio files that have been extracted from an Audio CD, but it can NOT extract
or read the audio tracks from the Audio CD directly (yet). Consequently you will have to extract ("rip") the
audio tracks first, before you can convert them with LameXP. We recommend using the Exact Audio Copy software
for that purpose. When ripping tracks from an Audio CD you should always save the tracks as uncompressed Wave
files or as lossless FLAC files! This will avoid a quality loss during the extraction/ripping process.

Warning: The Windows operating system will show CDA files (such as "Track01.cda") on an Audio CD. These are
dummy/fake files! Actually an Audio CD does NOT contain a file system and thus there are NO files. There only
are audio tracks on an Audio CD. These audio tracks can be extracted as files (e.g. Wave Audio files) using a
ripping software and then the extracted files can be converted. At the same time any attempt to copy/convert
the '.cda' files directly is destined to fail (as the '.cda' files do NOT actually contain any audio data).



Why is the maximum normalization level limited to -0.5 dB?

When an analogue [audio] signal is converted to the digital domain, the signal is sampled at a fixed rate
(e.g. 44100 samples per second) and each "sample" value is stored with a fixed number of bits (e.g. 16 or 24
bits per sample). Consequently [uncompressed] digital audio is represented as a sequence of binary sample
values. The range of possible sample values is determined by the word size ("bits per sample"). For example
with a word size of 16 bit, the minimum value is −32768 and the maximum value is 32767 - assuming the values
are signed. The range of the sample values corresponds to the voltage range of the electrical input signal.
The maximum digital sample value (i.e. 32767 at 16-Bit) often is referred to as 0dBFS (0dB "full scale").

Performing a Normalization in the digital domain seems straightforward: We simply multiply all sample values
with the same factor. And we choose this factor in such a way that the highest sample value(s) in the track
will become exactly 0dBFS after the normalization has been performed. However one needs to be aware that when
playing back the digital audio track, it needs to be converted back to an analogue signal. The D/A converter
will convert each sample from its binary representation to the corresponding voltage. Then a "reconstruction"
filter will be applied in order to recover a continuous signal from these individual voltages. And for the
reconstructed analogue signal it is possible to have voltages that are higher than the highest digital sample
in the audio track! This is illustrated in the following image (samples are represented as tiny squares):



Consequently normalizing the sample values to 0dBFS is NOT a very good idea, as this may very well result in
a reconstructed analogue signal which exceeds(!) 0dBFS. And, as the analogue parts of the playback equipment
generally are NOT prepared for +0dBFS voltages, this may cause problems, such as annoying distortions!

The help document of a well-known audio editing software contains the following advice:
If you're planning to put normalized audio on CD, you might want to normalize the waveforms to
no more than 96% [-0.36 dB] as some audio compact disc players have problems accurately reproducing
bits that have been processed to 100% (maximum) amplitude [0dBFS].
For details please refer to the following article:


Why do I get the error 'Executable doesn't support Windows compatibility mode' on startup?

LameXP was designed to run on all supported platforms natively (except for Linux/Wine). If you see this error
message, that's probably because your system is configured to run LameXP in 'compatibility mode', i.e. your
system will pretend an older OS version than is actually running. In Windows Explorer you can disable(!) the
compatibility mode by right-clicking on the 'LameXP.exe' file, choosing 'Properties' from the context menu,
switching to the 'Compatibility' tab and un-checking the 'Run this program in compatibility mode' option.



Why do I get the error 'Executable requires Windows XP or later' on startup?
Why do I get the error 'The procedure entry point De/EncodePointer could not be located' on startup?
Why do I get the error 'LameXP.exe is not a valid Win32 application' on startup?

You are trying to run LameXP on a platform that is NOT supported, such as Windows 95, Windows 98, Windows
Millennium Edition, Windows NT 4.0 or Windows 2000. There is nothing you can do about that, except for
updating to a less antiquated OS. Running an outdated and unsupported OS is a severe security risk anyway!

LameXP won't run on the 'RTM' release of Windows XP (no service packs) either. Service Pack 2 or newer is
required! If needed, you can download Service Pack 3 for Windows XP as network installation or as ISO image.
Finally this error can also occur, if your system has been configured to run LameXP in compatibility mode.

Remark: Executables compiled with Microsoft Visual Studio 2010 won't run on Windows 2000 or older (details).



Why do I get the error 'A device attached to the system is not functioning' on startup?

This error message from the Windows operating system is somewhat misleading. It often appears together with
a second error message and it means that Windows was unable to load/execute the program file. There are
various reasons why this error might occur, but usually it indicates that you are trying to run LameXP or the
LameXP setup/update program on a platform that is NOT supported, such as Windows 95, Windows 98, Windows
Millennium Edition, Windows NT 4.0 or Windows 2000. There is nothing you can do about that, except for
updating to a less antiquated OS. Running an outdated and unsupported OS is a severe security risk anyway!

Remark: Executables compiled with Microsoft Visual Studio 2010 won't run on Windows 2000 or older (details).



How can I translate LameXP to my language or improve an existing translation?

Please see the guide for translators at:


Where can I download the latest version of LameXP?

The latest "official" release of LameXP can be found on the following mirrors:


Where can I submit bug reports or feature requests?

The preferred place to report bugs or request new features is the LameXP thread at Doom9's Forum:

Please do NOT send me E-Mail unless you really have to! I receive a LOT of E-Mail and your mail can get lost!



Where can I find the LameXP source code?

LameXP is developed using the Git revision control system. The LameXP Git repository is mirrored at:


What are the prerequisites to build LameXP from the sources?

LameXP is currently being developed using the following build environment:

Also note the following hints:

Instructions to build Qt as 'static' libraries:


eof