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

[LoRd_MuldeR]

LameXP v4.11 RC-4

Changes between v4.10 and v4.11 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 with Update-4
* Starting with this version, LameXP is based on the MUtilities (http://sourceforge.net/p/mutilities/code/) library + massive code clean-up
* Added support for the DynamicAudioNormalizer (https://github.com/lordmulder/DynamicAudioNormalizer) normalization filter
* Updated Qt runtime libraries to v4.8.7 snapshot-4 (2015-02-16), compiled with MSVC 12.0
* Updated MediaInfo to v0.7.72 (2015-01-07), compiled with ICL 15.0 and MSVC 12.0
* Updated SoX to v14.4.2-Final (2015-02-22), compiled with ICL 15.0 and MSVC 12.0
* Updated Opus libraries to v1.1.x and Opus-Tools v0.1.9 to latest Git Master (2015-03-26)
* Updated mpg123 decoder to v1.22.0 (2015-02-24), compiled with GCC 4.9.2
* Updated Vorbis encoder to OggEnc v2.87 (2014-06-24), using libvorbis v1.3.4 and aoTuV b6.03_2014
* Updated Vorbis decoder to OggDec v1.10.1 (2014-06-25), using libVorbis v1.3.4
* Updated FLAC encoder/decoder to v1.3.1 (2014-11-26), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.18 (2014-06-30), compiled with GCC 4.9.1
* Updated QAAC add-in to the latest to QAAC v2.44, including a fix for the --artwork option
* Fixed potential crash in Cue Sheet importer (occurred when all input files were missing)
* Fixed a severe performance bottleneck, especially with a large number of parallel instances
* Fixed a very rare problem that, occasionally, prevented the TEMP folder from being removed
* The limit for the maximum number of parallel instances has been increased to 32
* Experimental support for Windows 10 Technical Preview
* Updated language files (big thank-you to all contributors !!!)

[LoRd_MuldeR]

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

Changes between v4.10 and v4.11 [2015-04-05]:
* Upgraded build environment to Microsoft Visual Studio 2013 with Update-4
* Starting with this version, LameXP is based on the MUtilities (http://sourceforge.net/p/mutilities/code/) library + massive code clean-up
* Added support for the DynamicAudioNormalizer (https://github.com/lordmulder/DynamicAudioNormalizer) normalization filter
* Updated Qt runtime libraries to v4.8.7 snapshot-5 (2015-03-25), compiled with MSVC 12.0
* Updated MediaInfo to v0.7.72 (2015-01-07), compiled with ICL 15.0 and MSVC 12.0
* Updated SoX to v14.4.2-Final (2015-02-22), compiled with ICL 15.0 and MSVC 12.0
* Updated Opus libraries to v1.1.x and Opus-Tools v0.1.9 to latest Git Master (2015-03-26)
* Updated mpg123 decoder to v1.22.0 (2015-02-24), compiled with GCC 4.9.2
* Updated Vorbis encoder to OggEnc v2.87 (2014-07-03), using libvorbis v1.3.4 and aoTuV b6.03_2014
* Updated Vorbis decoder to OggDec v1.10.1 (2015-03-19), using libVorbis v1.3.5
* Updated FLAC encoder/decoder to v1.3.1 (2014-11-26), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.18 (2014-06-30), compiled with GCC 4.9.1
* Updated QAAC add-in (http://sourceforge.net/projects/lamexp/files/Miscellaneous/Add-ins/qaac/) to the latest to QAAC v2.44, including a fix (https://github.com/nu774/qaac/commit/ad1e0ea9daed076531e96cfa3b82f290ba9eeb20) for the --artwork option
* Fixed potential crash in Cue Sheet importer (occurred when all input files were missing)
* Fixed a severe performance bottleneck, especially with a large number of parallel instances
* Fixed a very rare problem that, occasionally, prevented the TEMP folder from being removed
* The limit for the maximum number of parallel instances has been increased to 32
* Experimental support for Windows 10 Technical Preview
* Updated language files (big thank-you to all contributors !!!)

http://fc03.deviantart.net/fs71/f/2011/113/c/5/hoppy_easter_sign_by_mirz123-d3eojnl.gif

[Sparktank]

Thanks for the update, quite busy!

Happy Easter to you too.

[Octo-puss]

Can I get the standalone version like before please?

[Przemek_Sperling]

Thank you very much. Great job!

[LoRd_MuldeR]

Can I get the standalone version like before please?

I assume with "standalone version" you mean a binary that has portable mode (http://lamexp.sourceforge.net/doc/Manual.html#portable-mode) enabled by default ;)

Well, here we go:
http://sourceforge.net/projects/lamexp/files/Miscellaneous/Special%20Builds/LameXP-PORTABLE.2015-04-05.Release-Static.Build-1700.zip/download

[soneca]

Thanks for the new version!

[jpsdr]

Thanks for your work.
I've noticed a minor issue (unless it's wanted or i misunderstand the purpose of display), it probably exists since a long time.
I have an i7@980 with 6 cores with HT.
But, after install, and "Choose based on core" is checked, the cursor is on 4 (when i would expect 6 in that case).
Is it normal ?

[Octo-puss]

I assume with "standalone version" you mean a binary that has portable mode (http://lamexp.sourceforge.net/doc/Manual.html#portable-mode) enabled by default ;)

Well, here we go:
http://sourceforge.net/projects/lamexp/files/Miscellaneous/Special%20Builds/LameXP-PORTABLE.2015-04-05.Release-Static.Build-1700.zip/download
Uh, yes. Thank you. Been a while so I forgot what was it called :D

[LoRd_MuldeR]

But, after install, and "Choose based on core" is checked, the cursor is on 4 (when i would expect 6 in that case).
Is it normal ?

It's perfectly normal. As long as you keep "Choose [...] based on the number of CPU cores" checked, the slider doesn't apply and it can be ignored altogether :)

The slider currently defaults to 4, yes. But that is completely unrelated to the number of parallel threads that will be used if you let the program decide.

Also note that the heuristic, which is used to automatically decide the number of parallel threads (based on the number of CPU's), is not a simple "1:1" mapping.

Looks more like this:
http://i.imgur.com/YnQAvU5.png

[TOM_SK]

Anyone else getting this error on Windows 8?

http://i.imgur.com/6TtrPLW.png

[LoRd_MuldeR]

Anyone else getting this error on Windows 8?

http://i.imgur.com/6TtrPLW.png

Nope, works perfectly fine on my Windows 8.1 machine:
http://i.imgur.com/AqXWCkh.jpg

Is this problem reproducible? If so, what are your system specifications? Does the debug console (http://lamexp.sourceforge.net/doc/Manual.html#options-for-debugging) show any helpful info?

[manolito]

@ TOM_SK

Ha, the guru strikes again...

Just for the fun of it, can you try to change your display color depth from 32bit to 16bit and see what happens?

The reason I ask is that on my machine LameXP only works with 16bit colors, with 32bit colors I get exactly this error.


Cheers
manolito

[LoRd_MuldeR]

Just for the fun of it, can you try to change your display color depth from 32bit to 16bit and see what happens?

That doesn't seem to be possible any longer on Windows 8.

The reason I ask is that on my machine LameXP only works with 16bit colors, with 32bit colors I get exactly this error.

"Exactly this error" doesn't say anything here, though. That's because the unhandeled exception handler will be invoked, well, when the system throws some unexpected exception.

And this can be virtually anything! Like an access violation, a division by zero, an illegal instruction or whatever. We won't know without further details...


Here is a new Debug build, which might provide some insight on what's going on:
http://sourceforge.net/projects/muldersoft/files/LameXP/Testing/LameXP-TEST.2015-04-06.DEBUG.Build-1700.exe/download

Please use the Windows Debugger (WinDbg) for creating a proper stack trace:
https://www.sendspace.com/file/xepka0

[soneca]

Thanks for your work.
I've noticed a minor issue (unless it's wanted or i misunderstand the purpose of display), it probably exists since a long time.
I have an i7@980 with 6 cores with HT.
But, after install, and "Choose based on core" is checked, the cursor is on 4 (when i would expect 6 in that case).
Is it normal ?

Here using the i7 980X got a good difference between the two modes.
Converting 85 songs flac to mp3 VBR/quality level 1/algorithm-better quality.
61 seconds based on core and 50 seconds using 12 cores(HT).
And much faster than version 4.10, seems to have a better use of the instances.:cool:

[manolito]

Minor point about latest version:

The FAQ.html file needs to be updated. For the qaac addon it still links to the deprecated version from January 2014. The Manual.html file has the correct links...


Cheers
manolito

[LoRd_MuldeR]

And much faster than version 4.10, seems to have a better use of the instances.:cool:

Yes, a bug that could cause undesired delays in the creation of new encoder instances has been fixed with this version. This is especially noticeable, if you run a large number of instances in parallel.

http://i.imgbox.com/3G4Zr9xT.png (https://vimeo.com/114437958)


The FAQ.html file needs to be updated. For the qaac addon it still links to the deprecated version from January 2014. The Manual.html file has the correct links...

The old FAQ document has been deprecated, in favor of the new manual. It will be removed in a future version.

(There's also an FAQ section in the new manual file)

[soneca]

A huge difference! ;)

http://s20.postimg.org/mddd89bwt/Lame_xp_4_10.png
http://s20.postimg.org/o6g9wkx3h/Lame_xp_4_11.png

[manolito]

The old FAQ document has been deprecated, in favor of the new manual. It will be removed in a future version.

Does this also mean that the Fraunhofer AAC encoder is no longer supported?


Cheers
manolito


P.S.
A little bit Off-Topic...
The latest SoX downloads 14.4.2 at SourceForge only offer dynamic versions containing dozens of library DLLs. (The previous version 14.4.1 war almost static, only 2 additional DLLs required). Now the current LameXP version contains a patched SoX version 14.4.2 which not only has DynamicAudioNormalizer built in, but it also is absolutely static, no separate DLLs required. Great! Can I use this version to replace SoX in my plugins, or are there any catches?

[LoRd_MuldeR]

Does this also mean that the Fraunhofer AAC encoder is no longer supported?

It's supposed to still work, but haven't used it for a long time. There haven't been any updates either.

Does anybody use that encoder nowadays, given that people generally seems to favor QAAC and given that Winamp (where the encoder DLL was taken from) is gone for good?

The latest SoX downloads 14.4.2 at SourceForge only offer dynamic versions containing dozens of library DLLs. (The previous version 14.4.1 war almost static, only 2 additional DLLs required). Now the current LameXP version contains a patched SoX version 14.4.2 which not only has DynamicAudioNormalizer built in, but it also is absolutely static, no separate DLLs required. Great! Can I use this version to replace SoX in my plugins, or are there any catches?

SoX can be built with a zillion of optional libraries. I guess the "official" Windows binaries have these optional dependencies included, as shared libraries (DLL files).

My binary is kind of a "minimal" build, with all the optional lib's disabled. That's because I don't use SoX for encoding/decoding or for other fancy stuff. If you don't mind about a few missing optional features, there's nothing to worry.

(BTW: Also some of the libraries included with the official SoX binaries are specific to MinGW. My binary is created with MSVC/ICL, and with the static C++ Runtime)

[manolito]

To get Qaac working with LameXP the manual explains that the Apple Application Support must be installed. While this is much better than installing QuickTime or iTunes, it is still a little bulky and it installs a couple of services, and it calls home frequently.

Luckily there is a way to avoid the installation of Apple Application Support, this is how it is done:

7-Zip is required (anyone who has not installed it?)
Download the latest iTunes or QuickTime installer from Apple
Download "MakePortable.zip" from the Qaac project page:
https://sites.google.com/site/qaacpage/cabinet

Put the Apple installer and MakePortable.cmd into the same folder and run Makeportable.cmd.

You will end up with a newly created subfolder "QTFiles". Move this subfolder to your LameXP folder (i.e. make a subfolder below the main LameXP folder).

Of course you still need to copy the files from the Qaac add-on into your LameXP main folder.



Cheers
manolito

[LoRd_MuldeR]

Yeah, I know about this method, but didn't want to make the install instructions more complex than they are already.

Anyway, I added a link to the manual now ;)

[LoRd_MuldeR]

LameXP v4.12 Alpha-4

Changes between v4.11 and v4.12 [unreleased]:
* Added Hungarian translation, contributed by Zityi's Translator Team <zityisoft@gmail.com>
* Added optional support for the libfdk-aac encoder, using the fdkaac front-end by nu774
* Added detection of the 64-Bit version of QAAC encoder, requires 64-Bit Apple Application Support
* Added enhanced file renaming option: Default file extensions can now be overwritten
* Added enhanced file renaming option: Files can now be renamed via the regular expressions engine
* Updated MediaInfo to v0.7.73 (2015-04-09), compiled with ICL 15.0 and MSVC 12.0
* Updated ALAC decoder to refalac v1.47 (2015-02-15), based on reference implementation by Apple
* Fixed potential deadlock in Cue Sheet import dialog when "Browse..." button is clicked
* Fixed function to restore the default Temp folder, if custom Temp folder doesn't exist anymore

[SeeMoreDigital]

Changes between v4.11 and v4.12 [unreleased]:
* Added optional support for the libfdk-aac encoder, using the fdkaac front-end by nu774

Nice one... Out of interest, where can the necessary 'FdkAacEnc encoder binaries' be found?

[manolito]

You have to make the binary yourself using the file fdkaac_autobuild.zip from here:
https://sites.google.com/site/qaacpage/cabinet


Cheers
manolito

[LoRd_MuldeR]

LameXP v4.12 Alpha-6
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2015-05-25/

Changes between v4.11 and v4.12 [unreleased]:
* Added Hungarian translation, contributed by Zityi's Translator Team <zityisoft@gmail.com>
* Added optional support for the libfdk-aac encoder, using the fdkaac front-end by nu774
* Added detection of the 64-Bit version of QAAC encoder, requires 64-Bit Apple Application Support
* Added enhanced file renaming option: Default file extensions can now be overwritten
* Added enhanced file renaming option: Files can now be renamed via the regular expression engine
* Added capability to select multiple files on "Source Files" tab
* Updated MediaInfo to v0.7.73 (2015-04-09), compiled with ICL 15.0 and MSVC 12.0
* Updated ALAC decoder to refalac v1.47 (2015-02-15), based on reference implementation by Apple
* Updated GnuPG to v1.4.19 (2015-02-27), compiled with GCC 4.9.2
* Fixed potential deadlock in Cue Sheet import dialog when "Browse..." button is clicked
* Fixed function to restore the default Temp folder, if custom Temp folder doesn't exist anymore

[Motenai Yoda]

If I'm not wrong qaac doesn't support hev2 profile.
Indeed LameXP don't add any switch.

anyway fdkaac vbr modes are 1-5 but is selectable only up to 4 (5 did has a bug on >64kHz input, but seems it's fixed in 0.1.4 as changelog said "Fix VBR encoding of sample rates over 64 kHz")

any way to add normalization like TruePeak/EBU R128/ITU-R BS.1770?
basically
The stages of processing are:
1 Attenuate: 12.04 dB attenuation
2 4 × over-sampling
3 Low-pass filter
4 Absolute: Absolute value
source: https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-I!!PDF-E.pdf

where
- 1 "The purpose of this step
is to provide headroom for the subsequent signal processing employing integer arithmetic."
- 2 and 3 are a simple resampling to at least 192kHz (fill with 0 then lowpass with a FIR filter)
- 4 as ever get the max peak's abs value. (then add +12.04dB I think)

should can be easely done with sox

[LoRd_MuldeR]

If I'm not wrong qaac doesn't support hev2 profile.
Indeed LameXP don't add any switch.

I think the Apple AAC encoder doesn't support HEv2 profile. So QAAC doesn't. So LameXP doesn't (when using QAAC).

anyway fdkaac vbr modes are 1-5 but is selectable only up to 4 (5 did has a bug on >64kHz input, but seems it's fixed in 0.1.4 as changelog said "Fix VBR encoding of sample rates over 64 kHz")

Should be fixed:
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2015-05-29/LameXP-ALPHA.2015-05-29.Release-Static.Build-1756.exe/download

should can be easely done with sox

Can it be done with a single SoX invocation? If so, what is the exact SoX command-line that performs the required operations?

[Motenai Yoda]

I think the Apple AAC encoder doesn't support HEv2 profile. So QAAC doesn't. So LameXP doesn't (when using QAAC).
but is selectable and doesn't give any prompt/warn nor fallback to HE

Can it be done with a single SoX invocation? If so, what is the exact SoX command-line that performs the required operations?
I will investigate Sir:

ie gain -12.04 rate -v -s 192k gain -n *NormalizationLevel* rate -v -s *OriginalSampleRate* (dither?)

or gain -12.04 upsample *UpsampleFactor* fir *FirCoeff_Table_File* stat (should print some stuff, peak value included)

*/surely neither works but I'm too tired now to quarrel with sox/*

paper saids that UpsampleFactor should give at least 192kHz so ie 4 for 48kHz sources, 2 for 96kHz ones

fir coeffs
0.0017089843750 −0.0291748046875 −0.0189208984375 −0.0083007812500
0.0109863281250 0.0292968750000 0.0330810546875 0.0148925781250
−0.0196533203125 −0.0517578125000 −0.0582275390625 −0.0266113281250
0.0332031250000 0.0891113281250 0.1015625000000 0.0476074218750
−0.0594482421875 −0.1665039062500 −0.2003173828125 −0.1022949218750
0.1373291015625 0.4650878906250 0.7797851562500 0.9721679687500
0.9721679687500 0.7797851562500 0.4650878906250 0.1373291015625
−0.1022949218750 −0.2003173828125 −0.1665039062500 −0.0594482421875
0.0476074218750 0.1015625000000 0.0891113281250 0.0332031250000
−0.0266113281250 −0.0582275390625 −0.0517578125000 −0.0196533203125
0.0148925781250 0.0330810546875 0.0292968750000 0.0109863281250
−0.0083007812500 −0.0189208984375 −0.0291748046875 0.0017089843750

Note fdkaac from jb-alvarado/wiiaboo's media-autobuild_suite can be used too (since today XD)

[LoRd_MuldeR]

but is selectable and doesn't give any prompt/warn nor fallback to HE

Yes, because other AAC encoders supported in LameXP do support HEv2 profile just fine, so the option needs to reflect this.

In theory we could show a warning, if a specific AAC profile is selected, but the current AAC encoder doesn't support it. But I'm not sure we need this extra complexity.

Fallback to HE-AAC is implemented for QAAC already. But this works for CBR/ABR modes modes only, so in VBR mode you always get LC-AAC.

qaac 2.47
Usage: qaac [options] infiles....

--he HE AAC mode (TVBR is not available)


I will investigate Sir:

surely neither works but I'm too tired now to quarrel with sox

Well, it seems somebody has already implemented EBU R128 normalization, based on SoX/FFmpeg:
http://r128gain.sourceforge.net/

Unfortunately this tool requires SoX and FFmpeg as separate libraries. This makes it a bit awkward for integration into LameXP.

[manolito]

R128Gain has been superseded by BS1770Gain which is more universal (but no GUI). The necessary ffmpeg and SoX libraries are stripped down to the absolute minimum (5 DLLs, but still 15 MB).

For integration into LameXP it would probably make more sense to just use a current version of ffmpeg.exe for the EBU detection pass. The following command displays the detected loudness values which can be intercepted. The necessary correction can be done using the SoX library which comes with LameXP.

ffmpeg.exe -nostats -i %1 -filter_complex ebur128 -f null -

Keep in mind that just applying EBU loudness correction does not offer any safeguards against clipping...


Cheers
manolito


//EDIT//
The original R128Gain software allows to use ffmpeg and SoX libraries which are already present on the HDD:

--ffmpeg=<path> Directory of the FFmpeg shared libraries.
--sox=<path> Directory of the SoX shared libraries.
--lame=<path> Directory of the Lame shared libraries.
--magick=<path> Directory of the ImageMagick shared libraries.

[Motenai Yoda]

Even with ffmpeg only,without sox.
btw is -filter_complex "ebur128=peak=true"

I will investigate Sir:
surely neither works but I'm too tired now to quarrel with sox
Well, it seems somebody has already implemented EBU R128 normalization, based on SoX/FFmpeg:
http://r128gain.sourceforge.net/
I was sarcastic.

sox.exe %1 %1_out.wav gain -12.04 rate -v -s 192k gain -n -1 rate -v -s 44100
seems to work, normalizing at -1.0 -> -1.3 (maybe rate with -v -s is overkill)


sox.exe %1 -n gain -12.04 rate -v -s 192k stats
Overall Left Right
DC offset 0.000004 0.000003 0.000004
Min level -0.259104 -0.258960 -0.259104
Max level 0.260178 0.257213 0.260178
Pk lev dB -11.69 -11.74 -11.69
RMS lev dB -24.04 -23.91 -24.17
RMS Pk dB -15.23 -15.23 -15.33
RMS Tr dB -1.#J -209.76 -1.#J
Crest factor - 4.06 4.20
Flat factor 0.00 0.00 0.00
Pk count 2 2 2
Bit-depth 31/32 31/32 31/32
Num samples 73.2M
Length s 381.504
Scale max 1.000000
Window s 0.050

so 12.04 - 11.69 = +0.35 dB

sox.exe %1 -n gain -12.04 upsample 4 fir Ebu_Fir_Coeff.txt stats

Overall Left Right
DC offset 0.000004 0.000003 0.000004
Min level -0.257842 -0.256317 -0.257842
Max level 0.255081 0.254555 0.255081
Pk lev dB -11.77 -11.82 -11.77
RMS lev dB -24.13 -24.00 -24.26
RMS Pk dB -15.32 -15.32 -15.42
RMS Tr dB -1.#J -1.#J -1.#J
Crest factor - 4.06 4.21
Flat factor 0.00 0.00 0.00
Pk count 2 2 2
Bit-depth 31/32 31/32 31/32
Num samples 67.3M
Length s 381.504
Scale max 1.000000
Window s 0.050
12.04 - 11.77 = +0.27 dB (note with upsample factor = 4 it will oversample to 176,4kHz not 192kHz)

ffmpeg ebur128 saids +0.3 dB
(ffmpeg stats saids 0.0 dB)

[LoRd_MuldeR]

R128Gain has been superseded by BS1770Gain which is more universal (but no GUI). The necessary ffmpeg and SoX libraries are stripped down to the absolute minimum (5 DLLs, but still 15 MB).

If we had a binary of BS1770Gain with all the required libs linked in statically, it would be much more useful (and probably a lot smaller).

But it seems they use runtime DLL loading and don't intend a fully static build. At least their Makefile fails with a missing DLL file, when configure was run with "--enable-static" plus "--disable-shared" option.

What is the reason to use FFmpeg anyway? Using FFmpeg to read a WAVE file is like taking a sledgehammer to crack a nut. SoX already supports a wide range of audio formats...


sox.exe %1 %1_out.wav gain -12.04 rate -v -s 192k gain -n -1 rate -v -s 44100
seems to work, normalizing at -1.0 -> -1.3 (maybe rate with -v -s is overkill)

What is this command supposed to do?

If I understand it correctly, all that this does is: First attenuate the audio by -12.04 dB, then upsample to 192 kHz, then apply plain old standard normalization filter (with target level of -1 dBFS) and finally downsample to 44.1 kHz again.


What is the difference to:
sox.exe %1 %1_out.wav gain -n -1

...except for a seemingly pointless up/downsampling roundtrip?

:confused:

[Motenai Yoda]

http://www.indexcom.com/tech/0dBFS+/

u will need ffmpeg to get the peak stats.

ps
sox.exe %1 %1_out.wav gain -12.04 rate -v -s 192k gain -n -1 rate -v -s 44100
≡
gain -12.04 rate -v -s 192k gain -n *NormalizationLevel* rate -v -s *OriginalSampleRate* (dither?)

with simple gain -n -1 sox will normalize taking into account only samples's max abs value
with oversampling it can taking into a more precise waveform representation

anyway it's only a small request, nothing vital

[LoRd_MuldeR]

http://www.indexcom.com/tech/0dBFS+/

u will need ffmpeg to get the peak stats.

I can't follow :rolleyes:

First you suggest using SoX. But when I ask you what your suggested SoX command-line is actually supposed to do – to my understanding it simply applies the plain old standard normalization filter, only combined with a seemingly pointless up-/downsamling rountrip (but maybe I'm missing something?) – you suddenly suggest using FFmpeg. Can you please elaborate on your previous suggestion, before you go on to the next one?

To make it clean again: What we need is a single SoX invocation (command-line) that performs all the required operations. Alternatively, some other CLI tool, which can do the required operations with a single invocation, could be integrated. But only if that tool is 100% stand-alone, i.e. it doesn't introduce any nasty dependencies. Clearly, BS1770Gain (R128GAIN), in its current form, isn't suitable for LameXP integration. Neither is FFmpeg.

[manolito]

What is the reason to use FFmpeg anyway? Using FFmpeg to read a WAVE file is like taking a sledgehammer to crack a nut. SoX already supports a wide range of audio formats...


As I understand it, FFmpeg is not just used to read a WAVE file (or decode other formats), instead it is mainly needed to perform the loudness detection pass as standardized by the ITU or EBU. This detection pass has to determine the "Integrated Loudness" of the source. The second pass done by SoX simply applies the necessary gain to reach the desired output level of -23 LUFS (EBU R128) or -18 LUFS (ReplayGain) or any other desired target loudness.


It looks like Motenai Yoda somehow tries to do the detection pass with SoX. Probably not possible IMO.

And additionally using standard normalization is totally destroying the original purpose of using EBU R128 or ReplayGain.


I have implemented EBU R128 normalization for AVStoDVD, and it works very well, especially as a postprocessor for DynamicAudioNormalizer. The main problem is that there is no clipping protection.

Of course the detection pass could additionally detect the max peak of the source, and the gain value for the second pass could be reduced so that no clipping occurs. But then you would not get uniform loudness over several sources.

The other way to avoid clipping would be to use a brickwall limiter before the second pass to reduce the peaks by the required amount. SoX has a command which applies limiting during the gain adjustment pass, but it is hard to find a setting which avoids clipping and at the same time does not destroy the dynamics.


All this is for AVStoDVD which deals with audio for films. With LameXP which will probably mostly deal with music there would be another design problem. If you convert to a format which supports loudness tagging (MP3, FLAC and others) you will want to just add the necessary tags instead of physically altering the loudness of the target file (which my AVStoDVD plugin does).


Cheers
manolito

[LoRd_MuldeR]

As I understand it, FFmpeg [...] is mainly needed to perform the loudness detection pass as standardized by the ITU or EBU.

I would have assumed that this is what happens inside the BS1770Gain program - or, more specifically, the lib1770 (http://sourceforge.net/projects/r128gain/files/lib1770/0.9/) library.

Ideally, we'd have just a minimalistic CLI front-end to lib1770. Maybe with libsndfile linked in, statically, for reading writing the WAVE files.


It looks like Motenai Yoda somehow tries to do the detection pass with SoX. Probably not possible IMO.

Probably. But even we used SoX only to apply the final gain adjustment (and do the detection pass in FFmpeg separately), we would use the SoX "gain" filter with a fixed delta, not in "normalization" mode.

(And we usually wouldn't need to apply a resampling for doing this)


And additionally using standard normalization is totally destroying the original purpose of using EBU R128 or ReplayGain.

That's what I was thinking too.


I have implemented EBU R128 normalization for AVStoDVD, and it works very well, especially as a postprocessor for DynamicAudioNormalizer. The main problem is that there is no clipping protection.

Of course the detection pass could additionally detect the max peak of the source, and the gain value for the second pass could be reduced so that no clipping occurs. But then you would not get uniform loudness over several sources.

That's always the problem when you want to apply a single constant gain value to the entire file: A single peak in the "loud" section will prevent applying adequate gain in "silent" sections - at least if you want to avoid clipping (or limiting/compression). So a more dynamic approach would be desired. But I think BS.1770 (EBU R128) is not really suitable for a "windowed" approach, as it computes so-called "integrated" loudness over the whole program (i.e. file or track).

[manolito]

I would have assumed that this is what happens inside the BS1770Gain program - or, more specifically, the lib1770 (http://sourceforge.net/projects/r128gain/files/lib1770/0.9/) library.

Ideally, we'd have just a minimalistic CLI front-end to lib1770. Maybe with libsndfile linked in, statically, for reading writing the WAVE files.

You are probably right about the lib1770 library.

About the minimalistic CLI frontend to lib1770 why don't you get in touch with Peter Belkner (he even speaks German... :) ) ?



Probably. But even we used SoX only to apply the final gain adjustment (and do the detection pass in FFmpeg separately), we would use the SoX "gain" filter with a fixed delta, not in "normalization" mode.

(And we usually wouldn't need to apply a resampling for doing this)

Absolutely. Resampling, high pass filtering and other stuff are required for the detection pass, not for the gain adjustment.


That's always the problem when you want to apply a single constant gain value to the entire file: A single peak in the "loud" section will prevent applying adequate gain in "silent" sections - at least if you want to avoid clipping (or limiting/compression). So a more dynamic approach would be desired. But I think BS.1770 (EBU R128) is not really suitable for a "windowed" approach, as it computes so-called "integrated" loudness over the whole program (i.e. file or track).

Absolutely correct (at least if your result has to comply to the EBU R128 standard). No way to avoid a 2-pass process.

AFAIK the FooBar devs implemented a different design for ReplayGain. Their detection pass is much shorter, maybe it even is a "windowed" approach. I am not familiar with FooBar, though...



Cheers
manolito

[Motenai Yoda]

TruePeak/bs.1770 only concern about max peak of the waveform, not the short/medium term or integrate loudness, those are for r128.

also in that cli (first one) normalize on a oversampled waveform, so finds the delta and then normalize according to it (so internally 2 pass), finally downscale-back to 48kHz.
It doesn't calculate the delta and normalize at delta level.

It can also be done finding the TP level, and using sox or anything (even ffmpeg) to apply gain "delta" factor on an un-resampled waveform.

As #1232 this delta can be roughly found even with sox.

ffmpeg reading is somewhat different coz it uses hardcoded pre/post filters that, unlikely deprecated revisions, are no more mentioned in lastest bs.1770 (but lowpass).

anyway ffmpeg oversample at 192k too and it comply to the EBU R128 standard only for 48kHz content.

[LoRd_MuldeR]

LameXP v4.12 Alpha-7

Changes between v4.11 and v4.12 [unreleased]:
* Added Hungarian translation, contributed by Zityi's Translator Team zityisoft@gmail.com
* Added optional support for the libfdk-aac encoder, using the fdkaac front-end by nu774
* Added detection of the 64-Bit version of QAAC encoder, requires 64-Bit Apple Application Support
* Added enhanced file renaming option: Default file extensions can now be overwritten
* Added enhanced file renaming option: Files can now be renamed via the regular expression engine
* Added capability to select multiple files on "Source Files" tab
* Updated MediaInfo to v0.7.74 (2015-05-25), compiled with ICL 15.0 and MSVC 12.0
* Updated ALAC decoder to refalac v1.47 (2015-02-15), based on reference implementation by Apple
* Updated GnuPG to v1.4.19 (2015-02-27), compiled with GCC 4.9.2
* Fixed potential deadlock in Cue Sheet import dialog when "Browse..." button is clicked
* Fixed function to restore the default Temp folder, if custom Temp folder doesn't exist anymore

[LoRd_MuldeR]

LameXP v4.12 Alpha-8

Changes between v4.11 and v4.12 [unreleased]:
* Updated Qt runtime libraries to v4.8.7 Final (2015-05-25), compiled with MSVC 12.0
* Added Hungarian translation, contributed by Zityi's Translator Team zityisoft@gmail.com
* Added optional support for the libfdk-aac encoder, using the fdkaac front-end by nu774
* Added detection of the 64-Bit version of QAAC encoder, requires 64-Bit Apple Application Support
* Added enhanced file renaming option: Default file extensions can now be overwritten
* Added enhanced file renaming option: Files can now be renamed via the regular expression engine
* Added capability to select multiple files on "Source Files" tab
* Updated MediaInfo to v0.7.74 (2015-05-25), compiled with ICL 15.0 and MSVC 12.0
* Updated ALAC decoder to refalac v1.47 (2015-02-15), based on reference implementation by Apple
* Updated GnuPG to v1.4.19 (2015-02-27), compiled with GCC 4.9.2
* Fixed potential deadlock in Cue Sheet import dialog when "Browse..." button is clicked
* Fixed function to restore the default Temp folder, if custom Temp folder doesn't exist anymore

[Randy31416]

On my system (Win 7 64-bit) the output filenames do not retain the same name as the input filenames even though I have left the rename-output-files option unchecked. In particular, my input filenames often have more than one space character in a row to improve formatting when large aggregates of files are listed by other software, and LameXp renames them by squeezing all such cases down to a single space only. Is there any way to get the program to preserve the filename? Other than that (and it is a nit), what a great program, and thanks. The parallel processing of encoding (4-way for me) is a boon.

[SeeMoreDigital]

On my system (Win 7 64-bit) the output filenames do not retain the same name as the input filenames even though I have left the rename-output-files option unchecked.

Hi and welcome to the forum,

Can you give us some before and after examples?


Cheers

[LoRd_MuldeR]

File name strings generally are simplified() (http://doc.qt.io/qt-4.8/qstring.html#simplified), in order to removed typographical "mistakes", such as multiple space characters in a row.

[Randy31416]

File name strings generally are simplified() (http://doc.qt.io/qt-4.8/qstring.html#simplified), in order to removed typographical "mistakes", such as multiple space characters in a row.
So there is no way within LameXP to leave the filenames intact? (I do note, and thank you for, the quotes around "mistakes", as I infer that you recognize that in my case the extra spaces are not mistakes. The whole overly-precise formatting of titles, on the other hand . . . .)

I'd prefer it if the names were untouched. However, as a workaround, I wrote AutoHotkey scripts that I call before and after compression. The before script turns all blanks into @s (a character that never appears in my titles); the after script turns all @s into blanks. The result has the form I want, but I just have to remember to invoke the scripts.

[LoRd_MuldeR]

So there is no way within LameXP to leave the filenames intact? (I do note, and thank you for, the quotes around "mistakes", as I infer that you recognize that in my case the extra spaces are not mistakes. The whole overly-precise formatting of titles, on the other hand . . . .)

I'd prefer it if the names were untouched. However, as a workaround, I wrote AutoHotkey scripts that I call before and after compression. The before script turns all blanks into @s (a character that never appears in my titles); the after script turns all @s into blanks. The result has the form I want, but I just have to remember to invoke the scripts.

Okay, I have relaxed the clean_file_name() (https://github.com/lordmulder/MUtilities/blob/master/include/MUtils/Global.h#L98) function a bit, so that it uses trimmed() instead of simplified(), retaining spaces in the middle of a file name.

You can try this test build:
https://www.sendspace.com/file/fnjqaj

[LoRd_MuldeR]

LameXP v4.12 Beta-1

Changes between v4.11 and v4.12 [unreleased]:
* Updated Qt runtime libraries to v4.8.7 Final (2015-05-25), compiled with MSVC 12.0
* Added Hungarian translation, contributed by Zityi's Translator Team <zityisoft@gmail.com>
* Added optional support for the libfdk-aac encoder, using the fdkaac front-end by nu774
* Added detection of the 64-Bit version of QAAC encoder, requires 64-Bit Apple Application Support
* Added enhanced file renaming option: Default file extensions can now be overwritten
* Added enhanced file renaming option: Files can now be renamed via the regular expression engine
* Added capability to select multiple files on "Source Files" tab
* Updated MediaInfo to v0.7.74 (2015-05-25), compiled with ICL 15.0 and MSVC 12.0
* Updated mpg123 decoder to v1.22.2 (2015-05-24), compiled with GCC 5.1.0
* Updated ALAC decoder to refalac v1.47 (2015-02-15), based on reference implementation by Apple
* Updated GnuPG to v1.4.19 (2015-02-27), compiled with GCC 4.9.2
* Fixed potential deadlock in Cue Sheet import dialog when "Browse..." button is clicked
* Fixed function to restore the default Temp folder, if custom Temp folder doesn't exist anymore

[lethedoom]

SourceForge website mystery.

http://sourceforge.net/projects/lamexp/files/Snapshots%20(BETA)/

Today I find recent history wiped out:

Looking for the latest version? Download LameXP.2014-06-23.Release-Static.Build-1558.exe
Home / Snapshots (BETA)
Name Modified Size Downloads / Week Status
Parent folder
Totals: 182 Items
2015-03-28 2015-03-28

Back to the present today 7.18.2015.

[LoRd_MuldeR]

SourceForge file release system can be a bit funky at times...

See also:
http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration/

[SeeMoreDigital]

This is a new one: -

http://i59.tinypic.com/t6t79e.png

Is it anything I may have done?

Currently running Windows 10 Pro (64-bit) Build: 10240