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

[manolito]

After the HydrogenAudio listening test determined that fhgaac was superior to Nero AAC I decided to do some tests:

1. Speed is pretty much the same. FHGAAC is a tad slower than Nero (17 min vs. 16 min), but this is hardly significant.

2. Since FHG does not support ABR (and CBR is not really desirable), quality mode looks like the optimal mode to do a comparison. But this is not so easy:

Nero has a quality scale from 0.00 to 1.00. FHG uses VBR presets in the range of 1 to 5. LameXP only has a slider for the Nero style quality settings, so it somehow maps the Nero settings to the FHG settings.

In my first test I used a quality setting of 0.30 (which roughly corresponds to an average bitrate of 96 kbp/s). For Nero I got a file size of 67.2 MB, for FHG the file was much smaller (49.1 MB). The 0.30 quality setting was mapped to FHG VBR 2.

The next encode with FHG was done with a quality setting of 0.40 which corresponded to a FHG setting of VBR 3. This time the file size was almost identical to the encode done with Nero using a quality setting of 0.30.


I do not have the means to test the quality of the encoded files, my audio hardware is just too shabby. All encoded files sounded pretty much identical to me. But it looks like the mapping of the Nero quality settings to the FHG settings is not perfect yet.


Another hint:
If you want to use the FHG encoder but you do not care for WinAmp, you can extract the necessary files from the installer executable without actually installing WinAmp. Download the WinAmp installer, open it with 7zip and extract the required files.


Cheers
manolito

[LoRd_MuldeR]

Nero has a quality scale from 0.00 to 1.00. FHG uses VBR presets in the range of 1 to 5. LameXP only has a slider for the Nero style quality settings, so it somehow maps the Nero settings to the FHG settings. But it looks like the mapping of the Nero quality settings to the FHG settings is not perfect yet.

I am using a mapping that will map 0.00 to 1 and 1.00 to 5. The values between 0.00 and 1.00 are mapped to values between 1 and 5 in a linear fashion.

As the quality parameter of the FHG encoder only accepts integers, the values have to be rounded. That makes the mapping kind of coarse-grained...

If you want to use the FHG encoder but you do not care for WinAmp, you can extract the necessary files from the installer executable without actually installing WinAmp. Download the WinAmp installer, open it with 7zip and extract the required files.

I know. But I don't think it would be very "fair" to tell people to extract the encoder plugin without actually installing Winamp ;)

[manolito]

While testing the fhgaac encoder I stumbled upon a severe bug which probably has been there for quite a while:

After converting a 6-ch AC3 to a 6-ch AAC I noticed that the volume of the encoded file was way lower than the volume of the original AC3. Then I did the same encode using Nero, but the volume was still way too low. So I figured that this was a AAC issue, and I thought I might get better results using LameXP's normalize feature.

But it turned out that this approach did not work at all. SoX seemed to do its thing normally, but afterwards the encode stopped immediately. No matter if Nero or FHG was chosen as the encoder. Looks like the SoX output is not usable for ther AAC encoders. Here is the log:
LameXP v4.03 (Build #676), compiled on 2011-08-27 at 16:14:23

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

E:/DOKUME~1/Achim/LOKALE~1/Temp/1ca6b065a50346d48d45cb45e7cb39e8/tool_valdec.exe I:\test.ac3 -w I:\\bc36e19738db4fdf932efd5a9a240637.wav

Opening audio output PCM16 3/2.1 (5.1) 48000...
---------------------------------------
Frames/errors: 166277/0
System time: 766202ms
Process time: 582247ms
Approx. 10.94% realtime CPU usage

Exited with code: 0x0000

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

E:/DOKUME~1/Achim/LOKALE~1/Temp/1ca6b065a50346d48d45cb45e7cb39e8/tool_sox.exe -V3 -S --temp . I:\\bc36e19738db4fdf932efd5a9a240637.wav I:\\6b54e1c909f1409da8eab7f2ef915619.wav gain -n -0.50

E:\DOKUME~1\Achim\LOKALE~1\Temp\1ca6b065a50346d48d45cb45e7cb39e8\tool_sox.exe: SoX v14.3.2
E:\DOKUME~1\Achim\LOKALE~1\Temp\1ca6b065a50346d48d45cb45e7cb39e8\tool_sox.exe INFO formats: detected file format type `wav'
E:\DOKUME~1\Achim\LOKALE~1\Temp\1ca6b065a50346d48d45cb45e7cb39e8\tool_sox.exe INFO wav: EXTENSIBLE
Input File : 'I:\\bc36e19738db4fdf932efd5a9a240637.wav'
Channels : 6
Sample Rate : 48000
Precision : 16-bit
Duration : 01:28:40.45 = 255381504 samples ~ 399034 CDDA sectors
File Size : 42949672.19G
Bit Rate : 42949672.842949672.19G
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
E:\DOKUME~1\Achim\LOKALE~1\Temp\1ca6b065a50346d48d45cb45e7cb39e8\tool_sox.exe INFO sox: Overwriting `I:\\6b54e1c909f1409da8eab7f2ef915619.wav'
Output File : 'I:\\6b54e1c909f1409da8eab7f2ef915619.wav'
Channels : 6
Sample Rate : 48000
Precision : 16-bit
Duration : 01:28:40.45 = 255381504 samples ~ 399034 CDDA sectors
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
Comment : 'Processed by SoX'
E:\DOKUME~1\Achim\LOKALE~1\Temp\1ca6b065a50346d48d45cb45e7cb39e8\tool_sox.exe INFO sox: effects chain: input 48000Hz 6 channels
E:\DOKUME~1\Achim\LOKALE~1\Temp\1ca6b065a50346d48d45cb45e7cb39e8\tool_sox.exe INFO sox: effects chain: gain 48000Hz 6 channels
E:\DOKUME~1\Achim\LOKALE~1\Temp\1ca6b065a50346d48d45cb45e7cb39e8\tool_sox.exe INFO sox: effects chain: dither 48000Hz 6 channels
E:\DOKUME~1\Achim\LOKALE~1\Temp\1ca6b065a50346d48d45cb45e7cb39e8\tool_sox.exe INFO sox: effects chain: output 48000Hz 6 channels
Done.

Exited with code: 0x0000

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

E:/Programme/LameXP/fhgaacenc.exe --vbr 3 --dll E:/Programme/LameXP/enc_fhgaac.dll I:\\6b54e1c909f1409da8eab7f2ef915619.wav I:\\test.mp4

fhgaacenc version 20110822 by tmkk
E:\Programme\LameXP\enc_fhgaac.dll

Exited with code: 0x0000


The log does not indicate any problems, but the resulting AAC file had a length of 64 ms. Using the Nero AAC encoder made no difference, so I tend to assume that SoX cannot normalize multichannel WAV files. What do you think?


Cheers
manolito

[mike20021969]

Another hint:
If you want to use the FHG encoder but you do not care for WinAmp, you can extract the necessary files from the installer executable without actually installing WinAmp. Download the WinAmp installer, open it with 7zip and extract the required files.

I download Winamp from winamp.com. I extracted all the files with 7Zip, I couldn't find anything with an FHG reference. The were lots of folders and dll's. What is the file name to search/look for?

[LoRd_MuldeR]

I download Winamp from winamp.com. I extracted all the files with 7Zip, I couldn't find anything with an FHG reference. The were lots of folders and dll's. What is the file name to search/look for?

Please follow the instructions included with the 'FHG AAC Encoder Add-in' package:
http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0

@manolito
The reason why the audio converted from the AC-3 source appears to have a lower volume is because AC-3 has much bigger dynamic range.
Also I can confirm that there is a problem with the normalization filter. It's not only the AAC encoder. The same issue occurs with OggEnc, for example.
I will have to investigate what is going wrong here. But I will be away for the next few days, so please be patient...

[Motenai Yoda]

err.. adding concentric folders still don't work?

[LoRd_MuldeR]

Am I supposed to know what a "concentric" folder is? :confused:

[manolito]

RE normalization filter:

This has nothing to do with the decoder or encoder which LameXP uses. It is solely a SoX issue. And the problem was already present in V. 4.02 final.

For a test just try to convert a 6ch WAV (does not matter if it is in the Extensible Format or not) to a normalized 6ch WAV. Fails...


Cheers
manolito

[LoRd_MuldeR]

RE normalization filter:

This has nothing to do with the decoder or encoder which LameXP uses. It is solely a SoX issue. And the problem was already present in V. 4.02 final.

For a test just try to convert a 6ch WAV (does not matter if it is in the Extensible Format or not) to a normalized 6ch WAV. Fails...


Cheers
manolito

:scared:

Can this be reproduced with the "official" SoX binaries for Win32?

[Motenai Yoda]

Am I supposed to know what a "concentric" folder is? :confused:

in a simple way "one inside another" but I think "recursive" can best be understood by a dev.

ie
a folder "Micky Maus"
a folder "Goofy" into "Micky Maus"
an mp3 into "Goofy"

re normalization filter
there is an WaveGain(S) too
This is a special version of WaveGain that is designed to be used to apply ReplayGain to
a number of mono wave files that comprise the individual channels within a multi-channel
audio stream. For example, the 6 mono wave files that would comprise a 5.1 audio stream.

Processing regards the mono wave files as an album, but applies the gain that was computed
for the single loudest track to all of the tracks, There is a command line option, '-m',
that will cause the program to pause following the analysis phase to allow the user to
enter a dB adjustment that will be added to the value computed by the ReplayGain algorithm.
It is the user's responsibility to ensure that clipping will not result from the value
entered.

You may find other uses for this version. Input is not limited to mono files, but the style of processing will necessarily limit where it may be appropriate to use this.

edit: when "save output files to the same location where the input file is located" but "prepend relative source file path to output file" is still checked (even if greyed), it works right?

[LoRd_MuldeR]

in a simple way "one inside another" but I think "recursive" can best be understood by a dev.

There is an option to add a folder in a recursive way. So what exactly is the problem?

(Seems to work as expected for me)

when "save output files to the same location where the input file is located" but "prepend relative source file path to output file" is still checked (even if greyed), it works right?

The "prepend relative source file path to output file" option does not apply, if "save output files to the same location where the input file is located" is enabled.

[Motenai Yoda]

1- ok but I would expect it was the default method for drag'n'drop
2- look http://www.youtube.com/watch?v=MwyXFIObdug

[LoRd_MuldeR]

ok but I would expect it was the default method for drag'n'drop

Nope, when folders are added via drag&drop it is not done in a recursive way by default.

It's implemented that way, because adding a folder recursively might add a HUGE number files which can take a very long time.

Maybe the default behavior can be changed in a way that will trigger "recursive" mode when a folder that only contains sub-folders (but no files) is dropped.

(I want to avoid adding yet another option for this)

[manolito]

:scared:

Can this be reproduced with the "official" SoX binaries for Win32?

Unfortunately yes...:eek:

I tried with the current version of SoX (14.3.2), but it behaves exactly the same as the built-in version.


Cheers
manolito

[LoRd_MuldeR]

Thx for the info. At least it's not a build issue then ;)

[b66pak]

also broken with 14.3.1 or 14.3.0...
_

[LoRd_MuldeR]

This evening I did some more tests: SoX' gain filter doesn't fail with all multi-channel sources. And it only fails on some when the "-n" option is used :confused:

Anyway, if I also add the "-e" or "-b" option that seems to fix the issue. At least for my samples that failed before. Consequently LameXP will now use "-ne" instead of "-n" only.

Hopefully it works with your sample too. A new build is available via auto-update...

[manolito]

Yes, this fixes it...:thanks:

It adds a little to the encoding time, but I could not break it using all kinds of multichannel input files.

I still find it hard to explain why omitting the -e or -b option causes SoX to completely screw up the conversion. Strange...:confused:


Anyway, it works now, thanks again.


Cheers
manolito

[b66pak]

This evening I did some more tests: SoX' gain filter doesn't fail with all multi-channel sources. And it only fails on some when the "-n" option is used :confused:

Anyway, if I also add the "-e" or "-b" option that seems to fix the issue. At least for my samples that failed before. Consequently LameXP will now use "-ne" instead of "-n" only.

Hopefully it works with your sample too. A new build is available via auto-update...

this have to be a temporary solution! because -ne is not even close to -n...

-ne will rise the loudness of the central channel if its peak is lower than the side channels or will rise the loudness of the side channels if its peaks is lower than the central channel...

in other words the some level of DRC will be applied...
_

[LoRd_MuldeR]

this have to be a temporary solution!

As I am not a SoX developer, this is not in my hands, unfortunately.

(And nope, I'm not currently planning to add yet another tool to LameXP for normalization)

because -ne is not even close to -n...

-ne will rise the loudness of the central channel if its peak is lower than the side channels or will rise the loudness of the side channels if its peaks is lower than the central channel...

I am aware that "-ne" works slightly different.

Anyway, generally I would assume that all channels had been recorded at the same levels. And if not, that's probably unintentionally.

So their peaks should be at the same volume too!

A channel would only be "amplified" more than the others, if there is not a single peak in that channel for the whole duration of the audio...

in other words the some level of DRC will be applied...

Might be applied.

[manolito]

Just a thought:
Have you tried to use norm instead of gain -n?

Cheers
manolito

[LoRd_MuldeR]

The global "--norm" option basically is a shortcut for inserting the "gain -n" filter. Also the "norm" filter is nothing but an alias for "gain −n".

And yes, I tried it, just to be sure. But same effect ;)

[LoRd_MuldeR]

LameXP v4.03 Beta-2:
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2011-09-17/

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined naming pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this (http://forum.doom9.org/showthread.php?t=140273) thread for details) and removed all remnants of "old" decoder
* Added optional support for the FHG AAC Encoder included with Winamp 5.62 (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added a menu for bookmarking "favorite" output folders to the "output folder" tab
* Updated Qt runtime libraries to v4.8.0 Beta-1 (2011-07-19), compiled with MSVC 10.0
* Updated MediaInfo to v0.7.49 (2011-09-09), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed Cue Sheet import for tracks with certain characters in the title
* Fixed a problem with the "normalization" filter that sometimes caused the resulting file to be empty
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)
* Restored Windows 2000 support with Visual Studio 2010 builds (this is experimental!)
* The "Open File(s)" and "Open Folder" dialogs will now remember the most recent directory
* Miscellaneous bugfixes

Build #687 reverted NSIS to v2.46.1, because NSIS v2.46.2 broke Win2k support. Apart from that, build #687 is identical to build build #686.

[b66pak]

here (https://neon1.net/prog/normalizer.html) is the source code under GNU General Public License for a very fast normalizer...it has support only for 8/16bit simple header wavs up to 4gb...
_

[LoRd_MuldeR]

LameXP running on Windows 8:
http://img841.imageshack.us/img841/2341/lamexpwin8.jpg

Unfortunately it seems that some of the tools, including MediaInfo, will crash right away on Windows 8. Bummer! :(

Seems like only the 64-Bit tools will crash. And yes, I'm using the x64 edition of Win8.

It appears that MPRESS causes the issue. The original 64-Bit binary works fine, while the MPRESS-compressed one crashes right away.

As a temporary workaround you can use "--force-cpu-no-64bit" with the latest build in order to make LameXP work on Win8 64-Bit.

[MajorX]

Nice GUI. :)
Is LameXP support audio encoding from video file like*.mkv or *.avi ? If not is it possible to add it in LameXP ?

[LoRd_MuldeR]

Nice GUI. :)
Is LameXP support audio encoding from video file like*.mkv or *.avi?

Nope. But Avisynth-input (audio only) is supported. So you can encode the audio from your video files that way...

Use a simple script, such as:
FFAudioSource("C:\Some Path\Input.mkv")

If not is it possible to add it in LameXP ?

Possible, maybe. We would need to integrate a tool that can split the video file and "extract" the audio stream (e.g. MKVExtract for MKV files) for further processing.

But this additional "splitting" step it doesn't fit into the current design of the software. So this would require bigger changes in the code...

[LoRd_MuldeR]

LameXP v4.03 Beta-3:

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined naming pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this (http://forum.doom9.org/showthread.php?t=140273) thread for details) and removed all remnants of "old" decoder
* Added optional support for the FHG AAC Encoder included with Winamp 5.62 (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added a menu for bookmarking "favorite" output folders to the "output folder" tab
* Updated Qt runtime libraries to v4.8.0 Beta-1 (2011-07-19), compiled with MSVC 10.0
* Updated MediaInfo to v0.7.49 (2011-09-09), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed Cue Sheet import for tracks with certain characters in the title
* Fixed a problem with the "normalization" filter that sometimes caused the resulting file to be empty
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)
* Restored Windows 2000 support with Visual Studio 2010 builds (this is experimental!)
* The "Open File(s)" and "Open Folder" dialogs will now remember the most recent directory
* Miscellaneous bugfixes

[manolito]

Just noticed an unnecessary annoyance with the SoX "-ne" parameter. Whenever this parameter is used, SoX switches to 2-pass mode which of course doubles the filtering time.

While this is probably unavoidable for multichannel sources, it is complete nonsense to do 2 passes for stereo sources. SoX by itself is not smart enough to switch from "-ne" to just "-n" and does 2 passes on stereo sources which is a big waste of time.

Could you add some code to LameXP to use "-ne" conditionally only if the source has more than 2 channels?


Cheers
manolito

[LoRd_MuldeR]

Well, all the reason why we switched from "-n" to "-ne" is because "-n" is buggy. So, unfortunately, I think we can not switch back (now).

(Also, to my understanding, normalization always requires two passes. That's because the maximum peak in the file needs to be determined first, before the actual processing can start. Normalizing only within a local window would effectively "compress" the dynamics. IMHO that's not "normalization" any more)

[manolito]

Well, all the reason why we switched from "-n" to "-ne" is because "-n" is buggy. So, unfortunately, I think we can not switch back (now).
Did you ever encounter any problems with the "-n" parameter for stereo files? I certainly didn't.

(Also, to my understanding, normalization always requires two passes. That's because the maximum peak in the file needs to be determined first, before the actual processing can start. Normalizing only within a local window would effectively "compress" the dynamics. IMHO that's not "normalization" any more)
Alright, point taken, but then the "-ne" paramter invokes a third pass...:)
How else would you explain the performance hit when using "-ne" compared to just "-n" for stereo sources? I just did a couple of tests, and the results are reproduceable.

Source: 2-ch WAV 1.4 GB
Convert 2-ch WAV to normalized 2-ch WAV
Commandline: SoX.exe infile outfile gain -n(e) -0.50

Execution time for "-ne": 16min 20sec
Execution time for "-n": 12min 40sec

To make things worse, the resulting normalized files are NOT identical (which they should be).

So I would still lobby for using "-ne" only for multichannel sources...:p


Cheers
manolito

[LoRd_MuldeR]

Did you ever encounter any problems with the "-n" parameter for stereo files? I certainly didn't

I did not encounter any problems with "-n" and Stereo files either. But that's probably just by chance :confused:

To make things worse, the resulting normalized files are NOT identical (which they should be).

Well, "-ne" works slightly different from "-n". As far as I understood:

The latter will normalize all samples in all channels by the same factor, thus it is limited by the loudest sample in the loudest channel.

At the same time the former will normalize all samples in a channel by the the same factor, but may choose a different factor for each channel.

Consequently it is expected to get different results with "-ne", iff the peak values differ between your channels...

[manolito]

At the same time the former will normalize all samples in a channel by the the same factor, but may choose a different factor for each channel.

From the SoX manual:
Given the −e option, the levels of the audio channels of a multi-channel file are ‘equalised’, i.e.
gain is applied to all channels other than that with the highest peak level, such that all channels
attain the same peak level

The question is if the SoX guys regard a stereo file as "multi-channel". If they do then the "-ne" parameter will inevitably change the stereo balance of the source which is REAL BAD. Makes it unusable for stereo files.

Maybe the "-nb" option would be more suitable for stereo sources because it uses RMS values instead of peaks. This will result in a file with an even stereo balance (both channels have the same RMS value). This is often quite desirable, but probably not always...


Cheers
manolito

[LoRd_MuldeR]

If they do then the "-ne" parameter will inevitably change the stereo balance of the source which is REAL BAD. Makes it unusable for stereo files.

It would do so, if the Stereo channels have different peak levels.

And I think, except for very rare cases, the peak levels of the channels of a Stereo recording should be identical (and should be equalized, if they differ).

[b66pak]

no they are not...from my experience it is always a 0.5 to 1 db between left and right channels...

for 5.1 is even worse: center vs left+right front is 3-4 db and center vs left+right side/back is 4-8db...
_

[manolito]

And I think, except for very rare cases, the peak levels of the channels of a Stereo recording should be identical (and should be equalized, if they differ).
This is not true at all (maybe for classical recordings). Most modern instruments (i.e. synthesizers, electric guitar and bass, percussion) generate high peaks which do not contribute to the perceived loudness of the track. Unless brutal compression or brickwall limiting is used to achieve maximum loudness, the peak levels for the 2 channels will amost never be identical while the acoustic balance is perfect.

I have a background as a recording engineer (many years ago in the good old analog times), but if you do not believe me, test it for yourself:

Take some of your favorite audio records (good quality please, maybe jazz), load them into WaveLab and do a "Global Analysis". This will give you the peak levels plus the RMS levels for each track (separately for each channel).


Cheers
manolito

[LoRd_MuldeR]

Yes, I know that "sample value" and "perceived loudness" aren't the same at all and that RMS is a better loudness indicator. And I would never suggest to use the sample value to judge the loudness of a track. But we are not talking about average values here. Not even about average values for small segments. It's all about peak (maximum) values for complete tracks. Sure there are "high peaks which do not contribute to the perceived loudness of the track". And the number of such peaks may be very different between the channels. But each track/channel contains millions of individual sample values. So usually there is at least one (and one is sufficient for maximum calculation) of these "high" peaks in each channel. Actually my finding is that the maximum sample value generally is identical (or pretty close) between both channels of a Stereo recording, while both, the average and especially the maximum, RMS can differ significantly between the channels...

Example:
http://img834.imageshack.us/img834/3149/maxpeakvalue.png

[b66pak]

its time for some examples...


stereo (normalized after downmixing from 5.1)

[20:43:30.796] Commandline: sox -V0 -t raw -L -s -b 16 -c 6 -r 48000 - -n remix -m 1v0.3694,3v0.2612,5v0.3694 2v0.3694,3v0.2612,6v0.3694 gain -n stats

[20:48:21.750] Overall Left Right

[20:48:21.750] DC offset -0.000005 -0.000005 -0.000005
[20:48:21.750] Min level -0.934752 -0.934752 -0.776695
[20:48:21.750] Max level 1.000000 1.000000 0.872530

[20:48:21.750] Pk lev dB 0.00 0.00 -1.18

[20:48:21.750] RMS lev dB -26.14 -26.14 -26.15
[20:48:21.750] RMS Pk dB -10.96 -11.04 -10.96
[20:48:21.750] RMS Tr dB -1.#J -1.#J -1.#J
[20:48:21.750] Crest factor - 20.28 17.70
[20:48:21.750] Flat factor 0.00 0.00 0.00
[20:48:21.750] Pk count 2 2 2
[20:48:21.750] Bit-depth 32/32 32/32 32/32
[20:48:21.750] Num samples 124M
[20:48:21.750] Length s 2582.272
[20:48:21.750] Scale max 1.000000
[20:48:21.750] Window s 0.050
[20:48:21.765] Process terminated with code: 0
[20:48:21.765] Execution took 4 minute(s), 50 second(s).



[20:48:22.406] Commandline: sox -V0 -t raw -L -s -b 16 -c 6 -r 48000 - -n remix -m 1v0.3694,3v0.2612,5v0.3694 2v0.3694,3v0.2612,6v0.3694 gain -n stats

[20:51:12.343] Overall Left Right

[20:51:12.343] DC offset -0.000002 -0.000001 -0.000002
[20:51:12.343] Min level -1.000000 -1.000000 -0.930617
[20:51:12.343] Max level 0.958940 0.958940 0.937415

[20:51:12.343] Pk lev dB 0.00 0.00 -0.56

[20:51:12.343] RMS lev dB -25.23 -25.23 -25.23
[20:51:12.343] RMS Pk dB -9.66 -10.45 -9.66
[20:51:12.343] RMS Tr dB -1.#J -1.#J -1.#J
[20:51:12.343] Crest factor - 18.27 17.11
[20:51:12.343] Flat factor 0.00 0.00 0.00
[20:51:12.343] Pk count 2 2 2
[20:51:12.343] Bit-depth 32/32 32/32 32/32
[20:51:12.343] Num samples 126M
[20:51:12.343] Length s 2631.840
[20:51:12.343] Scale max 1.000000
[20:51:12.343] Window s 0.050
[20:51:12.343] Process terminated with code: 0
[20:51:12.343] Execution took 2 minute(s), 49 second(s).



[20:51:12.953] Commandline: sox -V0 -t raw -L -s -b 16 -c 6 -r 48000 - -n remix -m 1v0.3694,3v0.2612,5v0.3694 2v0.3694,3v0.2612,6v0.3694 gain -n stats

[20:55:57.062] Overall Left Right

[20:55:57.062] DC offset -0.000003 -0.000002 -0.000003
[20:55:57.062] Min level -0.966295 -0.940450 -0.966295
[20:55:57.062] Max level 1.000000 0.951579 1.000000

[20:55:57.062] Pk lev dB 0.00 -0.43 0.00

[20:55:57.062] RMS lev dB -24.49 -24.46 -24.52
[20:55:57.062] RMS Pk dB -8.03 -8.33 -8.03
[20:55:57.062] RMS Tr dB -133.10 -132.31 -133.10
[20:55:57.062] Crest factor - 15.90 16.82
[20:55:57.062] Flat factor 0.00 0.00 0.00
[20:55:57.062] Pk count 2 2 2
[20:55:57.062] Bit-depth 32/32 32/32 32/32
[20:55:57.062] Num samples 125M
[20:55:57.062] Length s 2595.808
[20:55:57.062] Scale max 1.000000
[20:55:57.062] Window s 0.050
[20:55:57.093] Process terminated with code: 0
[20:55:57.093] Execution took 4 minute(s), 43 second(s).



[20:55:57.640] Commandline: sox -V0 -t raw -L -s -b 16 -c 6 -r 48000 - -n remix -m 1v0.3694,3v0.2612,5v0.3694 2v0.3694,3v0.2612,6v0.3694 gain -n stats

[20:58:52.781] Overall Left Right

[20:58:52.781] DC offset -0.000003 -0.000002 -0.000003
[20:58:52.781] Min level -0.983251 -0.983251 -0.936560
[20:58:52.781] Max level 1.000000 1.000000 0.970447

[20:58:52.781] Pk lev dB 0.00 0.00 -0.26

[20:58:52.781] RMS lev dB -27.89 -27.96 -27.82
[20:58:52.781] RMS Pk dB -10.44 -10.44 -11.09
[20:58:52.781] RMS Tr dB -98.63 -98.63 -98.42
[20:58:52.781] Crest factor - 24.99 23.88
[20:58:52.781] Flat factor 0.00 0.00 0.00
[20:58:52.781] Pk count 2 2 2
[20:58:52.781] Bit-depth 32/32 32/32 32/32
[20:58:52.781] Num samples 124M
[20:58:52.781] Length s 2593.312
[20:58:52.781] Scale max 1.000000
[20:58:52.781] Window s 0.050
[20:58:52.781] Process terminated with code: 0
[20:58:52.781] Execution took 2 minute(s), 54 second(s).


original 5.1

[20:59:52.140] Commandline: sox -V0 -t raw -L -s -b 16 -c 6 -r 48000 - -n stats

[21:01:40.687] Overall Ch1 Ch2 Ch3 Ch4 Ch5 Ch6

[21:01:40.687] DC offset -0.000003 -0.000002 -0.000002 -0.000003 -0.000001 -0.000001 -0.000000
[21:01:40.687] Min level -0.464905 -0.464905 -0.443695 -0.464386 -0.321808 -0.427521 -0.333832
[21:01:40.687] Max level 0.501587 0.464935 0.481415 0.501587 0.349060 0.424225 0.382660


[21:01:40.687] Pk lev dB -5.99 -6.65 -6.35 -5.99 -9.14 -7.38 -8.34

0.00 -0.66 -0.36 0.00 -3.15 -1.39 -2.35 < this will be after normalizing


[21:01:40.687] RMS lev dB -32.58 -31.85 -31.59 -27.83 -39.44 -39.40 -40.73
[21:01:40.687] RMS Pk dB -12.62 -12.83 -12.62 -15.78 -14.06 -13.20 -19.63
[21:01:40.687] RMS Tr dB -1.#J -1.#J -1.#J -1.#J -1.#J -1.#J -1.#J
[21:01:40.687] Crest factor - 18.19 18.28 12.35 32.72 39.88 41.64
[21:01:40.687] Flat factor 12.84 0.00 0.00 0.00 17.08 4.44 0.00
[21:01:40.687] Pk count 4.33 2 3 2 14 3 2
[21:01:40.687] Bit-depth 15/16 15/16 15/16 15/16 15/16 15/16 15/16
[21:01:40.687] Num samples 124M
[21:01:40.687] Length s 2582.272
[21:01:40.687] Scale max 1.000000
[21:01:40.687] Window s 0.050
[21:01:40.687] Process terminated with code: 0
[21:01:40.687] Execution took 1 minute(s), 48 second(s).



[21:01:40.781] Commandline: sox -V0 -t raw -L -s -b 16 -c 6 -r 48000 - -n stats

[21:03:28.468] Overall Ch1 Ch2 Ch3 Ch4 Ch5 Ch6

[21:03:28.468] DC offset -0.000001 0.000000 -0.000001 -0.000000 -0.000000 -0.000000 -0.000000
[21:03:28.468] Min level -0.608521 -0.398529 -0.406006 -0.608521 -0.022552 -0.063690 -0.074982
[21:03:28.468] Max level 0.667389 0.328278 0.462891 0.667389 0.016663 0.068573 0.065765


[21:03:28.468] Pk lev dB -3.51 -7.99 -6.69 -3.51 -32.94 -23.28 -22.50

0.00 -4.48 -3.18 0.00 -29.43 -19.77 -18.99 < this will be after normalizing


[21:03:28.468] RMS lev dB -35.90 -38.52 -38.33 -29.07 -65.58 -51.39 -51.07
[21:03:28.468] RMS Pk dB -15.47 -16.51 -15.71 -15.47 -39.79 -31.00 -30.26
[21:03:28.468] RMS Tr dB -1.#J -1.#J -1.#J -1.#J -1.#J -1.#J -1.#J
[21:03:28.468] Crest factor - 33.62 38.19 18.97 42.86 25.45 26.83
[21:03:28.468] Flat factor 18.42 0.00 0.00 0.00 21.23 0.00 0.00
[21:03:28.468] Pk count 5.50 2 2 2 23 2 2
[21:03:28.468] Bit-depth 16/16 15/16 15/16 16/16 11/16 13/16 13/16
[21:03:28.468] Num samples 126M
[21:03:28.468] Length s 2631.840
[21:03:28.468] Scale max 1.000000
[21:03:28.468] Window s 0.050
[21:03:28.468] Process terminated with code: 0
[21:03:28.468] Execution took 1 minute(s), 47 second(s).



[21:03:28.937] Commandline: sox -V0 -t raw -L -s -b 16 -c 6 -r 48000 - -n stats

[21:05:14.234] Overall Ch1 Ch2 Ch3 Ch4 Ch5 Ch6

[21:05:14.234] DC offset -0.000001 -0.000000 -0.000001 -0.000000 -0.000000 -0.000001 -0.000001
[21:05:14.234] Min level -0.805939 -0.367798 -0.404785 -0.805939 -0.203033 -0.312012 -0.278168
[21:05:14.234] Max level 0.834442 0.398376 0.410004 0.834442 0.189209 0.278931 0.304901


[21:05:14.250] Pk lev dB -1.57 -7.99 -7.74 -1.57 -13.85 -10.12 -10.32

0.00 -6.42 -6.17 0.00 -12.28 -8.55 -8.75 < this will be after normalizing


[21:05:14.250] RMS lev dB -34.19 -34.00 -34.26 -28.99 -54.86 -39.13 -38.95
[21:05:14.250] RMS Pk dB -15.26 -15.62 -15.26 -15.52 -20.48 -22.44 -22.31
[21:05:14.250] RMS Tr dB -1.#J -138.72 -139.84 -147.72 -1.#J -1.#J -1.#J
[21:05:14.250] Crest factor - 19.96 21.16 23.49 112.39 28.22 27.01
[21:05:14.250] Flat factor 7.76 0.00 0.00 0.00 12.57 0.00 0.00
[21:05:14.250] Pk count 3 2 2 2 8 2 2
[21:05:14.250] Bit-depth 16/16 15/16 15/16 16/16 14/16 15/16 15/16
[21:05:14.250] Num samples 125M
[21:05:14.250] Length s 2595.808
[21:05:14.250] Scale max 1.000000
[21:05:14.250] Window s 0.050
[21:05:14.250] Process terminated with code: 0
[21:05:14.250] Execution took 1 minute(s), 45 second(s).



[21:05:14.359] Commandline: sox -V0 -t raw -L -s -b 16 -c 6 -r 48000 - -n stats

[21:06:50.937] Overall Ch1 Ch2 Ch3 Ch4 Ch5 Ch6

[21:06:50.937] DC offset -0.000002 -0.000001 -0.000002 -0.000001 -0.000000 -0.000000 -0.000000
[21:06:50.937] Min level -0.676056 -0.536987 -0.549896 -0.676056 -0.183105 -0.209625 -0.200348
[21:06:50.937] Max level 0.750793 0.552826 0.549530 0.750793 0.181732 0.236572 0.201385


[21:06:50.937] Pk lev dB -2.49 -5.15 -5.19 -2.49 -14.75 -12.52 -13.92

0.00 -2.66 -2.70 0.00 -12.26 -10.03 -11.43 < this will be after normalizing


[21:06:50.937] RMS lev dB -34.29 -33.64 -33.28 -29.03 -53.29 -44.20 -44.04
[21:06:50.937] RMS Pk dB -12.28 -12.28 -12.86 -14.12 -22.45 -24.03 -23.55
[21:06:50.937] RMS Tr dB -1.#J -107.22 -105.87 -128.05 -1.#J -193.53 -192.30
[21:06:50.937] Crest factor - 26.59 25.36 21.24 84.59 38.39 32.05
[21:06:50.937] Flat factor 0.00 0.00 0.00 0.00 0.00 0.00 0.00
[21:06:50.937] Pk count 2 2 2 2 2 2 2
[21:06:50.937] Bit-depth 16/16 16/16 16/16 16/16 14/16 14/16 14/16
[21:06:50.937] Num samples 124M
[21:06:50.937] Length s 2593.312
[21:06:50.937] Scale max 1.000000
[21:06:50.937] Window s 0.050
[21:06:50.937] Process terminated with code: 0
[21:06:50.937] Execution took 1 minute(s), 36 second(s).


-ne for stereo will do:

0.00 -1.18 > 0.00 0.00 > meaning the right channel will be amplified by 1.18bd

0.00 -0.56 > 0.00 0.00 > meaning the right channel will be amplified by 0.56bd

-0.43 0.00 > 0.00 0.00 > meaning the left channel will be amplified by 0.43bd

0.00 -0.26 > 0.00 0.00 > meaning the right channel will be amplified by 0.26bd


-ne for original 5.1 will do:

-0.66 -0.36 0.00 -3.15 -1.39 -2.35 > 0.00 0.00 0.00 0.00 0.00 0.00 > meaning the music (left/right channels) and the surround effect (side left/right channels) will be amplified a lot!

-4.48 -3.18 0.00 -29.43 -19.77 -18.99 > 0.00 0.00 0.00 0.00 0.00 0.00 > meaning the music (left/right channels) and the surround effect (side left/right channels) will be amplified a lot!

-6.42 -6.17 0.00 -12.28 -8.55 -8.75 > 0.00 0.00 0.00 0.00 0.00 0.00 > meaning the music (left/right channels) and the surround effect (side left/right channels) will be amplified a lot!

-2.66 -2.70 0.00 -12.26 -10.03 -11.43 > 0.00 0.00 0.00 0.00 0.00 0.00 > meaning the music (left/right channels) and the surround effect (side left/right channels) will be amplified a lot!
_

[LoRd_MuldeR]

After all I have decided to make the "channel equalization mode" an option.

Now you can even select "-n" again, but it will still fail with (some) multi-channel files, of course.

The new build is available via auto-update...

[manolito]

Thanks very much...

Could you elaborate on how the three different normalization modes (max level, max energy, none) translate to SoX parameters? Couldn't find anything in the documentation...


Cheers
manolito

[LoRd_MuldeR]

Could you elaborate on how the three different normalization modes translate to SoX parameters?

"Peak Level" == "-ne", "RMS Level" == "-nb", "None" == "-n"

[b66pak]

thanks a lot...
_

[CaMoTblku_OnToM]

ugly visual bug in latest stable release http://www.youtube.com/watch?v=_aYfZjy0YFs
how i can turn off this useless visual effects?
i think previous interface in 3.18 was much better

[LoRd_MuldeR]

ugly visual bug in latest stable release http://www.youtube.com/watch?v=_aYfZjy0YFs

Hello. That's not a bug or "effect". Some translations simply use much longer strings than the original (English) texts.

So, if necessary, the window width will be increased step-by-step, until all strings fit in...

(And nope, I can't increase the initial window width. This would only mislead the translators to use even longer strings ^^)

But feel free to suggest a better/shorter translation. Translation fixes always are welcome!

i think previous interface in 3.18 was much better

The "old" interface was built with Delphi 7.0 and didn't even support Unicode characters :p

The "new" Qt-based interface is MUCH advanced...

[LoRd_MuldeR]

LameXP v4.03 Beta-4:

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined naming pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this (http://forum.doom9.org/showthread.php?t=140273) thread for details) and removed all remnants of "old" decoder
* Added optional support for the FHG AAC Encoder included with Winamp 5.62 (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added a menu for bookmarking "favorite" output folders to the "output folder" tab
* Added Polish translation, thanks to Sir Daniel K <sir.daniel.k@gmail.com>
* Updated Qt runtime libraries to v4.8.0 RC-1 (2011-10-13), compiled with MSVC 10.0
* Updated mpg123 decoder to v1.13.4 (2011-09-07), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.50 (2011-09-23), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed Cue Sheet import for tracks with certain characters in the title
* Fixed a problem with the "normalization" filter that sometimes caused the resulting file to be empty
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)
* Restored Windows 2000 support with Visual Studio 2010 builds (this is experimental!)
* The "Open File(s)" and "Open Folder" dialogs will now remember the most recent directory
* Miscellaneous bugfixes

[LoRd_MuldeR]

LameXP v4.03 Beta-5:

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined naming pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this thread for details) and removed all remnants of "old" decoder
* Added optional support for the FHG AAC Encoder included with Winamp 5.62 (see FAQ doc for details)
* Added a menu for bookmarking "favorite" output folders to the "output folder" tab
* Added Polish translation, thanks to Sir Daniel K <sir.daniel.k@gmail.com>
* Added channel equalization options to the normalization filter (also fixes multi-channel processing)
* Updated Qt runtime libraries to v4.8.0 RC-1 (2011-10-13), compiled with MSVC 10.0
* Updated mpg123 decoder to v1.13.4 (2011-09-07), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.50 (2011-09-23), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed Cue Sheet import for tracks with certain characters in the title
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)
* Restored Windows 2000 support with Visual Studio 2010 builds (this is experimental!)
* The "Open File(s)" and "Open Folder" dialogs will now remember the most recent directory
* Miscellaneous bugfixes

Warning: There was a serious bug (http://img546.imageshack.us/img546/857/wupdatebug.png) in Beta-4 which prevents the Web Update utility from working properly :o
If you already have Beta-4 installed on your computer, then Auto Update won't work and you have to download/install the new version manually this time!
Sorry for any inconvenience...

[Dogway]

Do you happen to know if the aac or mp3 encoder dithers the output when input is for example 32 bit float wav? I didn't see anything related in the neroaacend cli help

[LoRd_MuldeR]

Do you happen to know if the aac or mp3 encoder dithers the output when input is for example 32 bit float wav? I didn't see anything related in the neroaacend cli help

Well, I think, whether the output will be (dithered) integer or floating-point depends on the decoder, which you use to play the compressed bitstream later.

There was a lengthy discussion on whether audio decoders should output floating-point here:
http://forum.doom9.org/showthread.php?t=156966

[Dogway]

wav decoder...Im reading here (http://www.gearslutz.com/board/so-much-gear-so-little-time/105258-aac-24-bit-uncompressed-files.html) and here (http://www.audiobanter.com/archive/index.php/t-39170.html) and it seems the encoders just don't care and "truncate" the signal. Maybe you could add dithering in the wav decoder?
Reading a bit more it seems they could probably dither, but doing it or not is not a critical issue.... : /

[LoRd_MuldeR]

I'm not exactly sure what you mean with "wav decoder", because (uncompressed) Wave files don't need any decoder.

And how are the MP3 or AAC encoders related to decoding :confused: