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

[LoRd_MuldeR]

LameXP v4.16 Beta-6

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017 with Update-5
* Updated LAME encoder to v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1
* Updated mpg123 decoder to v1.25.8 (2017-12-02), compiled with GCC 7.2.0
* Updated Opus encoder/decoder libraries to v1.3-beta-2 (2018-01-26) and Opus-Tools to v0.1.10-12 (2018-01-02)
* Updated Monkey's Audio binary to v4.33 (2017-12-01), compiled with ICL 18.0 and MSVC 15.5
* Updated FAAD decoder to v2.8.6 (2017-10-10), compiled with ICL 18.0 and MSVC 15.5
* Updated ALAC decoder to refalac v1.64 (2017-05-19), compiled with ICL 18.0 and MSVC 15.5
* Updated WavPack decoder to v5.1.0 (2017-01-20), compiled with ICL 18.0 and MSVC 15.5
* Updated MediaInfo to v17.12 (2017-12-21), compiled with ICL 18.0 and MSVC 14.1
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Updated QAAC add-in (separate download) to QAAC v2.64 (2017-07-19), compiled with ICL 18.0 and MSVC 15.5
* Complete re-write of MediaInfo parsing code, now using XML-based MediaInfo output
* Improved auto-detection of max. parallel instances on computers with "fast" (i.e. SSD or similar) drive
* Some improvements to output file name generation code
* Added "Visual Elements" manifest for Windows 8+ "Start" screen tile

[LoRd_MuldeR]

LameXP v4.16 Beta-9

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017.6 (MSVC 19.13)
* Updated LAME encoder to v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1
* Updated mpg123 decoder to v1.25.8 (2017-12-02), compiled with GCC 7.2.0
* Updated Opus encoder/decoder libraries to v1.3-beta-15 (2018-02-22) and Opus-Tools to v0.1.10-49 (2018-02-24)
* Updated Monkey's Audio binary to v4.33 (2017-12-01), compiled with ICL 18.0 and MSVC 15.5
* Updated FAAD decoder to v2.8.6 (2017-10-10), compiled with ICL 18.0 and MSVC 15.5
* Updated ALAC decoder to refalac v1.64 (2017-05-19), compiled with ICL 18.0 and MSVC 15.5
* Updated WavPack decoder to v5.1.0 (2017-01-20), compiled with ICL 18.0 and MSVC 15.5
* Updated MediaInfo to v17.12 (2017-12-21), compiled with ICL 18.0 and MSVC 14.1
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Updated QAAC add-in (separate download) to QAAC v2.64 (2017-07-19), compiled with ICL 18.0 and MSVC 15.5
* Complete re-write of MediaInfo parsing code, now using XML-based MediaInfo output
* Improved auto-detection of max. parallel instances on computers with "fast" (i.e. SSD or similar) drive
* Some improvements to output file name generation code
* Added "Visual Elements" manifest for Windows 8+ "Start" screen tile
* Some more protection against "DLL pre-loading" attacks has been implemented

[ggtop]

Hi LordMulder,
I recently figured out LameXP has a cuesheet import function :D. That'll make my life a lot of easier in the future because I used other tools in the past to split WAV images...
One cosmetic thing though. The column index is dropping the hour from the timestamp (title 10). See attached screenshot from LameXP and the original cue file created by Exact Audio Copy.
BTW Would be better to display 63... min instead of 1:03:...

TRACK 09 AUDIO
TITLE "Track09"
PERFORMER "Die drei !!!"
REM COMPOSER ""
INDEX 01 57:30:36
TRACK 10 AUDIO
TITLE "Track10"
PERFORMER "Die drei !!!"
REM COMPOSER ""
INDEX 01 63:51:43

Have nice Eastern,
ggtop

[LoRd_MuldeR]

Hi LordMulder,
I recently figured out LameXP has a cuesheet import function :D. That'll make my life a lot of easier in the future because I used other tools in the past to split WAV images...
One cosmetic thing though. The column index is dropping the hour from the timestamp (title 10). See attached screenshot from LameXP and the original cue file created by Exact Audio Copy.
BTW Would be better to display 63... min instead of 1:03:...

TRACK 09 AUDIO
TITLE "Track09"
PERFORMER "Die drei !!!"
REM COMPOSER ""
INDEX 01 57:30:36
TRACK 10 AUDIO
TITLE "Track10"
PERFORMER "Die drei !!!"
REM COMPOSER ""
INDEX 01 63:51:43

Have nice Eastern,
ggtop

Okay, I see why that happens. I was using the QTime (http://doc.qt.io/archives/qt-4.8/qtime.html) class to convert the time index to a string. QTime wraps around the "minute" component to zero after 59 :eek:

Now I'm doing the conversion manually, so that the "minute" component can go up to 99. Please try with the new TEST build:
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2018-04-01/LameXP-BETA.2018-04-01.Release-Static.Build-2106.exe/download

Regards.

[ggtop]

...Please try with the new TEST build...

Many thanks for the quick fix. I can confirm it works. Also tested some other cue/wav files.

ggtop

[LoRd_MuldeR]

LameXP v4.16 RC-1

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017.6 (MSVC 19.13)
* Updated LAME encoder to v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1
* Updated mpg123 decoder to v1.25.10 (2018-03-05), compiled with GCC 7.3.0
* Updated Opus encoder/decoder libraries to v1.3-beta-31 (2018-03-27) and Opus-Tools to v0.1.10-51 (2018-03-04)
* Updated Monkey's Audio binary to v4.33 (2017-12-01), compiled with ICL 18.0 and MSVC 15.5
* Updated FAAD decoder to v2.8.6 (2017-10-10), compiled with ICL 18.0 and MSVC 15.5
* Updated ALAC decoder to refalac v1.64 (2017-05-19), compiled with ICL 18.0 and MSVC 15.5
* Updated WavPack decoder to v5.1.0 (2017-01-20), compiled with ICL 18.0 and MSVC 15.5
* Updated MediaInfo to v17.12 (2017-12-21), compiled with ICL 18.0 and MSVC 14.1
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Updated QAAC add-in (separate download) to QAAC v2.64 (2017-07-19), compiled with ICL 18.0 and MSVC 15.5
* Complete re-write of MediaInfo parsing code, now using XML-based MediaInfo output
* Improved auto-detection of max. parallel instances on computers with "fast" (i.e. SSD or similar) drive
* Some improvements to output file name generation code
* Added "Visual Elements" manifest for Windows 8+ "Start" screen tile
* Some more protection against "DLL pre-loading" attacks has been implemented

[LoRd_MuldeR]

LameXP v4.16 RC-2

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017.6 (MSVC 19.13)
* Updated LAME encoder to v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1
* Updated mpg123 decoder to v1.25.10 (2018-03-05), compiled with GCC 7.3.0
* Updated Opus encoder/decoder libraries to v1.3-beta-31 (2018-03-27) and Opus-Tools to v0.1.10-51 (2018-03-04)
* Updated Monkey's Audio binary to v4.33 (2017-12-01), compiled with ICL 18.0 and MSVC 15.5
* Updated FAAD decoder to v2.8.6 (2017-10-10), compiled with ICL 18.0 and MSVC 15.5
* Updated ALAC decoder to refalac v1.64 (2017-05-19), compiled with ICL 18.0 and MSVC 15.5
* Updated WavPack decoder to v5.1.0 (2017-01-20), compiled with ICL 18.0 and MSVC 15.5
* Updated MediaInfo to v17.12 (2017-12-21), compiled with ICL 18.0 and MSVC 14.1
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Updated QAAC add-in (separate download) to QAAC v2.64 (2017-07-19), compiled with ICL 18.0 and MSVC 15.5
* Complete re-write of MediaInfo parsing code, now using XML-based MediaInfo output
* Improved auto-detection of max. parallel instances on computers with "fast" (i.e. SSD or similar) drive
* Some improvements to output file name generation code
* Added "Visual Elements" manifest for Windows 8+ "Start" screen tile
* Some more protection against "DLL pre-loading" attacks has been implemented

[Kisa_AG]

LameXP v4.16 RC-2
...
* Updated QAAC add-in (separate download) to QAAC v2.64 (2017-07-19), compiled with ICL 18.0 and MSVC 15.5
...

Hello!
Why don't you update QAAC to the newesr 2.66? Anything wrong with it?

[LoRd_MuldeR]

Hello!
Why don't you update QAAC to the newesr 2.66? Anything wrong with it?

The changelog for v4.16 is the accumulation of everything that happened in the past ~1 year since the previous release.

QAAC v2.64 simply was the latest version of QAAC at the time when I last updated QAAC.

I usually try to keep all tools up-to-date, but I also have a real-life job, so I can't update everything all the time ;)

(Also, don't expect any "spectacular" improvements in the new QAAC version. After all, it is "only" front-end to Apple's AAC encoder)

[LoRd_MuldeR]

LameXP v4.16 RC-3

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017.6 (MSVC 19.13)
* Updated LAME encoder to v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1
* Updated mpg123 decoder to v1.25.10 (2018-03-05), compiled with GCC 7.3.0
* Updated Opus encoder/decoder libraries to v1.3-beta-31 (2018-03-27) and Opus-Tools to v0.1.10-51 (2018-03-04)
* Updated Monkey's Audio binary to v4.33 (2017-12-01), compiled with ICL 18.0 and MSVC 15.5
* Updated FAAD decoder to v2.8.6 (2017-10-10), compiled with ICL 18.0 and MSVC 15.5
* Updated ALAC decoder to refalac v1.64 (2017-05-19), compiled with ICL 18.0 and MSVC 15.5
* Updated WavPack decoder to v5.1.0 (2017-01-20), compiled with ICL 18.0 and MSVC 15.5
* Updated MediaInfo to v18.03.1 (2018-03-26), compiled with ICL 18.2 and MSVC 15.6
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Updated QAAC add-in (separate download) to QAAC v2.64 (2017-07-19), compiled with ICL 18.0 and MSVC 15.5
* Complete re-write of MediaInfo parsing code, now using XML-based MediaInfo output
* Improved auto-detection of max. parallel instances on computers with "fast" (i.e. SSD or similar) drive
* Some improvements to output file name generation code
* Added "Visual Elements" manifest for Windows 8+ "Start" screen tile
* Some more protection against "DLL pre-loading" attacks has been implemented

[johnsonlam]

The changelog for v4.16 is the accumulation of everything that happened in the past ~1 year since the previous release.

QAAC v2.64 simply was the latest version of QAAC at the time when I last updated QAAC.

I usually try to keep all tools up-to-date, but I also have a real-life job, so I can't update everything all the time ;)

(Also, don't expect any "spectacular" improvements in the new QAAC version. After all, it is "only" front-end to Apple's AAC encoder)

Thanks for your work, I've enjoy LameXP and other utilities for almost a decade, some people did have most of their real-life besides the monitor, never mind.
I've noticed both the Doom9 and HydrogenAudio was not as crowd as before.

[LoRd_MuldeR]

LameXP v4.16 RC-4

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017.6 (MSVC 19.13)
* Updated LAME encoder to v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1
* Updated mpg123 decoder to v1.25.10 (2018-03-05), compiled with GCC 7.3.0
* Updated Opus encoder/decoder libraries to v1.3-beta-31 (2018-03-27) and Opus-Tools to v0.1.10-51 (2018-03-04)
* Updated Monkey's Audio binary to v4.33 (2017-12-01), compiled with ICL 18.0 and MSVC 15.5
* Updated FAAD decoder to v2.8.6 (2017-10-10), compiled with ICL 18.0 and MSVC 15.5
* Updated ALAC decoder to refalac v1.64 (2017-05-19), compiled with ICL 18.0 and MSVC 15.5
* Updated WavPack decoder to v5.1.0 (2017-01-20), compiled with ICL 18.0 and MSVC 15.5
* Updated MediaInfo to v18.03.1 (2018-03-26), compiled with ICL 18.2 and MSVC 15.6
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Updated QAAC add-in (separate download) to QAAC v2.64 (2017-07-19), compiled with ICL 18.0 and MSVC 15.5
* Complete re-write of MediaInfo parsing code, now using XML-based MediaInfo output
* Improved auto-detection of max. parallel instances on computers with "fast" (i.e. SSD or similar) drive
* Some improvements to output file name generation code
* Added "Visual Elements" manifest for Windows 8+ "Start" screen tile
* Some more protection against "DLL pre-loading" attacks has been implemented

[boyumeow]

Sorry to bother U again, but I just encounter the not able to encode Chinese character named song again, just wonder was this fixed before cause I somehow remember U did it?

LameXP v4.16 (Build #2124), compiled on 2018-04-17 at 20:19:48

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

C:/Users/AhBoy/AppData/Local/Temp/e507d1c81c1faf6c/lxp_oggdec.exe -w C:\Users\AhBoy\AppData\Local\Temp\e507d1c81c1faf6c\07d05cd64630cc93.wav "E:\Animovies\And to be remux\天下有情人.ogg"

OggDec v1.10.1 (libVorbis 1.3.5) Compiled on: Mar 19 2015
ERROR: cannot open E:\Animovies\And to be remux\?????.ogg
********** Done decoding all input files. **********

Exited with code: 0x0000

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

C:/Users/AhBoy/AppData/Local/Temp/e507d1c81c1faf6c/lxp_sox.exe --i C:\Users\AhBoy\AppData\Local\Temp\e507d1c81c1faf6c\07d05cd64630cc93.wav

C:\Users\AhBoy\AppData\Local\Temp\e507d1c81c1faf6c\lxp_sox.exe FAIL formats: can't open input file `C:\Users\AhBoy\AppData\Local\Temp\e507d1c81c1faf6c\07d05cd64630cc93.wav': WAVE: RIFF header not found

Exited with code: 0x0001

It encode successfully if I rename it to English character. I'm using Win10x64 for your info.

Thanks and have a nice everyday.

[LoRd_MuldeR]

Sorry to bother U again, but I just encounter the not able to encode Chinese character named song again, just wonder was this fixed before cause I somehow remember U did it?

It encode successfully if I rename it to English character. I'm using Win10x64 for your info.

Thanks and have a nice everyday.

According to your log, the file name was passed correctly to OggDec by LameXP, however OggDec failed to open the file.

It appears that OggDec does not support Unicode file names :o

Maybe I will try to build OggDec from the sources myself and patch in Unicode support...

[LoRd_MuldeR]

LameXP v4.16 RC-6

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017.6 (MSVC 19.13)
* Updated LAME encoder to v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1
* Updated mpg123 decoder to v1.25.10 (2018-03-05), compiled with GCC 7.3.0
* Updated Opus encoder/decoder libraries to v1.3-beta-31 (2018-03-27) and Opus-Tools to v0.1.10-51 (2018-03-04)
* Updated Monkey's Audio binary to v4.33 (2017-12-01), compiled with ICL 18.0 and MSVC 15.5
* Updated FAAD decoder to v2.8.6 (2017-10-10), compiled with ICL 18.0 and MSVC 15.5
* Updated Vorbis decoder to OggDec v1.10.1+ (2015-03-19), using libVorbis v1.3.6 (2018-03-16)
* Updated ALAC decoder to refalac v1.64 (2017-05-19), compiled with ICL 18.0 and MSVC 15.5
* Updated WavPack decoder to v5.1.0 (2017-01-20), compiled with ICL 18.0 and MSVC 15.5
* Updated MediaInfo to v18.03.1+ (2018-04-19), compiled with ICL 18.2 and MSVC 15.6
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Updated QAAC add-in (separate download) to QAAC v2.64 (2017-07-19), compiled with ICL 18.0 and MSVC 15.5
* Complete re-write of MediaInfo parsing code, now using XML-based MediaInfo output
* Improved auto-detection of max. parallel instances on computers with "fast" (i.e. SSD or similar) drive
* Some improvements to output file name generation code
* Added "Visual Elements" manifest for Windows 8+ "Start" screen tile
* Some more protection against "DLL pre-loading" attacks has been implemented

[boyumeow]

Hi LM, thanks for your kind attention and quick fix, this static build 2130 works for the Unicode support, hope I didn't create new bugs to LameXP.
Didn't realize OggDec does not support Unicode file names, I only just found it a few days ago when I want to share the happiness with a friend, not sure her phone support playing ogg files, so thinking encode into mp3.
Anyway, thanks and have a nice everyday :).

[foxyshadis]

Do you have the Oggdec patch? Sounds like it'd be useful to polish up and submit to xiph. Fortunately Opus doesn't seem to have that problem.

[LoRd_MuldeR]

Do you have the Oggdec patch? Sounds like it'd be useful to polish up and submit to xiph. Fortunately Opus doesn't seem to have that problem.

Opus-Tools doesn't have the problem (anymore), as my Unicode patch was already adopted (http://git.xiph.org/?p=opus-tools.git;a=commit;h=58347273ab4c9e9d30ab8ffd62acbac348f7e0c8). The patch for OggDec (John Edwards' version) is provided here (https://github.com/lordmulder/LameXP/blob/master/etc/Patches/OggDec-v1.10.1-Win32-UnicodeSupport%2BFlushFix.diff). Also submitted to the author.

[Gravitator]

Привет.
The program instead of the directory "Z:" selects the directory in which the LameXP program is installed "Z:\LameXP".
> DEMO (https://files.videohelp.com/u/227452/LameXP-RC6.2018-04-20.Release-Static.Build-2130%20%281%29.mkv)

[LoRd_MuldeR]

Привет.
The program instead of the directory "Z:" selects the directory in which the LameXP program is installed "Z:\LameXP".
> DEMO (https://files.videohelp.com/u/227452/LameXP-RC6.2018-04-20.Release-Static.Build-2130%20%281%29.mkv)

Seems strange :confused:

Would you kindly try with this version and watch out for the additional debug output?
https://sourceforge.net/projects/muldersoft/files/LameXP/Testing/LameXP-TEST.2018-04-28.zip/download

:thanks:

[Gravitator]

This version is normal...
Build #2131 and #2130 Identical? Perhaps the installer influenced the landmark :confused:

[LoRd_MuldeR]

This version is normal...
Build #2131 and #2130 Identical?

Well, not identical, obviously. But only change is that I added more "debug" output, so we can see (hopefully) where exactly things go mad.

Perhaps the installer influenced the landmark :confused:

I don't know how this should be possible. The installer doesn't really do anything, except for extracting the EXE file (and stuff) to the chosen directory.

The LameXP EXE file that us extracted from the installer is really exactly the same one as contained in the ZIP archive.

So, if you see divergent behavior between build #2131 and build #2130, something different must have happened, at runtime, I suppose...

[Gravitator]

Reinstalling to the default directory eliminates the bug!

[LoRd_MuldeR]

Reinstalling to the default directory eliminates the bug!

Strange :confused:

Anyway, if you think that the problem is somehow related to the "install directory", please try running the special build (https://sourceforge.net/projects/muldersoft/files/LameXP/Testing/LameXP-TEST.2018-04-28.zip/download) from the exact "install directory" where the problem occurs.

:thanks:

[Gravitator]

The program is affected by the dependence of the presence in the roots of the disk ... Only to trace this bug is not possible through a special version :( I'll wait for the final release :)

[LoRd_MuldeR]

The program is affected by the dependence of the presence in the roots of the disk ... Only to trace this bug is not possible through a special version :( I'll wait for the final release :)

If there is a problem, we should fix it before the final release.

But if you cannot it with the "special build", which is the same as previous build just with more diagnostic output added to the console, then I don't know what to do...

[LoRd_MuldeR]

LameXP v4.16 has been released :)
https://github.com/lordmulder/LameXP/releases/latest

Changes between v4.15 and v4.16 [2018-04-30]:
* Upgraded build environment to Microsoft Visual Studio 2017.6 (MSVC 19.13)
* Updated LAME encoder to v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1
* Updated mpg123 decoder to v1.25.10 (2018-03-05), compiled with GCC 7.3.0
* Updated Opus encoder/decoder libraries to v1.3-beta-31 (2018-03-27) and Opus-Tools to v0.1.10-51 (2018-03-04)
* Updated Monkey's Audio binary to v4.33 (2017-12-01), compiled with ICL 18.0 and MSVC 15.5
* Updated FAAD decoder to v2.8.6 (2017-10-10), compiled with ICL 18.0 and MSVC 15.5
* Updated Vorbis decoder to OggDec v1.10.1+ (2015-03-19), using libVorbis v1.3.6 (2018-03-16)
* Updated ALAC decoder to refalac v1.64 (2017-05-19), compiled with ICL 18.0 and MSVC 15.5
* Updated WavPack decoder to v5.1.0 (2017-01-20), compiled with ICL 18.0 and MSVC 15.5
* Updated MediaInfo to v18.03.1+ (2018-04-19), compiled with ICL 18.2 and MSVC 15.6
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Updated QAAC add-in (separate download) to QAAC v2.64 (2017-07-19), compiled with ICL 18.0 and MSVC 15.5
* Complete re-write of MediaInfo parsing code, now using XML-based MediaInfo output
* Improved auto-detection of max. parallel instances on computers with "fast" (i.e. SSD or similar) drive
* Some improvements to output file name generation code
* Added "Visual Elements" manifest for Windows 8+ "Start" screen tile
* Some more protection against "DLL pre-loading" attacks has been implemented

[SeeMoreDigital]

Fantastico... Many thanks :)

[manolito]

Tested, works fine, thanks a lot... :thanks:

[manolito]

Just found out that the latest version 18.05 of MediaInfo.exe (downloaded from the MediaArea website) cannot be used to replace the LameXP built-in version.

Probably something about Zenitram's changes to the XML output. Right now this is not a big issue, but considering the usual update cycle of LameXP it will be around 1 year until the next stable version. It would be nice if we could use a newer version of MediaInfo without having to install beta versions of LameXP.


Cheers
manolito

[LoRd_MuldeR]

Just found out that the latest version 18.05 of MediaInfo.exe (downloaded from the MediaArea website) cannot be used to replace the LameXP built-in version.

Probably something about Zenitram's changes to the XML output. Right now this is not a big issue, but considering the usual update cycle of LameXP it will be around 1 year until the next stable version. It would be nice if we could use a newer version of MediaInfo without having to install beta versions of LameXP.

LameXP v4.16 comes with a "custom" build of MediaInfo v18.03.1, which contains an additional patch (not contained in "official" MediaInfo v18.03.1 release) in order to fix a bug in XML output.

That bug had been introduced in v18.03 with:
Attachments: do not provide anymore attachments content in XML by default, reducing XML output size

The patch (which my "custom" build of MediaInfo v18.03.1 already contained) is now "officially" included in MediaInfo v18.05. According to the changelog, there were no other changes regarding XML output in MediaInfo v18.05.

I think you should test whether your MediaInfo.exe (downloaded from the MediaArea website) works correctly outside of LameXP – when called with options "--Output=XML" and "--Full" plus "--Cover_Data=base64".

[manolito]

I think you should test whether your MediaInfo.exe (downloaded from the MediaArea website) works correctly outside of LameXP – when called with options "--Output=XML" and "--Full" plus "--Cover_Data=base64".

Just did this with an MP3 containing a cover. The output looks OK to me, here is the result.txt file:
https://www.sendspace.com/file/mw2339

The commandline was:
Mediainfo.exe "--Output=XML" "--Full" "--Cover_Data=base64" i:\test.mp3 >i:\result.txt

LameXP rejects the file with a "format not recognized" error.


Cheers
manolito

[LoRd_MuldeR]

Just did this with an MP3 containing a cover. The output looks OK to me, here is the result.txt file:
https://www.sendspace.com/file/mw2339

The commandline was:
Mediainfo.exe "--Output=XML" "--Full" "--Cover_Data=base64" i:\test.mp3 >i:\result.txt

LameXP rejects the file with a "format not recognized" error.

Okay, I know why that happens: We check the "creatingLibrary" version in the XML output. When using the "built-in" MediaInfo binary, then the expected version of MediaInfo is known and thus the check will succeed – provided that the XML output is correct. But when using an "external" MediaInfo binary, the version of MediaInfo is not known beforehand, and therefore the internal (expected) version is set to UINT_MAX. This makes the "creatingLibrary" check always fail.

Please try with this version:
https://sourceforge.net/projects/muldersoft/files/LameXP/Testing/LameXP-TEST.2018-05-10.zip/download

[manolito]

Yes, this test version fixes it, thanks a lot... :thanks:

It also seems that I can use this executable as a hotfix for the stable version (it does not have a built-in timebomb like the beta versions). Nice...


Cheers
manolito

[AndyTejral]

Hey, I just tried to use LameXP for the first time. And I can't make it work! Trying to convert wma to mp3. Isn't that possible? Here is the error message:



LameXP v4.16 (Build #2134), compiled on 2018-04-30 at 14:48:13

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

The format of this file is NOT supported:
C:/Users/Andy/Music/10,000 Maniacs/Our Time in Eden/01 Noah's Dove.wma

Container Format: Windows Media
Audio Format: Type: WMA, Version: 2, Bitrate: ≈168 kbps (Variable)

[manolito]

Congratulations, on your first post you already discovered a major bug in the latest LameXP version... :devil:

I can confirm your issue, WMA v2 sources are rejected by the current LameXP version. I went back to the previous stable version 4.15, and this version has no problems with these sources.

Time for a hotfix...


Cheers
manolito


And a general rant:
After going back to a previous stable version I noticed that even for stable versions there is a time bomb of 1 year. I think that this is plain stupid. For Alpha, Beta or RC versions I can understand, but not for stable versions. Users may have valid reasons to stick to older stable versions, this latest WMA bug is a good example. Please stop imposing your views on users...

[LoRd_MuldeR]

Hey, I just tried to use LameXP for the first time. And I can't make it work! Trying to convert wma to mp3. Isn't that possible? Here is the error message:



LameXP v4.16 (Build #2134), compiled on 2018-04-30 at 14:48:13

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

The format of this file is NOT supported:
C:/Users/Andy/Music/10,000 Maniacs/Our Time in Eden/01 Noah's Dove.wma

Container Format: Windows Media
Audio Format: Type: WMA, Version: 2, Bitrate: ≈168 kbps (Variable)

It appears that MediaInfo now reports the format version of WMA streams as "N" rather than "Version N", which is why your WMA file was not recognized correctly :rolleyes:

Please try with the new TEST build:
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2018-05-18/LameXP-ALPHA.2018-05-18.Release-Static.Build-2140.exe/download

[AndyTejral]

Well, that worked! And man, that's perhaps the first time I've really given my computer a workout. 99% CPU for 1.6 hours!

And not only that, I intercut the original wav, the wma I made from that wav, and the mp3 I made from the wma. I can't tell the difference!

Great program! Thanks a lot!

[manolito]

I can confirm that the Alpha build 2140 does solve the WMA v2 issue... :cool:

Any chance for a stable hotfix version?

The LameXP test versions are not really user friendly, they expire after 30 days, and installing a newer test version requires users to reenter all their settings. (And you used some dirty tricks to defeat users who just set the system date back to an earlier date... :devil: )

Having to wait for one whole year until the next stable version fixes the WMA issue is not an acceptable option IMO...


Cheers
manolito

[LoRd_MuldeR]

I can confirm that the Alpha build 2140 does solve the WMA v2 issue... :cool:

Any chance for a stable hotfix version?

I'm currently looking into a problem regarding the new FAAD version. Maybe I will make a new release after that issue has been resolved...

[manolito]

:thanks:

[Photon]

Hi all,

I have been using LameXP for over a year - excellent program! However, I'm running into a bug when trying to encode using AAC (qaac 2.66). I don't encounter this problem with either OPUS, MP3 or Vorbis.

I'm currently using Version 4.16, Build 2134.

The problem is this: under the advanced settings tab, when inputting a custom encoding parameter for AAC (in this case, simply: "--tvbr 87") the encode fails, every time.

When inspecting the log, I figured out what the problem was:

https://s15.postimg.cc/wdvdwa8qz/Screen_Shot_2018-06-01_at_10.10.59.png

As you can see, instead of replacing and overriding the default quality setting (--tvbr 91, which the slider is set to under the Compression tab), the custom setting that I want (--tvbr 87) is just appended to the command string, thus conflicting with the first setting. Naturally this means that the encode stops in its tracks before it can do anything. It throws up this message at the bottom:

https://s15.postimg.cc/s8khaainv/Screen_Shot_2018-06-01_at_10.31.17.png

Please let me know if you can replicate this. It's the only thing holding me back from using LameXP for AAC encoding (which is otherwise first class).

[LoRd_MuldeR]

Hi all,

I have been using LameXP for over a year - excellent program! However, I'm running into a bug when trying to encode using AAC (qaac 2.66). I don't encounter this problem with either OPUS, MP3 or Vorbis.

I'm currently using Version 4.16, Build 2134.

The problem is this: under the advanced settings tab, when inputting a custom encoding parameter for AAC (in this case, simply: "--tvbr 87") the encode fails, every time.

When inspecting the log, I figured out what the problem was:

https://s15.postimg.cc/wdvdwa8qz/Screen_Shot_2018-06-01_at_10.10.59.png

As you can see, instead of replacing and overriding the default quality setting (--tvbr 91, which the slider is set to under the Compression tab), the custom setting that I want (--tvbr 87) is just appended to the command string, thus conflicting with the first setting. Naturally this means that the encode stops in its tracks before it can do anything. It throws up this message at the bottom:

https://s15.postimg.cc/s8khaainv/Screen_Shot_2018-06-01_at_10.31.17.png

Please let me know if you can replicate this. It's the only thing holding me back from using LameXP for AAC encoding (which is otherwise first class).

Well, the "custom" parameters are simply appended to the command-line that is generated automatically. And, of course, the generated command-line must contain the switches for the selected RC mode.

If you try to set the RC mode via "custom" parameter too, RC mode will unavoidably appear in the command-line twice – as the program clearly says: "custom" parameters are not validated and you use them at your own risk.

Most CLI tools will allow to specify even "conflicting" switches, in which case simply the last option on the command-line will take effect. This way you can easily "override" options already set by the generated command-line.

But: It appears that QAAC does more "pedantic" checking and won't allow to "override" the already-set RC mode.

There is no easy solution for this, because we would need figure out any possible combination of "conflicting" options. And, if a "conflicting" option was detected, remove that option from the generated command-line...

(Maintaining a list of potentially "conflicting" options – for every supported encoder – would be a lot of work. Just to enable a use-case that was never really intended)

[Photon]

Well, the "custom" parameters are simply appended to the command-line that is generated automatically. And, of course, the generated command-line must contain the switches for the selected RC mode.

If you try to set the RC mode via "custom" parameter too, RC mode will unavoidably appear in the command-line twice – as the program clearly says: "custom" parameters are not validated and you use them at your own risk.

Most CLI tools will allow to specify even "conflicting" switches, in which case simply the last option on the command-line will take effect. This way you can easily "override" options already set by the generated command-line.

But: It appears that QAAC does more "pedantic" checking and won't allow to "override" the already-set RC mode.

There is no easy solution for this, because we would need figure out any possible combination of "conflicting" options. And, if a "conflicting" option was detected, remove that option from the generated command-line...

(Maintaining a list of potentially "conflicting" options – for every supported encoder – would be a lot of work. Just to enable a use-case that was never really intended)

Thanks for the explanation. So in short, there is no way of using a custom-defined bitrate or quality level for AAC in LameXP?

Would it be possible in that case to provide an option somehow tweak the TVBR slider so that we have more granular control? (Maybe an "advanced" slider activated by a checkbox, that allows the user to move up and down in increments of 1). That's the only solution I can think of for this but I don't know how feasible it would be to implement.

Other software allows you to select the TVBR quality level in increments of one right from the GUI, it's just that they don't have any easy was of importing your whole library in one go like LameXP does.

[LoRd_MuldeR]

Thanks for the explanation. So in short, there is no way of using a custom-defined bitrate or quality level for AAC in LameXP?

Yes. Obviously QAAC doesn't allow overwrite of previous options.

Other software allows you to select the TVBR quality level in increments of one right from the GUI, it's just that they don't have any easy was of importing your whole library in one go like LameXP does.

Probably a case of "Placebo Effect" ;)

From QAAC wiki (https://github.com/nu774/qaac/wiki/Encoder-configuration#tvbr-quality-steps):

https://i.imgur.com/nsvIWG8.png


From LameXP code:
static const int g_qaacVBRQualityLUT[16] = {0 ,9, 18, 27, 36, 45, 54, 63, 73, 82, 91, 100, 109, 118, 127, INT_MAX};

class QAACEncoderInfo : public AbstractEncoderInfo
{
virtual int valueCount(int mode) const
{
switch(mode)
{
case SettingsModel::VBRMode:
return 15;
break;
[...]
}
}
virtual int valueAt(int mode, int index) const
{
switch(mode)
{
case SettingsModel::VBRMode:
return g_qaacVBRQualityLUT[qBound(0, index , 14)];
break;
[...]
}
}
[...]
}

[Photon]

Probably a case of "Placebo Effect" ;)

From QAAC wiki (https://github.com/nu774/qaac/wiki/Encoder-configuration#tvbr-quality-steps):

https://i.imgur.com/nsvIWG8.png

Well, I just went away and encoded an album using TVBR 87 and 91 using another program... and you're right, exactly the same file size! Not a jot of difference between them. Never would have known that if I hadn't signed up here. Thanks MuldeR.

[LoRd_MuldeR]

LameXP v4.17 Alpha-3

Changes between v4.15 and v4.16 [2018-04-30]:
* Upgraded build environment to Microsoft Visual Studio 2017.7 (MSVC 19.14)
* Updated Opus encoder/decoder libraries to v1.3-RC-1 (2018-06-01) and Opus-Tools to v0.1.10-71 (2018-04-30)
* Updated MediaInfo to v18.05 (2018-05-09), compiled with ICL 18.2 and MSVC 15.7
* Downgraded FAAD to from v2.8 to v2.7 for now, because v2.8 is currently broken with certain MP4 files
* Fixed detection of certain WMA and AAC files (regression in LameXP v4.16)

[manolito]

I'm currently looking into a problem regarding the new FAAD version. Maybe I will make a new release after that issue has been resolved...

Looks to me like this is not gonna happen...
I won't bother with LameXP Alpha, Beta or RC versions any longer, it's just too annoying. I went back to the stable version 4.15 and updated a few tools, and this will do until the next stable version comes out...


Cheers
manolito

[RieGo]

thanks for your regular updates. still using this tool mainly for opus low bitrate encoding stuff :)
now there's one request i'd like to mention. in LameXP you can only choose between preset bitrate options. 8;16;24 beeing the lowest. now there is quite a big quality gap between 8 and 16 kbit/s in opus.
could you make it possible to somehow be able to set custom bitrate values?
thx

[LoRd_MuldeR]

thanks for your regular updates. still using this tool mainly for opus low bitrate encoding stuff :)
now there's one request i'd like to mention. in LameXP you can only choose between preset bitrate options. 8;16;24 beeing the lowest. now there is quite a big quality gap between 8 and 16 kbit/s in opus.
could you make it possible to somehow be able to set custom bitrate values?
thx

Hello,

for now you could just add "--bitrate <value>" to the custom parameters for OpusEnc, on "Adavanced Options" tab.

This will overwrite the bitrate selected on "Compression" tab.

But if you think that we should add more bitrate steps for Opus towards the lower end, then I could probably do that. Maybe adding 12 kbps and 20 kbps would suffice?

Regards.