View Full Version : LameXP v4.21 Final · Build #2382 (2023-12-29)
LoRd_MuldeR
5th September 2020, 21:07
LameXP v4.19 Beta-2
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2020-09-05/LameXP-BETA.2020-09-05.Release-Static.Build-2278.exe/download
Changes between v4.18 and v4.19 [unreleased]
* Updated Vorbis encoder to OggEnc v2.88 (2020-07-07), using libvorbis v1.3.7 with aoTuV beta-6.03
* Updated Monkey's Audio binary to v5.54 (2020-08-24), compiled with ICL 19.1 and MSVC 15.9
* Updated mpg123 decoder to v1.26.3 (2020-07-16), compiled with GCC 10.1.0
* Updated MediaInfo to v20.08 (2020-08-11), compiled with ICL 19.1 and MSVC 15.9
* Updated cURL to v7.72.0 (2020-08-19), with libcurl v7.72.0 and OpenSSL v1.1.1g
* Added command-line switch --no-splash, which can be used to hide the "splash" screen at startup
tormento
10th September 2020, 10:05
LameXP v4.19 Beta-2
Couple of days the service is unavailable on downloading.
Strange enough, only one mirror has the download file.
Can you please provide a mirror? Binary expired here :scared:
manolito
10th September 2020, 11:08
SourceForge downloading can be a bit unreliable...
What always works here is to click on "Problems Downloading?" and then choose the "Direct Link". Just checked for the latest Beta-2, no problems.
LoRd_MuldeR
10th September 2020, 15:04
Couple of days the service is unavailable on downloading.
Strange enough, only one mirror has the download file.
Can you please provide a mirror? Binary expired here :scared:
Just checked, and all of the 16 update mirrors seem to be up and synchronized, so you should always be able to get the latest version via "auto-update" function:
https://pastebin.com/6vhtLuZi
As far as problems with SourceForge.net downloads are concerned, there is not much I can do about this, but I just downloaded the latest version from SourceForge.net without any problem.
LoRd_MuldeR
21st September 2020, 21:25
LameXP v4.19 Beta-3
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2020-09-21/LameXP-BETA.2020-09-21.Release-Static.Build-2280.exe/download
Changes between v4.18 and v4.19 [unreleased]
* Updated LAME encoder to v3.100.1-SVN (2020-08-25), compiled with ICL 19.1 and MSVC 15.9
* Updated Vorbis encoder to OggEnc v2.88 (2020-07-07), using libvorbis v1.3.7 with aoTuV beta-6.03
* Updated Monkey's Audio binary to v5.54 (2020-08-24), compiled with ICL 19.1 and MSVC 15.9
* Updated mpg123 decoder to v1.26.3 (2020-07-16), compiled with GCC 10.1.0
* Updated MediaInfo to v20.08 (2020-08-11), compiled with ICL 19.1 and MSVC 15.9
* Updated cURL to v7.72.0 (2020-08-19), with libcurl v7.72.0 and OpenSSL v1.1.1g
* Added command-line switch --no-splash, which can be used to hide the "splash" screen at startupLAME v3.100.1 Release
This is a point release that includes NO changes to the encoding libraries.
This release replaces the previous mpglib decoding library with the libmpg123 decoding library.
MrVideo
16th October 2020, 21:23
I notice while starting the program on my XP-32 box, it warns that dwnapi.dll is missing. Doing a little bit of research, I find out that its use starts with Vista. OK, but the strange part is that versions for XP-32 can be found and downloaded.
Is dwmapi really needed and what is it used for with regards to LameXP? I'm guessing that it isn't really important, since the program runs just fine without it.
LoRd_MuldeR
16th October 2020, 22:58
Some Windows API functions are only available in newer Windows versions. If we linked these functions statically, then the executable would no longer be able to run on "old" Windows versions.
The workaround is to import these "optional" functions dynamically, at runtime, via LoadLibrary() and GetProcAddress(). This way, we can use the new API functions where available, but still continue without them otherwise.
Specifically, the DWM (Desktop Window Manager) (https://docs.microsoft.com/en-us/windows/win32/dwm/dwm-overview) is only available in Windows Vista an later. LameXP uses DwmEnableBlurBehindWindow() from Dwmapi.dll to enable fancy "Aero" effects on support OS versions.
https://i.imgur.com/fhguMGT.png
MrVideo
17th October 2020, 22:16
Thanks for the update. Certainly doesn't bother me that blur effects are missing.
MrVideo
22nd October 2020, 01:50
Slight problem... the beta has expired. I know, it keeps working. That is why it is slight.
Another slight problem... when trying to check for a new version, the beta says that my internet connection is broken. It isn't.
LoRd_MuldeR
7th November 2020, 00:09
Another slight problem... when trying to check for a new version, the beta says that my internet connection is broken. It isn't.
Not quite sure. Nothing about the update check should have changed recently :confused:
Can you can press F11 in the update window to show the log?
MrVideo
8th November 2020, 01:41
Here is the result:
Checking your Internet connection...
Connecting to host: www.ebay.com
ERROR: Terminated with unknown code -1073741515
Connecting to host: www.gnu.org
ERROR: Terminated with unknown code -1073741515
Connecting to host: bandcamp.com
ERROR: Terminated with unknown code -1073741515
Connecting to host: neocities.org
ERROR: Terminated with unknown code -1073741515
Connecting to host: www.avidemux.org
ERROR: Terminated with unknown code -1073741515
[...]
Connecting to host: support.proboards.com
ERROR: Terminated with unknown code -1073741515
Connecting to host: www.oxford.gov.uk
ERROR: Terminated with unknown code -1073741515
Connecting to host: www.jd.com
ERROR: Terminated with unknown code -1073741515
Connecting to host: marknelson.us
ERROR: Terminated with unknown code -1073741515
Connecting to host: www.libav.org
ERROR: Terminated with unknown code -1073741515
Connectivity test has failed: Internet connection appears to be broken!
Just a subset of the list. All sites exit with the some code. I have no clue has to how you are trying to connected to these locations. A simple ping of 8.8.8.8 would be a great test.
nevcairiel
8th November 2020, 01:52
-1073741515 is C0000135, which means "DLL not found". Some component involved in the connection process is not present.
LoRd_MuldeR
8th November 2020, 13:49
Here is the result:
Checking your Internet connection...
Connecting to host: www.gnu.org
ERROR: Terminated with unknown code -1073741515-1073741515 is C0000135, which means "DLL not found". Some component involved in the connection process is not present.
Well, it would indicate that cURL process failed to start, apprently because of a missing DLL.
If I remember correctly, you are one of those diehard Windows XP users. Not that we should care at this point, but for me the cURL binary that ships with LameXP works fine on my Windows XP (with SP-3) VM:
https://i.imgur.com/Ln27iKyl.jpg (https://i.imgur.com/Ln27iKy.jpg)
You could try opening the "lxp_curl.exe" form the LameXP "temp" directory with Dependency Walker (https://www.dependencywalker.com/) and see if it reveals anything...
danlock
5th December 2020, 21:47
Something I've intended to mention for quite a while... (It seems to be cosmetic only (NOT? SEE EDIT!), but it is confusing nonetheless.)
When I transcode one or more files to (an) Opus file(s), regardless of the Quality / Bitrate setting on the Compression tab, if I set a different bitrate in the OpusEnc text entry box in the Custom Encoder Parameters portion of the Advanced Options tab), the resulting file's ENCODER_OPTIONS: tag contains an extra artifact from the Compression tab.
In this example, the Compression tab was set to ≈ 144 kbps and my custom parameter was --bitrate 150, which resulted in the following ENCODER_OPTIONS tag:
ENCODER_OPTIONS : --vbr --comp 10 --framesize 20 --bitrate 144 --bitrate 150
The resulting file is the same as if the setting from the Compression tab were not present; the file is identical to one encoded with --bitrate 150. Either the second --bitrate option supersedes the first one on the command line, the setting from the tab is being inserted into the tag prior to the custom setting, or both.
I guess it's NOT cosmetic only (Edit #2: my mistake... it is only cosmetic, as LoRd_MuldeR reminded me (below)):
I just re-encoded the same file with a higher bitrate on the Compression tab (≈160) and got a larger file (tag says ENCODER_OPTIONS : --vbr --comp 10 --framesize 20 --bitrate 160 --bitrate 150), which remained larger/160kbps when I changed to 12kbps and re-encoded (custom still set to 150, tag says ENCODER_OPTIONS : --vbr --comp 10 --framesize 20 --bitrate 12 --bitrate 150) , but removing the custom option completely gave me a tiny file with an overall (VBR/quality) bit rate of 12.5 kbps. The tag ends with --bitrate 12 as it should.
Over the years since the Compression tab's --bitrate=??? text has been visible in the ENCODER_OPTIONS tag prior to the custom value, I have noticed no other strange tagging issues when I've had settings on the "ordinary" tabs that differ from any custom options I have set. I haven't tested exhaustively.
I'm using the latest beta, but I've noticed the tagging issue for many, many months and versions.
-------------
I was in a hurry at the end when I posted this yesterday. I neglected to thank you for your help and response, LoRd_MuldeR. I'll insert it now (Sunday 06.December 2020) and in this message to avoid creating another message at the bottom of the thread. Thank you! :) ...and I was right the first time: it is only cosmetic. Thanks for pointing that out, too!
LoRd_MuldeR
6th December 2020, 03:56
Well, it is not under our control what exactly OpusEnc stores in the "ENCODER_OPTIONS" meta tag. That's an OpusEnc thing.
Anyways, it would appear that OpusEnc simply stores the "raw" (full) command-line, not just the effective encoder options. This explains why you will see "--bitrate" twice, iff you add "--bitrate" to the "Custom Encoder Parameters": LameXP already generates the "--bitrate" option for you, based on the selected bitrate, on the "Compression" tab. Consequently, if you add that option again, as a custom parameter, you'll end up with two times "--bitrate" in the command-line.
Furthermore, the general convention for conflicting command-line options is that the last one takes precedence. And that is exactly what OpusEnc seems to follow here ;)
LoRd_MuldeR
26th January 2021, 21:44
LameXP v4.19 RC-2
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2021-01-21/LameXP-RC2.2021-01-21.Release-Static.Build-2288.exe/download
Changes between v4.18 and v4.19 [unreleased]
* Updated LAME encoder to v3.100.1-SVN (2020-08-25), compiled with ICL 19.1 and MSVC 15.9
* Updated Vorbis encoder to OggEnc v2.88 (2020-07-07), using libvorbis v1.3.7 with aoTuV beta-6.03
* Updated Monkey's Audio binary to v5.54 (2020-08-24), compiled with ICL 19.1 and MSVC 15.9
* Updated mpg123 decoder to v1.26.3 (2020-07-16), compiled with GCC 10.1.0
* Updated MediaInfo to v20.08 (2020-08-11), compiled with ICL 19.1 and MSVC 15.9
* Updated cURL to v7.72.0 (2020-08-19), with libcurl v7.72.0 and OpenSSL v1.1.1g
* Added Bulgarian (български) translation, thanks to Симеон Илиянов Цветков <sicvetkov@uni-sofia.bg>
* Added command-line switch --no-splash, which can be used to hide the "splash" screen at startupLAME v3.100.1 Release
This is a point release that includes NO changes to the encoding libraries.
This release replaces the previous mpglib decoding library with the libmpg123 decoding library.
MrVideo
13th February 2021, 06:33
Sorry for the delay in responding. I got sidetracked.Well, it would indicate that cURL process failed to start, apprently because of a missing DLL.
I had to search the C: drive in order to find lxp_xurl. When I manually run it, it povides me with some help options. But, there was no failure.
If I remember correctly, you are one of those diehard Windows XP users. Not that we should care at this point, but for me the cURL binary that ships with LameXP works fine on my Windows XP (with SP-3) VM:
It is true, but I have moved some stuff over to Win7-64. LameXP is run from my XP box for logistical reasons.
You could try opening the "lxp_curl.exe" form the LameXP "temp" directory with Dependency Walker (https://www.dependencywalker.com/) and see if it reveals anything...
I have no idea what I am looking for in its output. But, it didn't complain about no DLLs not being found.
As a test, I did: lxp_curl -I --url http://forum.doom9.org and all went well. It displayed the http header.
Why not just ping 8.8.8.8? That IP isn't going away any time soon.
At this point, I don't think that curl is the issue.
Used the above 2288 build and still not able to determine if the internet is working.
MrVideo
13th February 2021, 07:31
I just noticed that when extracting flac tracks from a flac file, the directory that is created always has a " (2)" added to the name, even though it is the only directory there.
Oh wait, I see why it did it. If the flac file is named: Album.flac, it tries to create a working directory called: Album.flac. Obviously that is a conflict. The directory that contains the files is called: Album. So, why not make the working directory: Album. Then there won't be a conflict.
LoRd_MuldeR
14th February 2021, 18:24
I had to search the C: drive in order to find lxp_xurl. When I manually run it, it povides me with some help options. But, there was no failure.
Just go to the %TMP% directory. LameXP will create a sub-folder with a random name here on startup. The lxp_curl.exe you are looking for will be in there.
I have no idea what I am looking for in its output. But, it didn't complain about no DLLs not being found.
Watch out for a missing DLL file, or for a missing entry point in one of the required DLLs. For me all looks good on my Windows XP machine though:
https://imgur.com/a/7SyOy5j
(Note: Warning about delay-loaded DLLs can be ignored, because delay-loading is commonly used for optional dependencies)
As a test, I did: lxp_curl -I --url http://forum.doom9.org and all went well. It displayed the http header.
Then I don't understand what was the problem before :confused:
In your earlier post you said that cURL failed to run with error code -1073741515, aka 0xC0000135, aka STATUS_DLL_NOT_FOUND:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55
So that would have indicated that the cURL process could not be created because of a missing DLL.
If, however, you can start cURL from the command-line without problem, and if you are 100% sure that you were testing the same "lxp_curl.exe" file, then a missing DLL apparently is not the problem.
Why not just ping 8.8.8.8? That IP isn't going away any time soon.
Ping is a whole different thing than HTTP. While HTTP is based on TCP, the "ping" command is implemented via ICMP (https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol). Note that ICMP is neither based on TCP nor UDP, but is a "layer 3" protocol of its own.
Generally, a working "ping" does not guarantee that a HTTP/TCP connection will work too. At the same time, if a sever doesn't respond to "ping", it could still respond to HTTP/TCP. Many web-servers block ICMP for security reasons.
So, it is much more meaningful to test an actual HTTP/TCP connection than only "ping'ing" the server.
Furthermore, trying to connect to an IP address instead of a host name wouldn't test DNS resolution at all! So, we have to connect to an actual host name, in order to see whether DNS resolution is working properly.
Last but not least, testing just a single host name (server) would be unreliable, because it would introduce a single point of failure (https://en.wikipedia.org/wiki/Single_point_of_failure).
That's why we have a list of many "known" host names (160 at this time), and we consider the Internet connection to be "working" as soon as at least 5 out of those could be reached successfully.
I just noticed that when extracting flac tracks from a flac file, the directory that is created always has a " (2)" added to the name, even though it is the only directory there.
Oh wait, I see why it did it. If the flac file is named: Album.flac, it tries to create a working directory called: Album.flac. Obviously that is a conflict. The directory that contains the files is called: Album. So, why not make the working directory: Album. Then there won't be a conflict.
I assume you are talking about CUE sheet import here ;)
In fact, the default (suggested) name of the output folder is based on the file name of the .cue file that you are importing, not on the name of any of the Wave, FLAC or whatever file(s) that are referenced in the .cue file.
The suggested output folder name should contain a "…(n)" suffix, if and only if a file or directory of the name without that suffix already exists.
Is it possible that your .cue file was called something like "album.flac.cue" and therefore the suggested output folder name would be "album.flac", but a file named "album.flac" already existed?
MrVideo
14th February 2021, 21:19
Just go to the %TMP% directory. LameXP will create a sub-folder with a random name here on startup. The lxp_curl.exe you are looking for will be in there.
I use the cygwin terminal and it knows nothing about %TMP%. I just did a search of the program on te C: drive to find it.
An important piece of info was missing from your first response. I enbolded the text. You didn't tell me that. What I found on my system was created in June of 2020. It works.
Watch out for a missing DLL file, or for a missing entry point in one of the required DLLs. For me all looks good on my Windows XP machine though:
https://imgur.com/a/7SyOy5j
Yours looks a little different than mine.
In your earlier post you said that cURL failed to run with error code -1073741515, aka 0xC0000135, aka STATUS_DLL_NOT_FOUND:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55
So that would have indicated that the cURL process could not be created because of a missing DLL.
If, however, you can start cURL from the command-line without problem, and if you are 100% sure that you were testing the same "lxp_curl.exe" file, then a missing DLL apparently is not the problem.
Based on the new information about lxp_curl.exe, I first started lamexp and then looked for the program. I then found the "new" version and it indeed fails. The walker indicates that normaliz.dll is missing, which indeed it is. Was this DLL ever shipped with WinXP, or ever added with a patch? I'm at SP3. I found a site to get it, but I need to know the info about the one that you are running (they have several versions). The info line from the walker program will do.
Ping is a whole different thing than HTTP. While HTTP is based on TCP, the "ping" command is implemented via ICMP (https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol). Note that ICMP is neither based on TCP nor UDP, but is a "layer 3" protocol of its own.
'Tis very true.
Generally, a working "ping" does not guarantee that a HTTP/TCP connection will work too. At the same time, if a sever doesn't respond to "ping", it could still respond to HTTP/TCP. Many web-servers block ICMP for security reasons.
True, but google doesn't. I use it to see if my internet connection is alive or dead. If it doesn't work, nothing will.
Furthermore, trying to connect to an IP address instead of a host name wouldn't test DNS resolution at all! So, we have to connect to an actual host name, in order to see whether DNS resolution is working properly.
While that is true, the user would have discovered a DNS issue via other means, i.e., just by trying to go to any website via their browser. Odds are that a user would have found an issue with their LAN, or internet connection, long before running lamexp.
Last but not least, testing just a single host name (server) would be unreliable, because it would introduce a single point of failure (https://en.wikipedia.org/wiki/Single_point_of_failure).
That's why we have a list of many "known" host names (160 at this time), and we consider the Internet connection to be "working" as soon as at least 5 out of those could be reached successfully.
IMHO, doing this test is overkill, because of the very reason I mentioned above. Just go to your site to look for the update and if it doesn't work, report back to the user. At that point the user can troubleshoot their LAN/internet.
In fact, the default (suggested) name of the output folder is based on the file name of the .cue file that you are importing, not on the name of any of the Wave, FLAC or whatever file(s) that are referenced in the .cue file.
[quote]Is it possible that your .cue file was called something like "album.flac.cue" and therefore the suggested output folder name would be "album.flac", but a file named "album.flac" already existed?
In this case, that is indeed true. That is because there was an album.flac.cue and album.wave.cue file. Why there is a wave cue file is beyond me, size there are no wave files.
Suggestion... if this situation arises, how about adding a pop-up asking the user to enter a new directory name? That is because I end up having to go back and manually rename the directories. Easier to do it up front.
LoRd_MuldeR
15th February 2021, 00:52
Based on the new information about lxp_curl.exe, I first started lamexp and then looked for the program. I then found the "new" version and it indeed fails. The walker indicates that normaliz.dll is missing, which indeed it is. Was this DLL ever shipped with WinXP, or ever added with a patch? I'm at SP3. I found a site to get it, but I need to know the info about the one that you are running (they have several versions). The info line from the walker program will do.
I don't know. And because Windows XP went "end of life" so long ago, it is hard to find any information. On my Windows XP (SP-3) system it just worked ;)
The Microsoft site about the IdnToAscii() function, which is the only function cURL imports from "normaliz.dll", says:
Windows XP, Windows Server 2003:
The required header file and DLL are part of the Microsoft Internationalized Domain Name (IDN) Mitigation APIs, which are no longer available for download.
Apparently there used to be a redistributable installer, specifically for Windows XP. So you can try with this archived copy that I was able to dig up:
idndl.x86.exe (https://sourceforge.net/projects/lamexp/files/Miscellaneous/Redistributables/idndl.x86.exe/download)
(Vista and later apparently provide "normaliz.dll" out-of-the-box)
In this case, that is indeed true. That is because there was an album.flac.cue and album.wave.cue file. Why there is a wave cue file is beyond me, size there are no wave files.
Suggestion... if this situation arises, how about adding a pop-up asking the user to enter a new directory name? That is because I end up having to go back and manually rename the directories. Easier to do it up front.
I don't see why that would be needed. After all, we are talking about the suggested (default) name of the output directory.
If you don't like the default, you can always choose a different output directory of your liking – in the CUE Sheet import dialog – before you start the import/splitting process.
Hence, there should be no need to rename anything afterwards...
While that is true, the user would have discovered a DNS issue via other means, i.e., just by trying to go to any website via their browser. Odds are that a user would have found an issue with their LAN, or internet connection, long before running lamexp.
Well, this is not about what the user might be able to figure out. It is about how the application reliably detectes whether we have a "working" Internet connection or not.
Just go to your site to look for the update and if it doesn't work, report back to the user. At that point the user can troubleshoot their LAN/internet.
That's the point. If we weren't able to fetch the update info from our update mirror, we don't know whether it is because our update mirror is down, or because of a more general problem with the user's Internet connection.
Sure, we could simply throw a typical meaningless "Uh oh: Something went wrong!" error message and let the user figure out the specifics. But I think showing a somewhat more helpful error message is nice ;)
Furthermore, since this is already implemented, I don't see a reason to drop a better, already working solution in favor of an inferior one.
Most important: Dropping the Internet connection test would not solve your cURL issues at all, because a working cURL would still be required for the actual download of the update information. You wouldn't gain anything.
danlock
15th February 2021, 02:46
> I use the cygwin terminal and it knows nothing about %TMP%.
> I just did a search of the program on te C: drive to find it.
I think the applicable Windows environment variable is %temp% (which redirects to Windows' temporary directory)
... good luck :)
MrVideo
15th February 2021, 03:24
> I use the cygwin terminal and it knows nothing about %TMP%.
> I just did a search of the program on te C: drive to find it.
I think the applicable Windows environment variable is %temp% (which redirects to Windows' temporary directory)
Cygwin doesn't know it either.
MrVideo
15th February 2021, 03:31
I don't know. And because Windows XP went "end of life" so long ago, it is hard to find any information. On my Windows XP (SP-3) system it just worked ;)
Somehow you managed to get it on your system.:D
The Microsoft site about the IdnToAscii() function, which is the only function cURL imports from "normaliz.dll", says:
Apparently there used to be a redistributable installer, specifically for Windows XP. So you can try with this archived copy that I was able to dig up:
idndl.x86.exe (https://sourceforge.net/projects/lamexp/files/Miscellaneous/Redistributables/idndl.x86.exe/download)
That fixed it. Sometime after the June 2020 version of cURL you were using, the program got changed and started using normaliz.dll. You never stumbled on the issue because you already had that DLL on your system. Leave it to me to find that issue.
Most important: Dropping the Internet connection test would not solve your cURL issues at all, because a working cURL would still be required for the actual download of the update information. You wouldn't gain anything.
Well, that certainly makes the point moot.
Now we know what to do if this were to happen to anyone else. :D
Thanks for helping me find the issue.
BTW: I removed the other cURL directory from last year, so I won't get fooled again.
MrVideo
15th February 2021, 03:49
I don't see why that would be needed. After all, we are talking about the suggested (default) name of the output directory.
If you don't like the default, you can always choose a different output directory of your liking – in the CUE Sheet import dialog – before you start the import/splitting process.
Hence, there should be no need to rename anything afterwards...
Unfortunately, I do want the results placed in the source directory. Oh well.
LoRd_MuldeR
15th February 2021, 21:03
Somehow you managed to get it on your system.:D
It is included with IE7 or later, and probably many other applications. Actually, I was able to extract the required "idndl.x86.exe" redistributable from an old IE7 for Windows XP setup package.
Since, after a fresh install, I always update my system to the latest version with WSUS Offline Update (https://www.wsusoffline.net/), including the latest supported version of IE, that's probably how I got it.
That fixed it. Sometime after the June 2020 version of cURL you were using, the program got changed and started using normaliz.dll. You never stumbled on the issue because you already had that DLL on your system. Leave it to me to find that issue.
Okay. So I will include the "idndl.x86.exe" redistributable in the LameXP installer for now. Just to be sure.
Unfortunately, I do want the results placed in the source directory. Oh well.
No idea :confused:
After you have opened the CUE file to be imported but before you hit "Import Cue Sheet" simply click the "Browse" button (in the "Output directory" groupbox) and then choose whatever output directory you like. That's it.
MrVideo
17th February 2021, 18:33
It is included with IE7 or later, and probably many other applications. Actually, I was able to extract the required "idndl.x86.exe" redistributable from an old IE7 for Windows XP setup package.
Since, after a fresh install, I always update my system to the latest version with WSUS Offline Update (https://www.wsusoffline.net/), including the latest supported version of IE, that's probably how I got it.
I never updated IE7, as I do not use IE for any web browsing. All of my browsing is done on my Linux server using Opera and Vivaldi.
Okay. So I will include the "idndl.x86.exe" redistributable in the LameXP installer for now. Just to be sure.
Sounds like a great idea.
LoRd_MuldeR
18th February 2021, 02:00
I never updated IE7, as I do not use IE for any web browsing. All of my browsing is done on my Linux server using Opera and Vivaldi.
Keep in mind that many applications use embedded IE frames ;)
LoRd_MuldeR
18th February 2021, 23:11
LameXP v4.19 RC-3
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2021-02-18/LameXP-RC3.2021-02-18.Release-Static.Build-2294.exe/download
Changes between v4.18 and v4.19 [unreleased]
* Updated LAME encoder to v3.100.1-SVN (2020-08-25), compiled with ICL 19.1 and MSVC 15.9
* Updated Vorbis encoder to OggEnc v2.88 (2020-07-07), using libvorbis v1.3.7 with aoTuV beta-6.03
* Updated Monkey's Audio binary to v6.12 (2021-02-15), compiled with ICL 19.2 and MSVC 15.9
* Updated mpg123 decoder to v1.26.4 (2020-12-24), compiled with GCC 10.2.0
* Updated MediaInfo to v20.09 (2020-10-09), compiled with ICL 2021.1 and MSVC 15.9
* Updated cURL to v7.75.0 (2021-02-03), with libcurl v7.75.0 and OpenSSL v1.1.1i
* Added Bulgarian (български) translation, thanks to Симеон Илиянов Цветков <sicvetkov@uni-sofia.bg>
* Added command-line switch --no-splash, which can be used to hide the "splash" screen at startup
* Added a workaround for missing normaliz.dll to the installer (Windows XP only)
MrVideo
18th February 2021, 23:37
Keep in mind that many applications use embedded IE frames ;)
True. The only one that I know of that works just fine is VideoReDo. If there are others, there has never been a complaint (error). I guess I've been lucky.
manolito
3rd April 2021, 16:17
Getting THIS again:
https://forum.doom9.org/showthread.php?p=1892386#post1892386
All I can do is repeat my request from this older post. I totally understand if you do not want your users to use alpha, beta or RC versions forever, but for stable versions this nagging is totally annoying and unnecessary.
Please...
Getting THIS again:
https://forum.doom9.org/showthread.php?p=1892386#post1892386
All I can do is repeat my request from this older post. I totally understand if you do not want your users to use alpha, beta or RC versions forever, but for stable versions this nagging is totally annoying and unnecessary.
Please...
Have to say I completely agree with this and made an account just to post this. I LOVE LameXP, but being bombarded to check for an upgrade where there isn't one is just silly, and the music that it plays when skipping the upgrade check is entirely unnecessary and doesn't mute when sounds are otherwise muted. I get "this program hasn't been updated in a year" notices constantly.
Atak_Snajpera
22nd May 2021, 08:35
https://www.nirsoft.net/utils/run_as_date.html
https://www.nirsoft.net/utils/run_as_date.html
That seems like it would be a great workaround and I appreciate it, but I'm not having any luck with it. Still getting the "this version is over a year old" prompt. Thank you though!
LoRd_MuldeR
24th May 2021, 22:44
Have to say I completely agree with this and made an account just to post this. I LOVE LameXP, but being bombarded to check for an upgrade where there isn't one is just silly, and the music that it plays when skipping the upgrade check is entirely unnecessary and doesn't mute when sounds are otherwise muted. I get "this program hasn't been updated in a year" notices constantly.
Sorry for late replay. This has already been addressed for the upcoming release.
Until a new "stable" version is released, which will be very soon (hopefully), you can grab the latest "test" version here:
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2021-05-22/
Regards.
jpsdr
25th May 2021, 19:17
I've installed and tested the moment it was out the stable 4.18. I rarely use LameXP, but i wanted to use it now, and it crashed (it didn't at the time i've installed it)...
I've uninstalled the 4.18 and installed the beta 4.19, and when i start it, Kaspersky said that there is a virus trojan in \TEMP\xxxxx\lxp_curl.exe.
LoRd_MuldeR
25th May 2021, 20:58
I've installed and tested the moment it was out the stable 4.18. I rarely use LameXP, but i wanted to use it now, and it crashed (it didn't at the time i've installed it)...
Well, without more detailed information, it is impossible to analyze the problem.
But I can tell you that I regularly test on different systems, ranging from latest Windows 10 running on my Core-i7 machine to Windows XP SP-3 running on a Pentium II machine, and haven't encountered any crashes.
BTW: If you use any so-called "anti-virus" software (other than Microsoft Defender) I suggest tying to disabling it and then try again. Buggy "anti-virus" software is a common cause of "mysterious" crashes.
I've uninstalled the 4.18 and installed the beta 4.19, and when i start it, Kaspersky said that there is a virus trojan in \TEMP\xxxxx\lxp_curl.exe.
https://www.heise.de/select/ct/2021/12/2031014511239568241
(Honestly, at this point, I won't explain, for the umpteenth time, what a "False Positive" is and who you have to report it to if you want it fixed)
K4sum1
11th June 2021, 09:45
The program opens, but gives me you must be running Windows 8 or higher, on Windows 8.
Can you remove the error entirely? If the program doesn't work on 7 or older, it just doesn't work, there doesn't need to be an artificial limit to what it runs on.
LoRd_MuldeR
11th June 2021, 11:37
The program opens, but gives me you must be running Windows 8 or higher, on Windows 8.
Can you remove the error entirely? If the program doesn't work on 7 or older, it just doesn't work, there doesn't need to be an artificial limit to what it runs on.
LameXP runs on Windows XP or later, up to and including Windows 10. I frequently verify that the program runs on my Windows XP, Windows 8.1 and Windows 10 machines. So I'm a bit confused here :confused:
What exact version of Windows you are running on and what exact version of LameXP you are trying to use?
Do you get that message from the LameXP "main" program or from the installer? A screenshot and some more details may be helpful. Can you run LameXP withe option '--console' and post the output?
K4sum1
12th June 2021, 09:27
LameXP runs on Windows XP or later, up to and including Windows 10. I frequently verify that the program runs on my Windows XP, Windows 8.1 and Windows 10 machines. So I'm a bit confused here :confused:
What exact version of Windows you are running on and what exact version of LameXP you are trying to use?
Do you get that message from the LameXP "main" program or from the installer? A screenshot and some more details may be helpful. Can you run LameXP withe option '--console' and post the output?
Sorry for the late response, I never got a notification email.
First screenshot is running normally, second screenshot is running with --console.
I kinda forgot a slight detail in the first post (since I had to wait 5 days before being able to post), but you can see it in the screenshots.
https://i.imgur.com/OO7uAJR.jpg
LoRd_MuldeR
12th June 2021, 13:46
Apparently you are using Windows 8.0, rather than Windows 8.1.
Window 8.0 has reached end of life in 2016, i.e. 5 years ago. Just update to Windows 8.1, which is essentially a Service Pack to Windows 8 and will be supported with security fixes by Microsoft until 2023.
At this point, I won't put any effort into testing or supporting Windows 8.0. The same applies to Windows 7 without SP-1, or Windows XP without SP-3.
(BTW: Please don't post ultra-large screenshots as attachments. It breaks the layout.)
Is There a Difference Between 8 and 8.1?
The answer is no, not really. Windows 8.1 is considered a service pack for Windows 8. This means Windows 8.1 is a part of Windows 8 and is included in that life cycle.
K4sum1
12th June 2021, 16:16
Apparently you are using Windows 8.0, rather than Windows 8.1.
Window 8.0 has reached end of life in 2016, i.e. 5 years ago. Just update to Windows 8.1, which is essentially a Service Pack to Windows 8 and will be supported with security fixes by Microsoft until 2023.
At this point, I won't put any effort into testing or supporting Windows 8.0. The same applies to Windows 7 without SP-1, or Windows XP without SP-3.
(BTW: Please don't post ultra-large screenshots as attachments. It breaks the layout.)
8.0 is better than 7 and 8.1 in various ways. It has a better DWM than 7, but without the activation system of 8.1. It can be easily modded to use the 7 explorer, while 8.1 has buggy start menu replacements. It has the better performance of 8.x without the telemetry updates of 8.1.
Also, about support, 8.0 Embedded gets support until 2023 as well, and 8.0 embedded updates work on regular 8.0.
LoRd_MuldeR
12th June 2021, 18:30
8.0 is better than 7 and 8.1 in various ways. It has a better DWM than 7, but without the activation system of 8.1. It can be easily modded to use the 7 explorer, while 8.1 has buggy start menu replacements. It has the better performance of 8.x without the telemetry updates of 8.1.
Also, about support, 8.0 Embedded gets support until 2023 as well, and 8.0 embedded updates work on regular 8.0.
Fell free to use whatever outdated and end-of-live operating system you like – it is you who has to live with the implications. I could go on to elaborate on how irresponsibly it is to use an end-of-live operating system. But I know that trying to "proselytize" notorious update refusers is a totally pointless endeavor. So, do what you want, but do not expect software developers to care about such super-exotic configuration. Windows 8.x generally is a lost cause, because it never gained much popularity and was quickly superseded by Windows 10. But Windows 8.0 without the Windows 8.1 service pack in particular is such a niche configuration that it's not worth bothering...
(BTW: You are the first person to ever try running this software on Windows 8.0, and report back. I think that says it all.)
shades
20th July 2021, 03:04
Dear LoRd_MuldeR
Latest nightly build LameXP-RC10.2021-06-27.Release-Static.Build-2316 seems to be broken on extraction of the file wvunpack.exe
Extracting file: wvunpack.x64-avx.exe -> wvunpack.exe
Failedto open file on first attempt, retrying...
QFile::remove: Empty or null file name
BaseTask exception error:
File 'lxp_curl.exe' could not be locked
GURU MEDITATION !!! <- (NICE! :-D AMIGA throwback?? lol )
LoRd_MuldeR
21st July 2021, 21:22
Dear LoRd_MuldeR
Latest nightly build LameXP-RC10.2021-06-27.Release-Static.Build-2316 seems to be broken on extraction of the file wvunpack.exe
Extracting file: wvunpack.x64-avx.exe -> wvunpack.exe
Failedto open file on first attempt, retrying...
QFile::remove: Empty or null file name
BaseTask exception error:
File 'lxp_curl.exe' could not be locked
GURU MEDITATION !!! <- (NICE! :-D AMIGA throwback?? lol )
Probably yet another case of "anti-virus" software gone nuts :rolleyes: :D
If you run any "anti-virus" software, please turn it off (or, even better: uninstall) in order to confirm that the root cause of the problem indeed is a buggy "anti-virus" software. Then report the problem to then vendor.
(Should the problem persist after any "anti-virus" software has been eradicated from the system, then I may investigate further)
shades
23rd July 2021, 00:18
Probably yet another case of "anti-virus" software gone nuts :rolleyes: :D
If you run any "anti-virus" software, please turn it off (or, even better: uninstall) in order to confirm that the root cause of the problem indeed is a buggy "anti-virus" software. Then report the problem to then vendor.
(Should the problem persist after any "anti-virus" software has been eradicated from the system, then I may investigate further)
You are of course, correct.
Rotten Windows 10 simple pattern matching crap.
I placed an exception for the entire folder for MuldeR and it's frikken fine as.
thanks for the time in answering. :)
danlock
12th August 2021, 19:01
(title)
Details: @LoRd_MuldeR Do you intend to support .webp album covers in LameXP (so they will be transferred from the source to the destination file(s) for supported formats/containers)? If so, do you have a timeline or a version number in mind when that will be implemented?
Thank you very much! :thanks:
LoRd_MuldeR
14th August 2021, 19:22
Details: @LoRd_MuldeR Do you intend to support .webp album covers in LameXP (so they will be transferred from the source to the destination file(s) for supported formats/containers)? If so, do you have a timeline or a version number in mind when that will be implemented?
Not currently planned. There are many open questions regarding WebP:
Does Qt support the WebP format? I think Qt 4, which LameXP is currently based on, does not. Probably current Qt 5 does. But then, porting LameXP to Qt 5 will be a big project for the future :o
Do the various audio formats that we support in LameXP support the WebP format in their meta data? For example, MP3 embeds meta data in the form of ID3 tags. And, to the best of my knowledge, ID3v2 "officially" only supports JPEG and PNG. Which is obvious, because at the time that ID3v2 was created WebP didn't even exist! And that's only MP3. What about all the other formats? :confused:
Even if some of the audio formats that we support actually do support WebP in their meta data, do the encoders that we use support WebP as input? What do we do with the other formats? :(
danlock
15th August 2021, 07:34
:goodpost:
Not currently planned.
Understandable. Thank you again!
There are many open questions regarding WebP:
Does Qt support the WebP format? I think Qt 4, which LameXP is currently based on, does not. Probably current Qt 5 does. But then, porting LameXP to Qt 5 will be a big project for the future :o
Do the various audio formats that we support in LameXP support the WebP format in their meta data? For example, MP3 embeds meta data in the form of ID3 tags. And, to the best of my knowledge, ID3v2 "officially" only supports JPEG and PNG. Which is obvious, because at the time that ID3v2 was created WebP didn't even exist! And that's only MP3. What about all the other formats? :confused:
Even if some of the audio formats that we support actually do support WebP in their meta data, do the encoders that we use support WebP as input? What do we do with the other formats? :(
Foobar 2000 can read .webp files in metadata (and add or remove .webp files as metadata). That was first implemented by pointing Fb2k to an external file, and later added internally (September 2000). That's a program which was coded from the ground up to support plugins and other features, though, and Peter can alter his code base or plugins to add/remove support for different things anytime. It's possible other players/encoders can read .webp metadata as well, but I can't think of any. I presumed any other relatively-decent player would discard the .webp image data as extraneous. A poorly-coded player, on the other hand, would see the "extra" data and crash or claim the file is bad, but (come to think of it) since metadata exists as a separate, resizable part of the file (whether as part of the audio file or in an external tag file), it probably just wouldn't be displayed.
As small as lossy .webp (and the next version, .webp2) files are compared to most other image formats with similar quality, it's a space savings to use .webp format in audio files (lossless .webp files obviously don't compress as much). For maximum compatibility and even more space, I should probably just use an external image in the directory and put only textual metadata in the files.
Support in QT seems to be the biggest hurdle. I had not considered that. Thanks for reminding me of LameXP's usage of QT! :)
Well, for the purposes of this forum and LameXP, the future is approaching at a fixed speed. End users like me will probably learn of support for any new formats whenever any porting to a newer version of QT occurs, since the tagging is typically handled by the external components for which LameXP provides the interface. And those decoder/encoder combinations that don't support .webp would output a file that doesn't contain the image, of course, like they already do.
Something will change when those included external decoders work for newer metadata or LameXP itself can copy metadata in (.webp/etc.) whatever formats are present in the file, in the future, whenever it happens.
Speaking of time, I've allowed far too much of it to march past me while I typed this message! (Muss los!)
LoRd_MuldeR
29th August 2021, 19:09
LameXP v4.19 has been released :)
https://github.com/lordmulder/LameXP/releases/latest
Changes between v4.18 and v4.19 [2021-08-29]:
* Updated LAME encoder to v3.100.1-SVN (2020-08-25), compiled with ICL 19.1 and MSVC 15.9
* Updated Vorbis encoder to OggEnc v2.88 (2020-07-07), using libvorbis v1.3.7 with aoTuV beta-6.03
* Updated Monkey's Audio binary to v6.29 (2021-05-25), compiled with ICL 19.2 and MSVC 15.9
* Updated mpg123 decoder to v1.26.4 (2020-12-24), compiled with GCC 10.2.0
* Updated MediaInfo to v21.03 (2021-03-26), compiled with ICL 2021.2 and MSVC 15.9
* Updated cURL to v7.77.0 (2021-05-26), with libcurl v7.77.0 and OpenSSL v1.1.1k
* Updated the Windows SDK version used for release builds (Visual Studio 2017) to 10.0.14393.0
* Added Bulgarian (български) translation, thanks to Симеон Илиянов Цветков <sicvetkov@uni-sofia.bg>
* Added command-line switch --no-splash, which can be used to hide the "splash" screen at startup
* Added a workaround for missing normaliz.dll to the installer (Windows XP only)
* GnuPG has been replaced by CodeSign (https://bitbucket.org/muldersoft/codesign/src/master/) verification tool for checking the auto-update signatures
* Updated language files (big thank-you to all contributors !!!)
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.