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

[LoRd_MuldeR]

Again: Most audio encoders already contain hand-optimized assembler code for the "hot" functions, i.e. the functions where like ~99% of the work is done.

If a particular audio encoder contains optimized assembler code for your CPU, then the encoder will automatically enable/use the optimized assembler code on your system – that is regardless of what compiler or compiler settings were used to compile the plain C/C++ code. If, on the other hand, a particular audio encoder does not contain optimized assembler code for your CPU, then there is nothing I could do about that. You'd have to ask the developer of the particular encoder ;)

All that I can do is change the compiler settings that are used to compile the plain C/C++ code. But, as pointed out several times, this has a lesser effect on the overall performance, compared to the assembler stuff...

(That plus: I already create "generic", "sse2" and "avx" builds of the encoders and LameXP will invoke the appropriate one on each system)

[mariush]

Dude, people told you already in several threads, there's very little optimizations to be done when it comes to audio... and whatever optimizations are already in such programs, they work pretty much the same on Intel and AMD processors.

Whatever "improvements" you would do on audio encoders, it would only increase the speed by a few percentages at best, and nobody cares to invest a huge amount of time for so little benefit .
If you encode the audio track of a 2 hour movie in 10x real time speed (so basically finishing compression in 10 minutes), nobody cares to optimize some software to finish the job in 9 minutes and 30 seconds.

Nobody cares about OGG anymore, it's as good as "deprecated". It's replaced by Opus which is free and open source and produces better quality than MP3 or AAC at majority - if not all - of audio bitrates .
AAC is still worth using because it's used in DVDs and has good compatibility it's often used by Youtube and Apple for streaming audio. Whatever improvements you'd get between different codec versions would probably be psycho-achoustics (as in how to modify the sound to throw out some data for better compression, while tricking your ears into thinking it sounds good)

AC3 is old enough to have its patents expired so you don't have to pay licenses for it, MP3 also expired recently if I'm not mistaken, but the quality of AC3 is not better than MP3... not worth wasting time improving encoding speeds when there's something else better.

If you want something fast and best quality for a music collection, just use FLAC for archival and Opus for listening daily. Use a player like foobar2k and you'll be fine. And if you have a music player, try and see if Rockbox supports your player: https://www.rockbox.org/

If you need speed at compressing FLAC, encode multiple tracks at same time, or use Cuetools.FLAC encoder that can use OpenCL and your video card to compress audio super fast.

Forget about MP3.

[quitemice]

It is been said that you would consider a native Linux version but this is been a while back.

So the simple question is are you still thinking about this?

I don't have the knowledge to do it myself or help you with that though.

I recently switched to Linux and thought it would be very nice :D

I know, i can use wine to run it

[LoRd_MuldeR]

It is been said that you would consider a native Linux version but this is been a while back.

So the simple question is are you still thinking about this?

I don't have the knowledge to do it myself or help you with that though.

I recently switched to Linux and thought it would be very nice :D

I know, i can use wine to run it

It is still possible, because LameXP is written in C++ and based on the Qt cross-platform framework. However, it is unlikely to happen anytime soon, because:
I have a full-time job
Currently, LameXP is compiled with Visual C++ compiler. On Linux we'd have to compile it with GCC or LLVM. While, in theory, all C++ compilers should be "compatible", because they implement the same standard, in reality there always are some differences between compilers that will break your code. So, code that was developed and tested on Visual C++ will certainly require various fixes/workarounds to compile with GCC or LLVM.
Currently, LameXP is built with MSBuild (Visual Studio), which is not an option for Linux. So, in order to build LameXP on Linux we'd have write Makefiles first. Or we'd have to use something like CMake.
While LameXP is based on the Qt framework and most of the code should be perfectly cross-platform, there is also quite some Windows-specific code that uses the Win32 API. Of course, I keep that Windows-specific code separate from the rest, mostly encapsulated in the MUtils library. Still, for any Windows-specific function I'd either have to write a Linux equivalent or find a workaround to get a long without that function.
Currently, all encoders and decoders are included in LameXP as pre-compiled binaries. On Windows, this is necessary, because Windows doesn't ship with the required audio encoders/decoders or a way to get them easily. Also most Windows users don't have a clue how to compile stuff by themselves. But, on Linux, providing pre-compiled binaries is not feasible. Linux binaries generally work only on the same distribution where they have been compiled. So, instead, we'd have to install the required encoder and decoder binaries from the individual distribution's repository. Or have the user compile them. In any case, a lot of things need to change in how encoder/decoder binaries are invoked.

[LoRd_MuldeR]

LameXP v4.15 Beta-8

Changes between v4.14 and v4.15 [*unreleased*]:
* Fixed a bug in auto-rename feature, that caused problems when a meta-tag contained path separators
* Fixed included MediaInfo binary not working on processor without SSE2 support
* Improved file name generation from meta-tags containing characters that are forbidden in file names
* Some improvements for "high DPI" screens: Adjust initial window size according to DPI setting
* Updated Opus encoder/decoder libraries to v1.2-alpha2 (2017-05-05) and Opus-Tools to v0.1.10 (2017-02-22)
* Updated MediaInfo to v0.7.95 (2017-05-04), compiled with ICL 17.0 and MSVC 12.0
* Updated SoX to v14.4.2 (2015-02-22) with Dynamic Audio Normalizer v2.10 (2017-04-14) effect included
* Updated mpg123 decoder to v1.24.0 (2017-03-02), compiled with GCC 6.3.0
* Updated FAAD decoder to v2.7 from CVS in order to include latest libFAAD fixes (2016-11-11)
* Updated Monkey's Audio binary to v4.25 (2017-03-12), compiled with ICL 17.0 and MSVC 14.0
* Some tweaks to the auto-update function in order to speed-up the update check in most situations

[LoRd_MuldeR]

LameXP v4.15 RC-1

Changes between v4.14 and v4.15 [*unreleased*]:
* Fixed a bug in auto-rename feature, that caused problems when a meta-tag contained path separators
* Fixed included MediaInfo binary not working on processor without SSE2 support
* Improved file name generation from meta-tags containing characters that are forbidden in file names
* Some improvements for "high DPI" screens: Adjust initial window size according to DPI setting
* Updated Opus encoder/decoder libraries to v1.2-alpha2 (2017-05-05) and Opus-Tools to v0.1.10 (2017-02-22)
* Updated MediaInfo to v0.7.95 (2017-05-04), compiled with ICL 17.0 and MSVC 12.0
* Updated SoX to v14.4.2 (2015-02-22) with Dynamic Audio Normalizer v2.10 (2017-04-14) effect included
* Updated mpg123 decoder to v1.24.0 (2017-03-02), compiled with GCC 6.3.0
* Updated FAAD decoder to v2.7 from CVS in order to include latest libFAAD fixes (2016-11-11)
* Updated Monkey's Audio binary to v4.25 (2017-03-12), compiled with ICL 17.0 and MSVC 14.0
* Some tweaks to the auto-update function in order to speed-up the update check in most situations

[LoRd_MuldeR]

LameXP v4.15 RC-2

Changes between v4.14 and v4.15 [*unreleased*]:
* Fixed a bug in auto-rename feature, that caused problems when a meta-tag contained path separators
* Fixed included MediaInfo binary not working on processor without SSE2 support
* Improved file name generation from meta-tags containing characters that are forbidden in file names
* Some improvements for "high DPI" screens: Adjust initial window size according to DPI setting
* Updated Opus encoder/decoder libraries to v1.2-beta (2017-05-26) and Opus-Tools to v0.1.10 (2017-05-25)
* Updated MediaInfo to v0.7.95 (2017-05-04), compiled with ICL 17.0 and MSVC 12.0
* Updated SoX to v14.4.2 (2015-02-22) with Dynamic Audio Normalizer v2.10 (2017-04-14) effect included
* Updated mpg123 decoder to v1.24.0 (2017-03-02), compiled with GCC 6.3.0
* Updated FAAD decoder to v2.7 from CVS in order to include latest libFAAD fixes (2016-11-11)
* Updated Monkey's Audio binary to v4.25 (2017-03-12), compiled with ICL 17.0 and MSVC 14.0
* Some tweaks to the auto-update function in order to speed-up the update check in most situations

[LoRd_MuldeR]

LameXP v4.15 Final
https://github.com/lordmulder/LameXP/releases/latest

Changes between v4.14 and v4.15 [2017-05-31]:
* Fixed a bug in auto-rename feature, that caused problems when a meta-tag contained path separators
* Fixed included MediaInfo binary not working on processor without SSE2 support
* Improved file name generation from meta-tags containing characters that are forbidden in file names
* Some improvements for "high DPI" screens: Adjust initial window size according to DPI setting
* Updated Opus encoder/decoder libraries to v1.2-beta (2017-05-26) and Opus-Tools to v0.1.10 (2017-05-25)
* Updated MediaInfo to v0.7.95 (2017-05-04), compiled with ICL 17.0 and MSVC 12.0
* Updated SoX to v14.4.2 (2015-02-22) with Dynamic Audio Normalizer v2.10 (2017-04-14) effect included
* Updated mpg123 decoder to v1.24.0 (2017-03-02), compiled with GCC 6.3.0
* Updated FAAD decoder to v2.7 from CVS in order to include latest libFAAD fixes (2016-11-11)
* Updated Monkey's Audio binary to v4.25 (2017-03-12), compiled with ICL 17.0 and MSVC 14.0
* Some tweaks to the auto-update function in order to speed-up the update check in most situations
* Updated language files (big thank-you to all contributors !!!)

[LoRd_MuldeR]

LameXP v4.16 Alpha-3

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017 with Update-2
* Updated Opus encoder/decoder libraries to v1.2.1 (2017-07-26) and Opus-Tools to v0.1.10 (2017-05-25)
* Updated MediaInfo to v0.7.98 (2017-08-08), compiled with ICL 17.0 and MSVC 12.0
* Some improvements to output file name generation code

[cindernat]

First of all, great program - thank you so much.

One issue I'm having is when I am doing a batch conversion, for any folder that has files in its root directory plus additional folders, the additional folders are ignored.

EG: Within Artist A's folder, I have 3 albums and 4 single tracks (single tracks existing in that artist's root directory). In this scenario, only the single tracks are converted and the 3 album folders are skipped.

Yet Artist B, who only has album folders within their folder and no single tracks, nothing is skipped and all converted.

I hope that makes sense.

Anyone else had this occur?

[LoRd_MuldeR]

First of all, great program - thank you so much.

One issue I'm having is when I am doing a batch conversion, for any folder that has files in its root directory plus additional folders, the additional folders are ignored.

EG: Within Artist A's folder, I have 3 albums and 4 single tracks (single tracks existing in that artist's root directory). In this scenario, only the single tracks are converted and the 3 album folders are skipped.

Yet Artist B, who only has album folders within their folder and no single tracks, nothing is skipped and all converted.

I hope that makes sense.

Anyone else had this occur?

You mean this happens when you are adding a directory to the "Source Files" tab via Drag'n'Drop?

The reason is that, in this case, only the files in the directory itself are added. We do not, by default, add the whole directory tree recursively, because it could easily take ages on a massive directory tree. The only case when it will descend into sub-directories automatically is when the "starting" directory did not contain any files at all. And even then, it only descends to the next level, until some file have been found.

If you which to add a whole directory tree, in a fully recursive manner, you can do so via "File" -> "Open Folder Recursively".

[cindernat]

You mean this happens when you are adding a directory to the "Source Files" tab via Drag'n'Drop?

The reason is that, in this case, only the files in the directory itself are added. We do not, by default, add the whole directory tree recursively, because it could easily take ages on a massive directory tree. The only case when it will descend into sub-directories automatically is when the "starting" directory did not contain any files at all. And even then, it only descends to the next level, until some file have been found.

If you which to add a whole directory tree, in a fully recursive manner, you can do so via "File" -> "Open Folder Recursively".

Yep - that'd be it then. Didn't realise! Will take note for next time. Thank you!

[LoRd_MuldeR]

LameXP v4.16 Alpha-4

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017 with Update-3
* Updated Opus encoder/decoder libraries to v1.2.1 (2017-07-26) and Opus-Tools to v0.1.10 (2017-05-25)
* Updated MediaInfo to v0.7.98 (2017-08-08), compiled with ICL 17.0 and MSVC 12.0
* Some improvements to output file name generation code

[dissory]

Thanks for the great program, LoRd_MuldeR!

One thing I noticed though is if I convert .wav files containing metadata to .flac and back again to .wav all the original .wav metadata such as "Track name" is lost. Any way to fix this?

[LoRd_MuldeR]

Thanks for the great program, LoRd_MuldeR!

One thing I noticed though is if I convert .wav files containing metadata to .flac and back again to .wav all the original .wav metadata such as "Track name" is lost. Any way to fix this?

Hello.

The procedure is as follows: We use MediaInfo to detect the meta tags from the original input file, then we decompress the input file to WAV, and finally we encode to temporary WAV using the selected encoder (e.g. LAME, VorbisEnc, OpusEnc, or FLAC). Also, when we invoke the selected encoder, we forward the previously detected meta tags - as far as possible. The capabilities of the different encoders supported by LameXP differ greatly in what meta tags they support. But most of them support at least the bear minimum. Now, the "problem" with the WAV format is that WAV format does not really use an encoder at all! WAV format is the uncompressed output of the decoder. If, for example, you "convert" from FLAC to WAV, the resulting WAV file is actually the direct output of the FLAC decoder! There is no "encoding" step, in which we could embed the meta tags. And, apparently, the FLAC decoder does not add meta tags to the WAV file it produces.

BTW: I'm not even sure there is a standardized way of storing meta tags in WAV files. Sure, the WAV format is based on the RIFF format, so you can add arbitrary additional RIFF chunks to the file and any well-behaving application should simply ignore those additional RIFF chunks, if it doesn't understand them. But unless there is a widely-support standard for embedding meta tags in WAV format, it will be pretty pointless endeavor...

[RieGo]

hello,
just wondering: why is multithreading limited to 10 threads? :)
is it on purpose. is there a setting somewhere?
edit: nevermind. i just found the setting. seems like autodetection is not working properly. setting it manually fixes it

[LoRd_MuldeR]

hello,
just wondering: why is multithreading limited to 10 threads? :)
is it on purpose. is there a setting somewhere?
edit: nevermind. i just found the setting. seems like autodetection is not working properly. setting it manually fixes it

"Auto-detection" is working as expected, probably. That is because auto-detection has not been implemented to simply run as many encoder instances in parallel as there are (logical) CPU cores available. Instead, it has been optimized to run as many encoder instances in parallel as give the maximum throughput (or, equivalently, minimize overall encoding time). Note that running too many instances in parallel can easily result in HDD thrashing and thus slow things down considerably, as all those parallel instances also need to read their respective source file and write their respective output file. The following "cores to instances" curve has been derived experimentally, with the help of various LameXP users:

https://i.imgur.com/6XYwr03.png

[RieGo]

"Auto-detection" is working as expected, probably. That is because auto-detection has not been implemented to simply run as many encoder instances in parallel as there are (logical) CPU cores available. Instead, it has been optimized to run as many encoder instances in parallel as give the maximum throughput (or, equivalently, minimize overall encoding time). Note that running too many instances in parallel can easily result in HDD thrashing and thus slow things down considerably, as all those parallel instances also need to read their respective source file and write their respective output file. The following "cores to instances" curve has been derived experimentally, with the help of various LameXP users:

https://i.imgur.com/6XYwr03.png

wow. that's interesting. thanks for clearing up.
in my case it was faster using more threads manually, but that doesn't mean it's the same for everybody. probably depends on a lot of components.

[mariush]

That may have to revisited, or may need to use a number of threads if the input and outputs are on mechanical drives, and another number for SSDs , RAMDisks, NAS etc.

[LoRd_MuldeR]

In fact, we should probably use a simple "1:1" mapping, when a SSD (solid-state drive) is detected. But it turns out to be surprisingly difficult to tell SSD's and "normal" HDD's apart on windows ;)

Here is an attempt (simple command-line application for now), maybe you can give it a try:
https://sourceforge.net/projects/muldersoft/files/SSDD/SSDD.2017-10-08.zip/download

[mariush]

Yeah, it works fine for me.
First thought that came to mind was running a simple test like reading some 10K random 512 bytes sector reads from the hard drive, as such a big quantity of sectors and so spread out would be unlikely to be cached by the OS. Mechanical drives (even hdd with some nand cache) would have high seek times, while SSDs and ram drives would be fast. NAS drives may be somewhere in between, due to tcp/ip and all that.

[RieGo]

In fact, we should probably use a simple "1:1" mapping, when a SSD (solid-state drive) is detected. But it turns out to be surprisingly difficult to tell SSD's and "normal" HDD's apart on windows ;)

Here is an attempt (simple command-line application for now), maybe you can give it a try:
https://sourceforge.net/projects/muldersoft/files/SSDD/SSDD.2017-10-08.zip/download

my 2 ssds are correctly detected, but the encrypted volume that's on an ssd isn't detected at all (maybe because it's mounted as removable storage?)
but still that's a good starting point

[LoRd_MuldeR]

my 2 ssds are correctly detected, but the encrypted volume that's on an ssd isn't detected at all (maybe because it's mounted as removable storage?)

Not much of a surprise. What we can do is mapping a logical drive (i.e. drive letter) to the underlying physical device or devices – multiple logical drives may map to the same physical device, and a logical drive may span multiple physical devices. Then we can query certain properties of those physical device(s) which allow us to "detected" an SSD or SSD-like drive. However, if some software creates a "virtual" drive, it is pretty much impossible to tell on which physical drive or drives the data is actually stored. It may emulate (and thus look like) a "fixed" disk, but we don't know whether the contents of "virtual" drive are stored on a (local) physical device at all – might be a "RAM" disk, or a "cloud" drive, or whatsoever...

[LoRd_MuldeR]

LameXP v4.16 Alpha-5

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017 with Update-4
* Updated Opus encoder/decoder libraries to v1.2.1 (2017-07-26) and Opus-Tools to v0.1.10 (2017-05-25)
* Updated MediaInfo to v0.7.98 (2017-08-08), compiled with ICL 17.0 and MSVC 12.0
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Improved auto-detection of max. parallel instances on computers with SSD (or similar) drive
* Some improvements to output file name generation code

[Motenai Yoda]

It's me or when there is a beta update it can't be avoided?

[LoRd_MuldeR]

It's me or when there is a beta update it can't be avoided?

See information included with pre-release ("beta") builds:

LameXP Pre-Release Version
--------------------------

This pre-release version of LameXP is intended for testing and evaluation only.
We recommend to *not* use this version for production. Use it at your own risk!

Note: This "test" version of LameXP will expire 30 days after the release date.
LameXP is free/libre software. The "stable" versions of LameXP do *not* expire!

So yeah, if you want to support development of LameXP by testing out pre-release ("beta") builds, then you'll need to update to the latest build about every ~30 days.

There is nothing, though, that would urge you to upgrade from the latest "stable" version to any "beta" version...

[LoRd_MuldeR]

LameXP v4.16 Alpha-6

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017 with Update-4
* 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.7 (2017-09-25), compiled with GCC 7.2.0
* Updated Opus encoder/decoder libraries to v1.2.1 (2017-07-26) and Opus-Tools to v0.1.10 (2017-05-25)
* Updated MediaInfo to v0.7.98 (2017-08-08), compiled with ICL 17.0 and MSVC 12.0
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Improved auto-detection of max. parallel instances on computers with SSD (or similar) drive
* Some improvements to output file name generation code

[LoRd_MuldeR]

LameXP v4.16 Alpha-7

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017 with Update-4
* 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.7 (2017-09-25), compiled with GCC 7.2.0
* Updated Opus encoder/decoder libraries to v1.2.1 (2017-07-26) and Opus-Tools to v0.1.10 (2017-05-25)
* Updated MediaInfo to v0.7.98 (2017-08-08), compiled with ICL 17.0 and MSVC 12.0
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Improved auto-detection of max. parallel instances on computers with SSD (or similar) drive
* Some improvements to output file name generation code

This should fix a compatibility issue in "mpg123" introduces in previous build...

[LoRd_MuldeR]

LameXP v4.16 Alpha-9

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017 with Update-4
* 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.7 (2017-09-25), compiled with GCC 7.2.0
* Updated Opus encoder/decoder libraries to v1.2.1 (2017-07-26) and Opus-Tools to v0.1.10 (2017-05-25)
* Updated MediaInfo to v17.10 (2017-11-02), compiled with ICL 18.0 and MSVC 14.1
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Complete re-write of MediaInfo parsing code, now using XML-based MediaInfo output
* Improved auto-detection of max. parallel instances on computers with SSD (or similar) drive
* Some improvements to output file name generation code

[danlock]

First, obligatory (IMO) appreciation as part of my first post: I love LameXP and have used it for years! :)

Now, my report (the primary message): When converting from any MP3-format file, LameXP stops before decoding the MP3 with an error similar to this:


LameXP v4.16 (Build #2056), compiled on 2017-11-25 at 16:05:01

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

The format of this file is NOT supported:
E:/<directory>/<filename>.mp3

Container Format: MPEG Audio
Audio Format: Type: MPEG Audio, Profile: Layer 3, Version: 1, Bitrate: ≈64 kbps (Variable)

128 kbps (constant) and 320 kbps (constant) files from other sources abort with the same error (indicating the relevant format in the error text).


The CMD console window open at the time of the error contains the following text at the bottom of the output:


Initializing encoding process...
DiskSpace observer started!
CPU observer started!
RAM observer started!
Process thread {f4d1a364-f902-481d-a14a-5f7e2b2ab27b} has started.
Running jobs: 0



This has occurred only for the past 2-3 alpha versions of LameXP.

As far as I can remember, the first version which used the "new" version of LAME did not abort MP3 decoding with that error, but more-recent versions of LameXP have presented that error upon MP3 decode. (edit: I'm not completely certain about that)

Thanks for reading! :)

[manolito]

Hi danlock,

interesting report...
I am quite sure that it's not Lame.exe which is to blame, but that it is something about the latest Alpha versions of LXP which causes the issue.

I still use the current stable version 4.15, and because I never liked LoRd_MuldeR's approach to use Alpha versions of some helper tools even in stable LXP versions I regularly replace these tools with stable versions. In this case it was Lame v. 3.100 Alpha which I replaced with v. 3.95 stable.

After your post I updated Lame for LXP with the current stable version 3.100 (I used the RareWares download), and it works flawlessly for decoding and encoding. No problems whatsoever, and for me this means that the fault you are experiencing is caused not by Lame.exe, but by the current LXP Alpha.


Cheers
manolito

[danlock]

Right... the stable build has the older version of LAME and older versions of Opus and opusenc.

I want the newer Opus very much [from the unreleased builds] because it is a large upgrade in terms of audio quality when encoding certain files and fixes some bugs.

The unreleased alpha/beta builds contain, as far as LAME goes, an update to "LAME encoder v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1" ...

I'm wondering if I lack a support file to run files compiled "with ICL 18.0 and MSVC 14.1". I'll check for a Microsoft runtime for MSVC 14.1 and see if my up-to-date system already has it installed. I'll have to search for ICL because I'm not sure what that acronym stands for. I'm too tired right now to verify that particular acronym, so I'll check it later... or it might pop into my head when I'm more alert.

Thanks for the reply! I know rolling back to the most recent stable build is an option, but that would mean using libopus 1.x rather than the newest 2.1.1 [virtually identical to 2.1] for encoding, and 1.1.x and 2.x behave surprisingly differently when encoding audio.

You can check opus-codec.org or the Opus RFC's (https://tools.ietf.org/html/rfc6716) most recent update (https://tools.ietf.org/html/rfc8251) at ietf.org as well as the Opus thread on hydrogenaud.io for a more precise Opus changelog... but I digress.

I'm eager to read LoRd MuldeR's response... does LAME 3.100 Final support every variation of MP3-encoded file? It says Final so it should, right? Did any of the CLI options change that haven't yet been fixed in LameXP's code, or does its method of invocation/hooking differ in some way from the earlier versions of LAME and/or mpg123 which worked correctly? [This version might work correctly as well, depending on a few things on my end.]

I still suspect it might be a missing dependency on my system rather than anything LM did. I keep forgetting to check for and validate certain things that might be responsible.... hmm. :o

[manolito]

I assume that you are familiar with the LXP method to replace built-in tools with different versions...
https://forum.doom9.org/showthread.php?p=1806010#post1806010

Using this method it should be easy to replace the built-in Opus files (opusdec.exe and opusenc.exe) with newer ones. Of course only as long as the user interface has not changed.

As for your concerns about missing support files for newer executables I don't think so. ICL means "Intel Compiler" and MSVC stands for "Microsoft Visual C". LoRd_MuldeR always made sure that LXP is self-contained so it does not need any additional support libraries.


Cheers
manolito

[LoRd_MuldeR]

First, obligatory (IMO) appreciation as part of my first post: I love LameXP and have used it for years!

You are welcome!

When converting from any MP3-format file, LameXP stops before decoding the MP3 with an error similar to this:
LameXP v4.16 (Build #2056), compiled on 2017-11-25 at 16:05:01

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

The format of this file is NOT supported:
E:/<directory>/<filename>.mp3

Container Format: MPEG Audio
Audio Format: Type: MPEG Audio, Profile: Layer 3, Version: 1, Bitrate: ≈64 kbps (Variable)

128 kbps (constant) and 320 kbps (constant) files from other sources abort with the same error (indicating the relevant format in the error text).[INDENT]

Hello, is that really everything you can see in the log of the failed job?

I'm suspicious, because I can see no error there. Doesn't even look like it started doing anything :confused:

As far as I can remember, the first version which used the "new" version of LAME did not abort MP3 decoding with that error, but more-recent versions of LameXP have presented that error upon MP3 decode.

I am pretty sure that this problem is not related to the LAME encoder, or the MPG123 decoder, since from you log it doesn't look like we ever got to the point where any of those would be invoked.

Instead, I suspect that it is somehow related to the recent MediaInfo changes. I will have to look into this ASAP... (but not tonight ;))

[danlock]

Hello, is that really everything you can see in the log of the failed job?

Before that, it [the command window] shows the usual startup information and checks for the presence of the optional other licensed codec files (Nero/FHG/ALAC), then says the file was added correctly. After a line break or two, it then displays the text I quoted in my initial message (presumably text which was displayed after I tried to convert the MP3).

I'm suspicious, because I can see no error there. Doesn't even look like it started doing anything :confused:

Yeah, that's all there is, which is what confused me also.

Only MP3 files seem to be affected, and the process of decoding aborts before it starts with a LameXP error window saying the file can't be processed and indicating I can click (double-click?) the filename for more details. The window displayed after clicking the filename is where the "This file is NOT supported!" error I quoted is shown. After that, I can close that window and continue using LameXP for other things or quit or whatever.

I've tried both changing and removing tags/metadata (ID3 v1.1 and v2.x) in the problematic MP3 files LameXP has told me were not supported (despite my having used them as source files in older versions of LameXP without error before) and LameXP still reports the files as "NOT supported" and doesn't even begin the decoding process.

I think you're correct in suspecting that LAME has not yet been invoked when the file is reported as being unsupported; in my fatigue when writing the initial message, I was confusing LameXP's error window with one reporting output from LAME.

Admittedly, I've only tried converting Ogg, Opus, MP3, WAV, and FLAC files during the time this "no MP3" error has existed in the betas, so I don't know whether any other non-MP3 files abort prior to decoding (Ogg, Opus, WAV, and FLAC work correctly and as-expected).

thanks! :)

[danlock]

I assume that you are familiar with the LXP method to replace built-in tools with different versions...
https://forum.doom9.org/showthread.php?p=1806010#post1806010

Using this method it should be easy to replace the built-in Opus files (opusdec.exe and opusenc.exe) with newer ones. Of course only as long as the user interface has not changed.

I read that, but didn't think of it until now. Thanks for reminding me, manolito. :D I'll keep that in mind if I decide to use that method. (I think all the changes to Opus were internal and did not affect the interface.)

[manolito]

Instead, I suspect that it is somehow related to the recent MediaInfo changes. I will have to look into this ASAP... (but not tonight ;))

In my LameXP installation of the stable version 4.15 I have replaced the built-in MediaInfo.exe with the current version 17.10 from the Mediaarea Web page:
http://mediaarea.net/download/binary/mediainfo/17.10/MediaInfo_CLI_17.10_Windows_i386.zip

and this does not introduce any problems. If the issue is related to recent MediaInfo changes, then it looks like it must be your MediaInfo build which comes with the LXP installer.

Should be easy to confirm by danlock:
Just download MediaInfo.exe from the above link and put the executable in the appropriate folder. If the problem disappears then it does not have anything to do with MediaInfo.


Cheers
manolito

[LoRd_MuldeR]

In my LameXP installation of the stable version 4.15 I have replaced the built-in MediaInfo.exe with the current version 17.10 from the Mediaarea Web page:
http://mediaarea.net/download/binary/mediainfo/17.10/MediaInfo_CLI_17.10_Windows_i386.zip

and this does not introduce any problems. If the issue is related to recent MediaInfo changes, then it looks like it must be your MediaInfo build which comes with the LXP installer.

It is the "XML formatted" output of MediaInfo that has changed recently:

Version 17.10, 2017-11-02
--------------
[...]
+ New MediaInfo XML output, with XSD, more suitable for automatic parsing. Use Option("Inform", "OLDXML") for keeping previous behavior
[...]

...and only the latest LameXP v4.16 builds will actually request XML format from MediaInfo. Which explains why older versions are not affected.

[LoRd_MuldeR]

LameXP v4.16 Alpha-10

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017 with Update-4
* 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.7 (2017-09-25), compiled with GCC 7.2.0
* Updated Opus encoder/decoder libraries to v1.2.1 (2017-07-26) and Opus-Tools to v0.1.10 (2017-05-25)
* Updated MediaInfo to v17.10 (2017-11-02), compiled with ICL 18.0 and MSVC 14.1
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Complete re-write of MediaInfo parsing code, now using XML-based MediaInfo output
* Improved auto-detection of max. parallel instances on computers with SSD (or similar) drive
* Some improvements to output file name generation code

[LoRd_MuldeR]

Yeah, that's all there is, which is what confused me also.

Only MP3 files seem to be affected, and the process of decoding aborts before it starts with a LameXP error window saying the file can't be processed and indicating I can click (double-click?) the filename for more details. The window displayed after clicking the filename is where the "This file is NOT supported!" error I quoted is shown. After that, I can close that window and continue using LameXP for other things or quit or whatever.

So, the "format version" string returned by MediaInfo (in XML format) has changed slightly. This resulted in LameXP failing to select the "right" decoder class. Instead, the file was treated like an unsupported format.

Should be fixed (https://github.com/lordmulder/LameXP/commit/ec3632aa4581d8b85c078771b7893f2b182ec969) by now, hopefully ;)

[Floatingshed]

Hello LoRd_MuldeR, I have only just discovered this excellent tool. I was searching for a quick and easy way to convert 12,000 audio files to a much smaller size for streaming use. Quality is unimportant, it is to serve as a reminder of how the audio sounds (begins and ends) in a remote radio environment. Anyway I am converting to ogg with quality -2, I could cut my file sizes even further by switching to mono but that option is only available for mp3. Can I possibly override the ogg settings somehow? Thanks.

[LoRd_MuldeR]

Hello LoRd_MuldeR, I have only just discovered this excellent tool. I was searching for a quick and easy way to convert 12,000 audio files to a much smaller size for streaming use. Quality is unimportant, it is to serve as a reminder of how the audio sounds (begins and ends) in a remote radio environment. Anyway I am converting to ogg with quality -2, I could cut my file sizes even further by switching to mono but that option is only available for mp3. Can I possibly override the ogg settings somehow? Thanks.

Yes. Try adding the custom OggEnc2 option "--downmix". From OggEnc2 manpage:

--downmix Downmix stereo to mono. Only allowed on stereo
input.

[Floatingshed]

I followed the instructions precisely, created the tools/version folder structure but it doesn't appear to be using my oggenc2 at all.

[manolito]

I think you misunderstood LoRd_Mulder's instructions. To add a custom option to the Ogg encoder there is no need to create a "tools\version" folder - this is meant for using a different encoder executable.

In LameXP under "Advanced Options" near to the bottom there are fields where you can add custom options to the internal encoders. Just enter "--downmix" here for the Ogg encoder.

Good luck
manolito

[LoRd_MuldeR]

In LameXP under "Advanced Options" near to the bottom there are fields where you can add custom options to the internal encoders. Just enter "--downmix" here for the Ogg encoder.

Exactly. Also there is a small help button at that location, which will show you other "custom" options you may add.

[Floatingshed]

Oh how stupid of me, I didn't notice that the advanced options panel was scrollable. Duh!
Thanks both.

[danlock]

I didn't notice that the advanced options panel was scrollable.
@Floatingshed: In my experience, changing the bitrate and channels (mono/stereo/etc.) for MP3 files near the top of the Advanced Options tab will cause LameXP to encode Ogg files using the same options as long as the options chosen are valid for Ogg.

Using the Custom Options available for each filetype as suggested by manolito and verified by LoRd MuldeR seems like a more precise method of doing so, however.

@LoRd MuldeR: Thanks for the quick fix :) I wish all software were as easy to update as LameXP and other similarly-simple auto-updating programs! Vielen Dank!
:thanks:

[LoRd_MuldeR]

LameXP v4.16 Beta-1

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.2.1-35 (2017-11-16) and Opus-Tools to v0.1.10-9 (2017-05-25)
* Updated MediaInfo to v17.10 (2017-11-02), compiled with ICL 18.0 and MSVC 14.1
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* 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

[LoRd_MuldeR]

LameXP v4.16 Beta-2

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.2.1-35 (2017-11-16) and Opus-Tools to v0.1.10-9 (2017-05-25)
* Updated Monkey's Audio binary to v4.33 (2017-12-01), 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.10 (2017-11-02), compiled with ICL 18.0 and MSVC 14.1
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* 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-3

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.2.1-35 (2017-11-16) and Opus-Tools to v0.1.10-9 (2017-05-25)
* 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.10 (2017-11-02), 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[/COLOR]