LameXP v4.18 Final · Build #2240 (2019-12-18)

[T-Hawk]

Originally Posted by LoRd_MuldeR

It is important to understand that the ReplayGain tag that LAME is creating (by default) is nothing but a meta information. It does not alter the volume of the audio file at all!

ReplayGain normalization happens, if at all, at playback time. So, IMO, there are only two possible situations:

• If you do want ReplayGain to normalize the volume of you media files, then you need a playback software that supports ReplayGain and your media files need to contain proper ReplayGain meta information.
  The latter is exactly what LAME is doing (by default). In other words, LAME prepares the created MP3 files for ReplayGain processing, but the actual processing happens in your playback software.

• If you do not want ReplayGain to normalize the volume of you media files, then use a playback software that does not support ReplayGain –or– just disable the ReplayGain feature of your playback software.
  Either way, as long as ReplayGain is disabled (or unsupported) in your playback software, the ReplayGain meta information that may be present in the media file will simply be ignored.

tl;dr If you don't like ReplayGain processing, then disable it in your playback software

I would rather just not have to deal with it. It's not always obvious if a particular player is using ReplayGain and how to disable it. Foobar and Audacity are not adding the "meta information" to the best of my knowledge and both are using the LAME encoder. So I assume it is a LAMEXP default and not a LAME default. Looks like I will just use Foobar from now on and have to go back to the files I've already converted with LAMEXP and remove the track volume info.

[manolito]

Originally Posted by manolito

But there is a command line switch in Lame.exe which disables calculation of the ReplayGain value, maybe adding "--noreplaygain" to the custom MP3 parameters in LameXP will fix it for you.

Have you tried this workaround?

[LoRd_MuldeR]

Originally Posted by T-Hawk

So I assume it is a LAMEXP default and not a LAME default. Looks like I will just use Foobar from now on and have to go back to the files I've already converted with LAMEXP and remove the track volume info.

Nope, it really is a LAME default. LameXP does nothing to enable ReplayGain tag generation. Though, LameXP does northing to disable this default behavior of LAME either.

See LAME manpage:
https://linux.die.net/man/1/lame

--noreplaygain
Disable ReplayGain analysis.
By default ReplayGain analysis is enabled. This switch disables it.

Manually add switch "--noreplaygain" to custom parameters, if you really wish to suppress ReplayGain tag creation.

[LoRd_MuldeR]

LameXP v4.18 Beta-5

Changes between v4.17 and v4.18 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2017.9 (MSVC 14.16)
* Updated LAME encoder to v3.100.1-SVN (2019-07-23), compiled with ICL 19.0 and MSVC 14.16
* Updated Opus encoder/decoder libraries to v1.3.1 (2019-04-14) and Opus-Tools to v0.2+3 (2018-10-16)
* Updated Vorbis encoder to OggEnc v2.88 (2018-11-14), using libvorbis v1.3.6 with aoTuV b6.03 (2018)
* Updated FLAC encoder/decoder to v1.3.2+ Git (2018-09-19), compiled with ICL 19.0 and MSVC 14.16
* Updated Monkey's Audio binary to v4.73 (2019-05-15), compiled with ICL 19.0 and MSVC 14.16
* Updated mpg123 decoder to v1.25.11 (2019-07-18) and added 64-Bit binaries, compiled with GCC 9.1.0
* Updated MediaInfo to v19.07 (2019-07-16), compiled with ICL 19.0 and MSVC 14.16
* Fixed encoding with Nero AAC encoder for input sampling rate less than 8 KHz or greater than 96 KHz

[manolito]

Since development of LameXP has slowed down considerably, more and more users of the latest stable version now get this at startup:



After clicking "Ignore" there is another message that the update check was declined (accompanied by a very silly sound clip).

Please, if you are too busy to release a new stable version within one year, could you please add an option (maybe hidden in the settings file) to skip this update reminder? It really annoys me to no end...


Cheers
manolito

[LoRd_MuldeR]

Sorry, for the delay. I'm planning to release a new version soon™. In the meantime you can check out RC-2.

LameXP v4.18 RC-2

Changes between v4.17 and v4.18 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2017.9 (MSVC 14.16)
* Updated LAME encoder to v3.100.1-SVN (2019-07-23), compiled with ICL 19.0 and MSVC 14.16
* Updated Opus encoder/decoder libraries to v1.3.1 (2019-04-14) and Opus-Tools to v0.2+3 (2018-10-16)
* Updated Vorbis encoder to OggEnc v2.88 (2018-11-14), using libvorbis v1.3.6 with aoTuV b6.03 (2018)
* Updated FLAC encoder/decoder to v1.3.2+ Git (2018-09-19), compiled with ICL 19.0 and MSVC 14.16
* Updated Monkey's Audio binary to v4.73 (2019-05-15), compiled with ICL 19.0 and MSVC 14.16
* Updated mpg123 decoder to v1.25.11 (2019-07-18) and added 64-Bit binaries, compiled with GCC 9.1.0
* Updated MediaInfo to v19.07 (2019-07-16), compiled with ICL 19.0 and MSVC 14.16
* Added Japanese (日本語) translation, thanks to Maboroshin <pc.genkaku.in>
* Fixed encoding with Nero AAC encoder for input sampling rate less than 8 KHz or greater than 96 KHz

[LoRd_MuldeR]

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

Changes between v4.17 and v4.18 [2019-12-18]:
* Upgraded build environment to Microsoft Visual Studio 2017.9 (MSVC 14.16)
* Updated LAME encoder to v3.100.1-SVN (2019-07-23), compiled with ICL 19.0 and MSVC 14.16
* Updated Opus encoder/decoder libraries to v1.3.1 (2019-04-14) and Opus-Tools to v0.2+3 (2018-10-16)
* Updated Vorbis encoder to OggEnc v2.88 (2018-11-14), using libvorbis v1.3.6 with aoTuV b6.03 (2018)
* Updated FLAC encoder/decoder to v1.3.2+ Git (2018-09-19), compiled with ICL 19.0 and MSVC 14.16
* Updated Monkey's Audio binary to v4.73 (2019-05-15), compiled with ICL 19.0 and MSVC 14.16
* Updated mpg123 decoder to v1.25.11 (2019-07-18) and added 64-Bit binaries, compiled with GCC 9.1.0
* Updated MediaInfo to v19.07 (2019-07-16), compiled with ICL 19.0 and MSVC 14.16
* Added Japanese (日本語) translation, thanks to Maboroshin <pc.genkaku.in>
* Fixed encoding with Nero AAC encoder for input sampling rate less than 8 KHz or greater than 96 KHz
* Updated language files (big thank-you to all contributors !!!)

[manolito]

[Taurus]

[SeeMoreDigital]

Many, many thanks

[VzK]

Thanks for the update!

[danlock]

@LoRd_MuldeR

[Ma-Xell]

[tablerocker]

Thank you for the update!
Little flaw:
On http://lamexp.sourceforge.net/doc/Ch....18-unreleased it says 4.18 is unreleased.
And the given email address lacks the domain ".de".

[LoRd_MuldeR]

Originally Posted by tablerocker

Little flaw:
On http://lamexp.sourceforge.net/doc/Ch....18-unreleased it says 4.18 is unreleased.

Latest changelog should now be available.

[Aggregate]

The latest LameXP release has stolen all multimedia files associations to itself (mp3, m3u, wav, etc.), however I don't remember any question about files associations during the installation. Is this normally ? What's the reason for these files associations for LameXP, if it's not an audio player, but it's formats encoder ?

[SeeMoreDigital]

How odd @Aggregate,

What operating system (and version) are your running?

Personally, I'm running Windows 10 Home v1909 [18363.535]...


Cheers

[Aggregate]

I'm using Windows 10 Pro v1909 [18363.535]
I would like to clarify that I've been using LameXP for quite long time, but any previous versions didn't touch file associations, except the last one.

[SeeMoreDigital]

Originally Posted by Aggregate

I'm using Windows 10 Pro v1909 [18363.535]
I would like to clarify that I've been using LameXP for quite long time, but any previous versions didn't touch file associations, except the last one.

Odd... There was no such problem when I installed the newest version of LameXP...

[LoRd_MuldeR]

Originally Posted by Aggregate

The latest LameXP release has stolen all multimedia files associations to itself (mp3, m3u, wav, etc.), however I don't remember any question about files associations during the installation. Is this normally ? What's the reason for these files associations for LameXP, if it's not an audio player, but it's formats encoder ?

Not quite sure what is happening.

What I can say for sure is that the shell integration code, which would be relevant here, has not been changed since some time around 2015:
https://github.com/lordmulder/LameXP...ntegration.cpp

What this code does: For each "supported" file extension (.wav, .mp3, etc. pp.), it will lookup the file type that is currently registered to that extension. Then, for each of those existing file types, it will add a custom command ("ConvertWithLameXP"). The standard "open" command of the file type is not modified. Also, for file extensions that already are registered to a file type, the file extension to file type mapping is not changed.

If and only if one of the "supported" file extensions is not registered to a file type at all (which rarely happens, but is possible), then a mapping to the our own "LameXP.SupportedAudioFile" file type is created for that file extension.

Works as expected for me. This is on Windows 10 v1909:
https://i.imgur.com/KpStPIe.png