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

[LoRd_MuldeR]

LameXP v4.07 Beta-2

Changes between v4.06 and v4.07:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-1
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Added "Up One Level" button to the output folder tab
* Added Opus decoder option to output always at the native sample rate of 48.000 Hz
* Updated Qt runtime libraries to v4.8.4 (2012-11-29), compiled with MSVC 11.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-01-24)
* Fixed handling of certain characters when passing meta tags on the command-line

[Atak_Snajpera]

Lord_Mulder
I was always wondering why this thread (tool) is not in Audio section? Instead it sits lonely in development section like outcast

[SeeMoreDigital]

Originally Posted by Atak_Snajpera

Lord_Mulder
I was always wondering why this thread (tool) is not in Audio section? Instead it sits lonely in development section like outcast

Agreed...

[LoRd_MuldeR]

I think it could fit into both sub-forums. Originally I opened the thread under "Development", because it was a tool that I was developing myself and I didn't want to imply that this is a "finished" product. I would have put it under "Audio", if I had wanted to discuss about some third-party audio tool. But that wasn't the case. I'm not quite sure whether it should be moved to "Audio" nowadays. But I think moving the thread, after all the time, might confuse some people...

[SeeMoreDigital]

Originally Posted by LoRd_MuldeR

But I think moving the thread, after all the time, might confuse some people...

I would suppose that all the people who are really interested in LameXP will have subscribed to the thread... So moving it over to the audio section would make no difference to them

[LoRd_MuldeR]

LameXP v4.07 Beta-3

Changes between v4.06 and v4.07:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-1
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Added "Up One Level" button to the output folder tab
* Added Opus decoder option to output always at the native sample rate of 48.000 Hz
* Updated Qt runtime libraries to v4.8.4 (2012-11-29), compiled with MSVC 11.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-01-24)
* Updated GnuPG to v1.4.13, compiled with GCC 4.7.2
* Fixed handling of certain characters when passing meta tags on the command-line

[LoRd_MuldeR]

LameXP v4.07 Beta-4

Changes between v4.06 and v4.07:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-1
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Added "Up One Level" button to the output folder tab
* Added Opus decoder option to output always at the native sample rate of 48.000 Hz
* Updated Qt runtime libraries to v4.8.4 (2012-11-29), compiled with MSVC 11.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-02-09)
* Updated SoX to to v14.4.1 (2012-02-09), compiled with ICL 13.0 and MSVC 10.0
* Updated GnuPG to v1.4.13, compiled with GCC 4.7.2
* Updated language files (big thank-you to all contributors !!!)
* Fixed handling of certain characters when passing meta tags on the command-line

[LoRd_MuldeR]

LameXP v4.07 Beta-6
http://sourceforge.net/projects/lame...29/2013-02-12/

Changes between v4.06 and v4.07:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-1
* Minimum supported platform now is Windows XP with Service Pack 3 (download)
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Added "Up One Level" button to the output folder tab
* Added Opus decoder option to output always at the native sample rate of 48.000 Hz
* Updated Qt runtime libraries to v4.8.4 (2012-11-29), compiled with MSVC 11.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-02-09)
* Updated Valdec decoder to v1.4.0a (2013-02-11), based on latest AC3Filter Tools
* Updated SoX to to v14.4.1 (2012-02-09), compiled with ICL 13.0 and MSVC 10.0
* Updated GnuPG to v1.4.13, compiled with GCC 4.7.2
* Updated language files (big thank-you to all contributors !!!)
* Fixed handling of certain characters when passing meta tags on the command-line

[real.finder]

hi

Any idea about mka support in lamexp?

I use http://sourceforge.net/projects/aud-subsplitter

and the output is mka, for this I have to get it back to origin aac or mp3, etc...

To work with lamexp

thx

[LoRd_MuldeR]

The problem is that there can be any type of audio in a Matroska file. And all the decoders used by LameXP to decode the various audio formats do not support Matroska files as input.

We would need to demux the audio stream, e.g. via mkvextract (from MKVtoolnox), before decoding, but that currently doesn't fit into the design of LameXP...

[manolito]

I just found out that the latest Beta version refuses to start on my (ancient) machine:

The last line in the console window is "CPU_TYPE_X86_GEN".
The program exits with the message: "Unhandled exception handler invoked, application will exit".

My machine: CPU Intel Celeron Coppermine 1.1 Ghz, MMX and SSE (no SSE2), 576 MB RAM. WinXP Pro SP3, all current updates.


Aside from this, I discovered that the latest version of SOX now (kind of) supports large WAV files in the WAVE_FORMAT_EXTENSIBLE format. This is very useful for me because I now can convert large multichannel AAC files to multichannel AC3 with normalization. The following command sequence works: (source is a large (> 5GB) 6ch WAV file)

sox.exe --ignore-length -t wav test.wav -t wav normalized.wav gain -n -1
aften.exe -readtoeof 1 normalized.wav test.ac3

So I see no reason why LameXP shouldn't do this also. Version 4.06 final does not work, even if I use the latest SOX version and add the custom command "-readtoeof 1" to Aften. I had hoped that version 4.07 Beta 6 had corrected this, but unfortunately I could not test it...



Cheers
manolito

[LoRd_MuldeR]

Originally Posted by manolito

I just found out that the latest Beta version refuses to start on my (ancient) machine:

The last line in the console window is "CPU_TYPE_X86_GEN".
The program exits with the message: "Unhandled exception handler invoked, application will exit".

My machine: CPU Intel Celeron Coppermine 1.1 Ghz, MMX and SSE (no SSE2), 576 MB RAM. WinXP Pro SP3, all current updates.

That's interesting. Though I have no idea why that is

At that point, the application does nothing, but extract the binaries. It does not run any of them yet. And even if we assume that it extracts a "wrong" (unsupported) binary and eventually runs it, only the new process would crash - not the LameXP process itself. So it must be something in the extraction/initialization code...

I also tried to reproduce the behavior the behavior with:
LameXP.exe --force-cpu-no-sse --force-cpu-no-64bit

But works okay for me:

LameXP - Audio Encoder Front-End v4.07 Beta-6 (Build #1246)
Copyright (c) 2004-2013 LoRd_MuldeR <mulder2@gmx.de>. Some rights reserved.
Built on 2013-02-12 at 20:43:58 with MSVC 2012-U1 for Win-x86.

[...]

CPU flags overwritten by user-defined parameters. Take care!

   CPU vendor id  :  GenuineIntel (Intel: 1)
CPU brand string  :  Intel(R) Core(TM)2 Quad CPU           @ 2.40GHz
   CPU signature  :  Family: 6, Model: 15, Stepping: 7
CPU capabilities  :  MMX: 1, SSE: 0, SSE2: 0, SSE3: 0, SSSE3: 0, x64: 0
 Number of CPU's  :  4

[...]

Thread is doing something important... Done

Selected CPU is: CPU_TYPE_X86_GEN
Extracting file: aften.i386.exe -> aften.exe
Extracting file: gpgv.exe -> gpgv.exe
Extracting file: elevator.exe -> elevator.exe
Extracting file: dcaenc.exe -> dcaenc.exe
Extracting file: avs2wav.exe -> avs2wav.exe
Extracting file: flac.exe -> flac.exe
Extracting file: gpgv.gpg -> gpgv.gpg
Extracting file: faad.exe -> faad.exe
Extracting file: lame.i386.exe -> lame.exe
Extracting file: mac.exe -> mac.exe
Extracting file: mediainfo.i386.exe -> mediainfo.exe
Extracting file: mpcdec.exe -> mpcdec.exe
Extracting file: mpg123.exe -> mpg123.exe
Extracting file: oggdec.exe -> oggdec.exe
Extracting file: oggenc2.i386.exe -> oggenc2.exe
Extracting file: opusdec.exe -> opusdec.exe
Extracting file: opusenc.exe -> opusenc.exe
Extracting file: refalac.exe -> refalac.exe
Extracting file: shorten.exe -> shorten.exe
Extracting file: sox.exe -> sox.exe
Extracting file: speexdec.exe -> speexdec.exe
Extracting file: tta.exe -> tta.exe
Extracting file: valdec.exe -> valdec.exe
Extracting file: wget.exe -> wget.exe
Extracting file: wma2wav.exe -> wma2wav.exe
Extracting file: wupdate.exe -> wupdate.exe
Extracting file: wvunpack.exe -> wvunpack.exe
All extracted.

Can you please try to find the last build that still worked on your old machine?
http://sourceforge.net/projects/lame...%20%28BETA%29/

Originally Posted by manolito

Aside from this, I discovered that the latest version of SOX now (kind of) supports large WAV files in the WAVE_FORMAT_EXTENSIBLE format. This is very useful for me because I now can convert large multichannel AAC files to multichannel AC3 with normalization. The following command sequence works: (source is a large (> 5GB) 6ch WAV file)

sox.exe --ignore-length -t wav test.wav -t wav normalized.wav gain -n -1
aften.exe -readtoeof 1 normalized.wav test.ac3

So I see no reason why LameXP shouldn't do this also. Version 4.06 final does not work, even if I use the latest SOX version and add the custom command "-readtoeof 1" to Aften. I had hoped that version 4.07 Beta 6 had corrected this, but unfortunately I could not test it...

The problem is, we won't know when to pass "--ignore-length". Passing that always doesn't sound like a good idea...

[manolito]

OK, just tested almost evey 4.07 version starting with Alpha 4. No success, the last working version is 4.06 final. Every version after this shows the same behavior...

The problem is, we won't know when to pass "--ignore-length". Passing that always doesn't sound like a good idea...

Oh, I do think it is a good idea. From the SOX manual:

--ignore-length
Override an (incorrect) audio length given in an audio file’s header. If this option is given then
SoX will keep reading audio until it reaches the end of the input file.

Just like the Aften "-readtoeof 1" parameter which should always be present, I believe this SOX parameter won't do any harm, even in situations when it is not necessary. Requires some testing...


Cheers
manolito

[LoRd_MuldeR]

Originally Posted by manolito

OK, just tested almost evey 4.07 version starting with Alpha 4. No success, the last working version is 4.06 final. Every version after this shows the same behavior...

Hmm, that's strange. We still need to figure out the exact build number, so I have a chance to figure out what exactly changed.

Version 4.06 Final is build #1170. The next build I uploaded is #1197 (2012-11-24):
http://sourceforge.net/projects/lame...7.exe/download

Does that one already fail ???

Originally Posted by manolito

Oh, I do think it is a good idea. From the SOX manual:

Just like the Aften "-readtoeof 1" parameter which should always be present, I believe this SOX parameter won't do any harm, even in situations when it is not necessary. Requires some testing...

We really shouldn't force this behavior unless we absolutely need it, because:

• If SoX simply ignores the length, i.e. it continues to reads until it stumbles upon the end of the file, it obviously cannot report progress. That's because if you have read X samples of an "unknown" length, how many percent of the whole thing you have processed? You simply cannot know until you are at 100%. Consequently this would break progress reporting in LameXP, which is a bad thing.
• There may be perfectly legal RIFF files that have other (unspecified) data after the audio data in the first "data" chunk. The length info guarantees that we don't read beyond the first "data" chunk. If we blindly ignore the length info, we'll decode that "garbage" at the end of the file. I don't know how common such files are, but we are definitely trading one problem for another here. You could actually argue that WAV/RIFF files bigger than 4 GB are illegal by definition, while files that have additional data after the first "data" chunk definitely are allowed. By definition, all "unknown" chunks are simply ignored (skipped over). So there is a reason why they made it an option.

[manolito]

Version 4.06 Final is build #1170. The next build I uploaded is #1197 (2012-11-24):
http://sourceforge.net/projects/lame...7.exe/download

Does that one already fail ???

Yes it does. It just pops up the following message:
"Not a debug build. Please unload debugger and try again"
Needless to say that there is no debugger running on my machine.

We really shouldn't force this behavior unless we absolutely need it, because:
If SoX simply ignores the length, i.e. it continues to reads until it stumbles upon the end of the file, it obviously cannot report progress. That's because if you have read X samples of an "unknown" length, how many percent of the whole thing you have processed? You simply cannot know until you are at 100%. Consequently this would break progress reporting in LameXP, which is a bad thing.

I'd much rather do without progress reporting than with the current behavior which is simply annoying. When I try to convert such a file LameXP just does its thing for a long time (these are large files) without any warnings. It reports that it has successfully converted the file, but when I check the output I see that the file is truncated. This is unacceptable.


Cheers
manolito

[LoRd_MuldeR]

Originally Posted by manolito

Yes it does. It just pops up the following message:
"Not a debug build. Please unload debugger and try again"
Needless to say that there is no debugger running on my machine.

Now that's sounds like a completely different problem

So do you only get that issue with that specific build? Is it reproducible? And only your "old" machine or on other machines too?

Also: With which build that issue is gone and you start getting the crash you described earlier?

(BTW: I could also send you a DEBUG build of the latest version, so you might be able to figure out where exactly it crashes...)

[EDIT] The code that would complain about a debugger has not changed at all since 2012-03-26 [/EDIT]

Originally Posted by manolito

I'd much rather do without progress reporting than with the current behavior which is simply annoying. When I try to convert such a file LameXP just does its thing for a long time (these are large files) without any warnings. It reports that it has successfully converted the file, but when I check the output I see that the file is truncated. This is unacceptable.

Don't forget that you are trying to process an invalid/broken/out-of-specs Wave file. So truncation this is actually the "expected" behavior, regarding the file format specifications

I'm not totally against adding hacks to process such broken files more "gracefully", but only as long as it doesn't cause any bad side effects.

As explained before, always ignoring the length, not only brakes progress reporting (probably), but also could cause other valid files to decode garbage. So it's not really a good idea.

(Best heuristic I could think of in a few minutes is passing "--ignore-length" only for files whose size exceeds 4 GB)

[manolito]

Originally Posted by LoRd_MuldeR

Now that's sounds like a completely different problem

So do you only get that issue with that specific build? Is it reproducible? And only your "old" machine or on other machines too?

Also: With which build that issue is gone and you start getting the crash you described earlier?

(BTW: I could also send you a DEBUG build of the latest version, so you might be able to figure out where exactly it crashes...)

OK, those are the results of some heavy testing...

I tried the latest Beta on my Netbook Medion Akoya E1210 (the famous Aldi Netbook), and there were no problems whatsoever. The Atom CPU supports all SSE versions, memory had been upgraded to 2 GB.


On my desktop computer (Celeron Coppermine, only MMX and SSE, 576 MB RAM) all attempts to run the 4.07 versions of LameXP failed. I uninstalled all resident AntiVirus software and made sure that no A/V service was still running. I made the software run with 256 colors, I tried to run it in safe mode, nothing helped.

Version Alpha 4 from 2012-11-24 always gave me the debug build error, and all later versions up to Beta 6 issued the "Unhandled exception handler invoked..." message. And this behavior is reproduceable each and every time.

My conclusion is that XP support in Visual Studio 2012 Update-1 is limited. It's probably not worth your time to debug this.

Originally Posted by LoRd_MuldeR

(Best heuristic I could think of in a few minutes is passing "--ignore-length" only for files whose size exceeds 4 GB)

Yes, I could live with that...


Cheers
manolito

[LoRd_MuldeR]

Originally Posted by manolito

OK, those are the results of some heavy testing...

I tried the latest Beta on my Netbook Medion Akoya E1210 (the famous Aldi Netbook), and there were no problems whatsoever. The Atom CPU supports all SSE versions, memory had been upgraded to 2 GB.

On my desktop computer (Celeron Coppermine, only MMX and SSE, 576 MB RAM) all attempts to run the 4.07 versions of LameXP failed. I uninstalled all resident AntiVirus software and made sure that no A/V service was still running. I made the software run with 256 colors, I tried to run it in safe mode, nothing helped.

I think we need a Debug build at this point. Please stay tuned...

Originally Posted by manolito

Version Alpha 4 from 2012-11-24 always gave me the debug build error, and all later versions up to Beta 6 issued the "Unhandled exception handler invoked..." message. And this behavior is reproduceable each and every time.

I still don't see how this can happen only with specific builds. As said before, the code in question has not changed for ages...

Originally Posted by manolito

My conclusion is that XP support in Visual Studio 2012 Update-1 is limited. It's probably not worth your time to debug this.

It works fine on all my Windows XP systems. Also I explicitly compile the LameXP "main" program with "/arch:IA32" so it is guaranteed to run fine on systems without SSE/SSE2.

(The default has changed to "/arch:SSE2" in Visual Studio 2012, as has been the case with ICL for a long time)

[LoRd_MuldeR]

LameXP v4.07 Beta-7

Changes between v4.06 and v4.07:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-1
* Minimum supported platform now is Windows XP with Service Pack 3 (download)
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Added "Up One Level" button to the output folder tab
* Added Opus decoder option to output always at the native sample rate of 48.000 Hz
* Updated Qt runtime libraries to v4.8.4 (2012-11-29), compiled with MSVC 11.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-02-09)
* Updated Valdec decoder to v1.4.0a (2013-02-11), based on latest AC3Filter Tools
* Updated SoX to to v14.4.1 (2012-02-09), compiled with ICL 13.0 and MSVC 10.0
* Updated GnuPG to v1.4.13, compiled with GCC 4.7.2
* Updated language files (big thank-you to all contributors !!!)
* Fixed handling of certain characters when passing meta tags on the command-line
* Fixed Keccak library to not crash on systems without SSE/SSE2 support

[LoRd_MuldeR]

LameXP v4.07 Beta-9

Changes between v4.06 and v4.07:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-1
* Minimum supported platform now is Windows XP with Service Pack 3 (download)
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Added "Up One Level" button to the output folder tab
* Added Opus decoder option to output always at the native sample rate of 48.000 Hz
* Updated Qt runtime libraries to v4.8.4 (2012-11-29), compiled with MSVC 11.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-02-09)
* Updated Valdec decoder to v1.4.0a (2013-02-11), based on latest AC3Filter Tools
* Updated MediaInfo to v0.7.62 (2013-02-22), compiled with ICL 12.1.7 and MSVC 10.0
* Updated SoX to to v14.4.1 (2012-02-09), compiled with ICL 13.0 and MSVC 10.0
* Updated GnuPG to v1.4.13, compiled with GCC 4.7.2
* Updated language files (big thank-you to all contributors !!!)
* Fixed handling of certain characters when passing meta tags on the command-line
* Fixed Keccak library to not crash on systems without SSE/SSE2 support