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

[Dogway]

sorry I didn't think mp3 or aac used already 32bit fp.

[mike20021969]

Using 4.03 beta 5, am I correct in saying the the debug console not be disabled? It would appear it cannot.
(This is the first time I installed a LameXP beta version).

Also, is there a new stable version around the corner? :)

[LoRd_MuldeR]

Using 4.03 beta 5, am I correct in saying the the debug console not be disabled? It would appear it cannot.
(This is the first time I installed a LameXP beta version).

Please read the F.A.Q. document:
http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#900a2a6c

Also, is there a new stable version around the corner? :)

Yes, soon. It will contain the LAME 3.99 final release.

[mike20021969]

Please read the F.A.Q. document:
Thanks for pointing me to that :)
Yes, soon. It will contain the LAME 3.99 final release.
Excellent.
:thanks:

[LoRd_MuldeR]

LameXP v4.03 Beta-6:

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>
* 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 LAME encoder to v3.99 Final (2011-10-17), compiled with ICL 12.1.6 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.131))
* 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 a potential bug in CPU type detection that might have caused the wrong binary to be used
* 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

[LoRd_MuldeR]

LameXP v4.03 RC-1:

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 an option to hibernate the computer (aka "Suspend-to-Disk") instead of shutting it down
* 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 LAME encoder to v3.99 Final (2011-10-17), compiled with ICL 12.1.6 and MSVC 10.0 (details)
* 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 a potential bug in CPU type detection that might have caused the wrong binary to be used
* 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

[Motenai Yoda]

it has the same bug that I've previously reported:
if "Prepend relative source file path to output file" in "Output Directory" tab is checked, it still remains active (but greyed) even when "Save output files to the same location where the input file is located" is checked.

-feature request
to avoid intense (and slow) hd activity, as the size of an intermediate raw files can be easily calculated previously (duration_in_seconds * frequency * bitdepth * channels), it should be possible, if the free RAM size is greater than the above + an offset, use a ram file for the raw intermediate.

edit I mean "phisical ram"

[LoRd_MuldeR]

it has the same bug that I've previously reported:
if "Prepend relative source file path to output file" in "Output Directory" tab is checked, it still remains active (but greyed) even when "Save output files to the same location where the input file is located" is checked.

I think I already had commented on that one. But again: If the "Save output files to the same location where the input file is located" is checked, then the "Prepend relative source file path to output file" option doesn't make much sense. And therefore it is disabled (greyed out). So what exactly, in your opinion, is the problem here? :confused:

-feature request
to avoid intense (and slow) hd activity, as the size of an intermediate raw files can be easily calculated previously (duration_in_seconds * frequency * bitdepth * channels), it should be possible, if the free RAM size is greater than the above + an offset, use a ram file for the raw intermediate.

Not possible. That's because LameXP is "only" a GUI front-end to a bunch of command-line tools. These tools read their input from a file and they also write their output back to a file. When LameXP calls one of the command-line tools (e.g. an encoder or a decoder), then it can tell the tool which file to read the input from and also which file to write the output to. But that's it! You can't tell the tool to keep the output in the memory (RAM). And even if you could, each process still has its own (virtual) memory space! That means: If, for example, the decoder process would keep the output in a buffer inside its memory (instead of writing it to a file), then the output data would be gone for good, as soon as the decoder process terminates - with no way for the encoder process to every access that data.

Well, that's not the whole truth. It is possible to pass data from one process to another one directly in the memory - by using a pipe. Or more specifically: By having the first process write the data to STDOUT and having the second process read the data from STDIN. But this has other problems: For example, the second process can not determine the size of the input until it has read/processed everything, because seeking is not possible when reading from a pipe. Also not all tools used in LameXP do support reading/writing from/to STDOUT/STDIN. Last but not least, implementing the usage of pipes (at least for the tools that do support it) would require fundamental changes in the architecture of LameXP. For example, decoding and encoding would then happen in parallel, rather than doing it in two separate steps...

Anyway, what you can do already: Create a "RAM Disk" and move LameXP's Temp directory to that RAM Disk.

[Motenai Yoda]

I think I already had commented on that one. But again: If the "Save output files to the same location where the input file is located" is checked, then the "Prepend relative source file path to output file" option doesn't make much sense. And therefore it is disabled (greyed out). So what exactly, in your opinion, is the problem here? :confused:

when "Save output files to the same location where the input file is located" and "Prepend relative source file path to output file" are checked (although the latter is grayed),
if u process a file in
"C:\lord_mulder\work"

the output file is placed in
"C:\lord_mulder\work\lord_mulder\work"

I've posted a video at the time. http://forum.doom9.org/showthread.php?p=1523849#post1523849

imho or is grayed/disabled/unapplied or is active/applied.


Not possible. That's because LameXP is "only" a GUI front-end to a bunch of command-line tools. These tools read their input from a file and they also write their output back to a file. When LameXP calls one of the command-line tools (e.g. an encoder or a decoder), then it can tell the tool which file to read the input from and also which file to write the output to. But that's it! You can't tell the tool to keep the output in the memory (RAM). And even if you could, each process still has its own (virtual) memory space! That means: If, for example, the decoder process would keep the output in a buffer inside its memory (instead of writing it to a file), then the output data would be gone for good, as soon as the decoder process terminates - with no way for the encoder process to every access that data.

Well, that's not the whole truth. It is possible to pass data from one process to another one directly in the memory - by using a pipe. Or more specifically: By having the first process write the data to STDOUT and having the second process read the data from STDIN. But this has other problems: For example, the second process can not determine the size of the input until it has read/processed everything, because seeking is not possible when reading from a pipe. Also not all tools used in LameXP do support reading/writing from/to STDOUT/STDIN. Last but not least, implementing the usage of pipes (at least for the tools that do support it) would require fundamental changes in the architecture of LameXP. For example, decoding and encoding would then happen in parallel, rather than doing it in two separate steps...

Anyway, what you can do already: Create a "RAM Disk" and move LameXP's Temp directory to that RAM Disk.

yeah, I thought that there were such problems

[LoRd_MuldeR]

when "Save output files to the same location where the input file is located" and "Prepend relative source file path to output file" are checked (although the latter is grayed),
if u process a file in
"C:\lord_mulder\work"

the output file is placed in
"C:\lord_mulder\work\lord_mulder\work"

I've posted a video at the time.

imho or is grayed or is active/applied.

Oh, I see :eek:

Sorry, I did not get your point before. But the example made it clear now.

Thank you for the report, I will fix this ASAP.

[LoRd_MuldeR]

LameXP v4.03 RC-2:

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 an option to hibernate the computer (aka "Suspend-to-Disk") instead of shutting it down
* 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 LAME encoder to v3.99 Final (2011-10-17), compiled with ICL 12.1.6 and MSVC 10.0 (details)
* 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 a potential bug in CPU type detection that might have caused the wrong binary to be used
* Fixed Cue Sheet import for tracks with certain characters in the title
* Fixed a bug with "Prepend relative source file path to output file" under certain conditions
* 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 RC-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
* Added an option to hibernate the computer (aka "Suspend-to-Disk") instead of shutting it down
* 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)
* Added indicators for current CPU usage, RAM usage and free diskspace to the processing window
* Updated Qt runtime libraries to v4.8.0 RC-1 (2011-10-13), compiled with MSVC 10.0
* Updated LAME encoder to v3.99 Final (2011-10-17), compiled with ICL 12.1.6 and MSVC 10.0 (details)
* 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 a potential bug in CPU type detection that might have caused the wrong binary to be used
* Fixed Cue Sheet import for tracks with certain characters in the title
* Fixed a bug with "Prepend relative source file path to output file" under certain conditions
* 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

If nobody has any objections, this will go final very soon :)

[mike20021969]

Thanks for the update...roll on the Final :)

I like using AAC encoding - it's just a shame that my iPod and Sony mp3 players don't "support the sound quality" of the lower bitrates (e.g. 32kbps or 64kbps) - they sound rather crisp on the computer, but the high-end is lacking on the mp3 players (it's similar to listening to mp3pro encodes on a software player which doesn't support mp3pro playback).

[LoRd_MuldeR]

Thanks for the update...roll on the Final :)

I like using AAC encoding - it's just a shame that my iPod and Sony mp3 players don't "support the sound quality" of the lower bitrates (e.g. 32kbps or 64kbps) - they sound rather crisp on the computer, but the high-end is lacking on the mp3 players (it's similar to listening to mp3pro encodes on a software player which doesn't support mp3pro playback).

That sounds like your player doesn't support HE-AAC:

HE-AAC is nothing but (LC-)AAC combined with SBR (Spectral Band Replication), the same way "mp3PRO" is just good old MP3 with SBR pre-/postprocessing.

Any player that supports LC-AAC can decode HE-AAC as well. But without a fully HE-capable decoder you only get half the sample rate for 'HE' files (e.g. 22.05 Hz instead of 44.1 Hz).

As a result the "higher" frequencies are missing completely when playing HE-AAC files with a LC-AAC player/decoder, giving it a rather "dull" sound...

(Note: HE-AAC is only used for ultra-low bitrates, which explains why you won't get those problems at higher bitrates. At higher bitrates plain LC-AAC will be used)

[mike20021969]

Thanks for that very clear explanation :)
Hopefully, there's a branded mp3 player "out there" that supports HE-AAC.

[SeeMoreDigital]

Thanks for that very clear explanation :)
Hopefully, there's a branded mp3 player "out there" that supports HE-AAC.
Given QuickTime7 player now supports AAC-HE. How about all you iPod owners getting together and campaigning Apple to support it?

Plus, you could also remind them there's such a thing as AAC-HE PS too!

[Przemek_Sperling]

Thanks for that very clear explanation :)
Hopefully, there's a branded mp3 player "out there" that supports HE-AAC.

Pity that your player does not work with RockBox http://www.rockbox.org
I have to say that the firmware is great.

[SeeMoreDigital]

Pity that your player does not work with RockBox http://www.rockbox.org
I have to say that the firmware is great.Many (non Apple) cell phones fully support playback of AAC-LC and AAC-HE sources.

All my Mediatek chip-set based hardware players fully support playback of AAC-LC, AAC-HE and AAC-HE PS sources ;)

[LoRd_MuldeR]

LameXP v4.03 has been released :)

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 an option to hibernate the computer (aka "Suspend-to-Disk") instead of shutting it down
* 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)
* Added indicators for current CPU usage, RAM usage and free diskspace to the processing window
* Updated Qt runtime libraries to v4.8.0 RC-1 (2011-10-13), compiled with MSVC 10.0
* Updated LAME encoder to v3.99 Final (2011-10-17), compiled with ICL 12.1.6 and MSVC 10.0 (details)
* 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 a potential bug in CPU type detection that might have caused the wrong binary to be used
* Fixed Cue Sheet import for tracks with certain characters in the title
* Fixed a bug with "Prepend relative source file path to output file" under certain conditions
* 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

[mike20021969]

LameXP v4.03 has been released :)
Nice one.
:thanks:

Next beta tomorrow? ;)

[SeeMoreDigital]

LameXP v4.03 has been released :)
Excellent...

[MajorX]

Thanks LoRd_MuldeR :)
I have few questions plzz help,

I want to compress heavily an audio(with 32kbps, 6 channel to 2 channel) .....so Is it good to enable volume normalization if yes what setting should i use now the defaults value are
Peak Volume(dB)= -0.50
Equalization Mode= Peak Level

Can i hide dropBox?

[LoRd_MuldeR]

I want to compress heavily an audio(with 32kbps, 6 channel to 2 channel) .....

I'd recommend to use AAC for that purpose.

so Is it good to enable volume normalization if yes what setting should i use now the defaults value are
Peak Volume(dB)= -0.50
Equalization Mode= Peak Level

I don't think volume normalizations makes the audio easier/harder to compress, so it shouldn't matter.

WARNING: People tend to rate the quality of audio higher when it's "louder". So be sure that you don't get fooled here :)

Consequently, if you want to test the effect of normalization, you should compare the following:

(1) Compress -> Normalize -> Decompress/Listen
(2) Normalize -> Compress -> Decompress/Listen

Can i hide dropBox?

Sure. Right-click.

[MadRat]

I'm... really sorry to bring this up but... Norton is blocking tool_lame.exe as having highly suspicious behavior and telling me I should restart my computer.

[mariush]

Uninstall or update Norton then, because it's stupid and incorrect determination from Norton. tool_lame.exe is a mp3 encoder - it takes an uncompressed audio file and creates a mp3 file.

[Othniel Graichen]

I am testing LameXp v4.03 Final-1 Build 764 this AM.

Today I processed some mp3 files containing cover art into a new directory with this build. I lost the cover art in the new
folder

I am reencoding with LAME -- the input files are 48k CBR mp3, and the output is VBR 9 at 16k sampling frequency. The encoding went ok, but the cover art is now gone.

Your release notes say this is supposed to work. This is issue #1.

Also I was unable to select 8 as my minimum bitrate in LAME having instead to supply -b 8 using the Lame cmdline options.
Is there a reason for that or is this an oversight?

Furthermore, when I attempted to drop my audiobooks folder on LameXP's main window, it said 1 file not recognized. I had to enter that directory and select all its subfolders to drag and drop. The source was a folder on my Desktop. So when I processed, all files were created in a flat output folder losing the original directory structure.

Now when I select "prepend directory structure" it
creates users/owner/Desktop/NWT.cbr/subfolders/files within
the output folder which is better than having them altogether but I guess I do not know how to control where the files are generated. This is the least important issue as I can always prune the folder and rename at a higher level.
I'm not sure if this is an issue or I just dont know how it is supposed to work.

Othniel

[Othniel Graichen]

I have more information about my previous report.

Windows Explorer is stupid. ok you knew that already.

Well Final-1 Build does include artwork.

Mp3tag shows it, MPC can play my VBR mp3s. But WMP
will not handle my VBR mp3 files and Windows Explorer will
not show the embedded artwork.

I was not aware of how frail and wimpy WMP is as I
primarily use MPC. Please excuse the false alarm.
I hope to make it up to you in working on the Linux
release of LameXP.

[LoRd_MuldeR]

I'm... really sorry to bring this up but... Norton is blocking tool_lame.exe as having highly suspicious behavior and telling me I should restart my computer.

As always in this situation: Please re-scan the suspicious file at http://www.virustotal.com/ to be sure it isn't really infected.

Then report the FALSE POSITIVE to the developer of your AntiVirus software. And, if they don't fix the problem, switch to a better product.

(I can't do anything about the issue, because it is impossible to know what aspect of LAME triggers the failure in their software)

[LoRd_MuldeR]

I am testing LameXp v4.03 Final-1 Build 764 this AM.

Today I processed some mp3 files containing cover art into a new directory with this build. I lost the cover art in the new
folder

I am reencoding with LAME -- the input files are 48k CBR mp3, and the output is VBR 9 at 16k sampling frequency. The encoding went ok, but the cover art is now gone.

Your release notes say this is supposed to work. This is issue #1.

LameXP will detect/extract "cover art" that is embedded in your MP3 files. And, if the selected encoder supports it, then it will re-embed the cover art.

However LameXP will not deal with cover art that is saved as a separate JPEG file or in any other way.

Please use Mp3Tag (http://www.mp3tag.de/en/) to make sure your input MP3 files contain cover art. Then, after the files have been re-encoded, check the output files again.

Also I was unable to select 8 as my minimum bitrate in LAME having instead to supply -b 8 using the Lame cmdline options.
Is there a reason for that or is this an oversight?

The values were limited to a "sane" range. Why do you want to force LAME to use such ultra-low bitrates? :scared:

Note: The lowest supported bitrate in original MP3 (as defined by MPEG-1) is 32 kbps. MPEG-2 added even lower bitrates to MP3, but only for 16, 22.05 and 24 kHz!

See also:
http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/switchs.html#b

Furthermore, when I attempted to drop my audiobooks folder on LameXP's main window, it said 1 file not recognized. I had to enter that directory and select all its subfolders to drag and drop. The source was a folder on my Desktop. So when I processed, all files were created in a flat output folder losing the original directory structure.

That's probably because there actually was an un-supported file in the folder your dropped onto LameXP ;)

I guess there was something like "thumbs.db" or "desktop.ini" in your folder. Maybe you didn't see the file, because it was hidden. LameXP will reject those, of course.

(I should make LameXP ignore files like "thumbs.db" or "desktop.ini" in a future version though)

Now when I select "prepend directory structure" it
creates users/owner/Desktop/NWT.cbr/subfolders/files within
the output folder which is better than having them altogether but I guess I do not know how to control where the files are generated. This is the least important issue as I can always prune the folder and rename at a higher level.
I'm not sure if this is an issue or I just dont know how it is supposed to work.

That's best explained with an example, I think :)

Let's assume your output folder is selected as:
C:\Some Output Folder

Also let's assume you are converting the following source files:
C:\My Music\1st Artist\Song 1.mp3
C:\My Music\2nd Artist\Song 2.mp3
D:\Foobar\Test\Rnd32\Whatever.mp3

Normally LameXP would create these output files:
C:\Some Output Folder\Song 1.mp3
C:\Some Output Folder\Song 2.mp3
C:\Some Output Folder\Whatever.mp3

With "prepend relative source file path to output file" enabled, you will get these instead:
C:\Some Output Folder\My Music\1st Artist\Song 1.mp3
C:\Some Output Folder\My Music\2nd Artist\Song 2.mp3
C:\Some Output Folder\Foobar\Test\Rnd32\Whatever.mp3

[Othniel Graichen]

>>The values were limited to a "sane" range. Why do you want to force LAME to use such ultra-low bitrates?

I am a Linux cmd line kinda guy. LameXP GUI is new to me. Here is my "NORMAL" command line to process voice recordings:

lame --resample 11 -b 8 -V 9 -a FM103-3_102911_003.wav

Sometimes I include the --preset voice switch -- mostly not.
I work with voice recordings transmitted over FM.

For VBR to work right -- you must let LAME decide the appropriate bit rate. -b specifies the minimum and -B the maximum. 32 is the default for -b so VBR cant take advantage of 24, 16 and 8 encodings unless you enable this via switch.

Othniel Graichen

[LoRd_MuldeR]

AFAIK, VBR mode woks just fine without -b and -B. In that case LAME will simply use its default minimum/maximum bitrates for your 'VBR' quality value.

So IMO you shouldn't overwrite these, unless you have a very good reason to do so. The documentation even states that "the use of -B is NOT RECOMMENDED".

Also, as mentioned before, the lowest bitrate allowed in MP3, according to MPEG-1, is 32 kbps.

Even lower bitrates are only supported with MPEG-2 extensions. And even then only for 16, 22.05 and 24 kHz, but not for the more common sample rates, like 44.1 or 48 kHz.

Last but not least and most important:

I encoded a 44.1 kHz file with LAME and "-V9" (no other options set!). LAME encoded at 22.05 kHz. The output MP3 file did contain 8, 16 and 24 kbps frames!

Hence LAME will automatically downsample the input for such ultra-low quality settings. And, if it does so, it will make use of the lowest bitrates - even without '-b' option ;)

(BTW: You may want to check out MPEG Audio Info (http://sourceforge.net/projects/lamexp/files/Miscellaneous/MPEG%20Audio%20Info/MPEGAudioInfo.2011-04-24.zip/download), which gives detailed per-frame info, to analyze the output MP3 files.)

[Taurus]

Out of curiosity I gave the FHG aac encoder a shot.
Maybe this has been adressed before:
Why is the slider in the compression settings tab only working at insane intervalls?
From level 0.50 to 0.9 there is almost no increase in bitrate
and even 1.0 is giving me a file undersized compared to the source.
The FHG files are from the newest 5.622 Winamp.
Back to nero for now.:p

[LoRd_MuldeR]

Out of curiosity I gave the FHG aac encoder a shot.
Maybe this has been adressed before:
Why is the slider in the compression settings tab only working at insane intervalls?
From level 0.50 to 0.9 there is almost no increase in bitrate
and even 1.0 is giving me a file undersized compared to the source.
The FHG files are from the newest 5.622 Winamp.
Back to nero for now.:p

As the FHG encoder is ClosedSource, only one of the Winamp/FHG engineers could answer this question :p

All that LameXP can do is passing options to the API provided by the encoder. And the VBR quality selector of the FHG encoder is relatively coarse-grained:

The quality value can be selected between 1 and 5, integer (whole numbers) only. The quality selector of the Nero encoder is much more fine-grained, as you know...

(Note that the quality slider in LameXP was designed for Nero AAC. For FHG AAC the values in range 0.0 to 1.0 are mapped to 1...5 in a linear fashion)

[Othniel Graichen]

AFAIK, VBR mode works just fine without -b and -B. In that case LAME will simply use its default minimum/maximum bitrates for your 'VBR' quality value.

Also, as mentioned before, the lowest bitrate allowed in MP3, according to MPEG-1, is 32 kbps.

Even lower bitrates are only supported with MPEG-2 extensions.


I stand corrected. Thank you. I like to learn.

However, I am aware that I am utilizing MPEG-2.5 extensions. Maybe LAMExp should have another checkbox under the Additional Options tab in the channel mode/sampling rate box called "Enable MPEG-2.5".

When such a box is checked, 8, 11.025 and 12 kHz should be available in the sample rate pull-down box. I suggest also that the minimum bitrate field be set to 8 when MPEG-2.5 is enabled.

The application is not theoretical but that of mp3 audiobooks and
voice recordings.

[Taurus]

Thank you:thanks:

[LoRd_MuldeR]

I stand corrected. Thank you. I like to learn.

However, I am aware that I am utilizing MPEG-2.5 extensions. Maybe LAMExp should have another checkbox under the Additional Options tab in the channel mode/sampling rate box called "Enable MPEG-2.5".

When such a box is checked, 8, 11.025 and 12 kHz should be available in the sample rate pull-down box. I suggest also that the minimum bitrate field be set to 8 when MPEG-2.5 is enabled.

The application is not theoretical but that of mp3 audiobooks and
voice recordings.

I don't think we need yet another option. LAME doesn't have a switch for that either. It's as simple as that: When encoding to a sample rate that is only supported in MPEG-1 (32, 44.1 or 48 kHz), LAME will create a MPEG-1 MP3 stream. When encoding to a sample rate that is only supported in MPEG-2 (16, 22.05 and 24 kHz), LAME will create a MPEG-2 MP3 stream. And when encoding to a sample rate that is only supported in MPEG-2.5 (8, 11.025 and 12 kHz), LAME will create a MPEG-2.5 MP3 stream. For 99.9% of the user this difference doesn't even matter (and thus we should confuse them with different MPEG standard versions). Moreover, in any case, LAME will make use of all supported bit rates (for the current sample rate), at least when encoding in VBR mode. There is no need to use -b or -B to "enable" additional bit rates. Instead these options can be used to further restrict the bit rates that VBR mode can choose from! And thus you should only be using them, if you have a very good reason to do so. Otherwise trust LAME's VBR algorithm...

http://img854.imageshack.us/img854/3479/cwindowssystem32cmdexe2l.th.png (http://img854.imageshack.us/img854/3479/cwindowssystem32cmdexe2l.png) http://img228.imageshack.us/img228/2352/cwindowssystem32cmdexe2f.th.png (http://img228.imageshack.us/img228/2352/cwindowssystem32cmdexe2f.png)

[MadRat]

As always in this situation: Please re-scan the suspicious file at http://www.virustotal.com/ to be sure it isn't really infected.

Then report the FALSE POSITIVE to the developer of your AntiVirus software. And, if they don't fix the problem, switch to a better product.

(I can't do anything about the issue, because it is impossible to know what aspect of LAME triggers the failure in their software)

It seems to be a false positive.

File already submitted: The file sent has already been analysed by VirusTotal in the past. This is same basic info regarding the sample itself and its last analysis:
MD5: 1aad0bc496cf8bd07b86ebc11bdb8a33
Date first seen: 2011-11-02 20:48:41 (UTC)
Date last seen: 2011-11-02 20:48:41 (UTC)
Detection ratio: 0/43

Thank you, for being patient.

[LoRd_MuldeR]

Result: 0 /43 (0.0%) (http://www.virustotal.com/file-scan/report.html?id=8e6b100d56f79eab6f6611b7f7f9d7d710a306b4e145012579835ec4bd66b4f5-1320266949)

Clearly a FALSE POSITIVE :)

Interestingly the "Symantec" scanner, which is the company behind "Norton", also confirms that the file is clean.

Maybe the issue has already been fixed ???

[ikuban]

Is the new RMS equalization mode similar to a dynamic range compression?

[manolito]

Is the new RMS equalization mode similar to a dynamic range compression?
No, the dynamic range of the source is not touched by this option. What is getting changed is the balance between the different channels of a multichannel source. Here is a quote from the SoX manual regarding the gain -nb effect:
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 (but, without also giving −n, the audio is not ‘normalised’).

The −B (balance) option is similar to −e, but with −B, the RMS level is used instead of the peak
level. −B might be used to correct stereo imbalance caused by an imperfect record turntable car-
tridge. Note that unlike −e, −B might cause some clipping.

−b is similar to −B but has clipping protection, i.e. if necessary to prevent clipping whilst
balancing, attenuation is applied to all channels. Note, however, that in conjunction with −n, −B
and −b are synonymous.


Cheers
manolito

[LoRd_MuldeR]

Is the new RMS equalization mode similar to a dynamic range compression?

Well, kind of, I would say.

It does not compress the dynamic range "inside" on channel. That is: All samples in one channel will always be amplified by the same factor.

However one channel may be amplified stronger than the other ones, which possibly (not necessarily) changes the dynamic range "between" the channels - that may be desired or not.

(Be aware that, due to a bug(?) in SoX, the plain "-n" option files for some files, which was all the reason to use "-nb" by default)

[manolito]

(Be aware that, due to a bug(?) in SoX, the plain "-n" option files for some files, which was all the reason to use "-nb" by default)
Oh yes, this is a SoX bug which has been there for some time. Have a look here:
http://sox.sourceforge.net/Docs/Bugs

The recommended workaround is:
Create a folder called `tmp' at the top level of the `C:' drive (and any other drive from which SoX may be invoked).

But this workaround does not work at all. And SoX has not been updated since February 2011, so there is not much hope that this bug will get fixed anytime soon...:rolleyes:

Which makes me think if it would be a good idea to ditch SoX for normalizing altogether...


Cheers
manolito

[LoRd_MuldeR]

I think that's another issue.

LameXP already tells SoX to put temporary files into the LameXP Temp folder, which lies inside %TEMP% and therefore has no problems with file permissions.

The problem is more that normalization with just "-n" works most of the time, but sometimes creates an empty file without an error message...

(BTW: Whoever tries to create a sub-folder for temporary files in the Root folder of the system drive and then wonders about missing permissions doesn't have a clue. That wouldn't work on a Unix system either - at least not without using 'sudo'. It's certainly not a Vista/UAC-specific issue)

[manolito]

The problem is more that normalization with just "-n" works most of the time, but sometimes creates an empty file without an error message...
For me it does not look like sometimes. For a 6-ch wav file (no matter if the file is in the extensible format or not) SoX always creates an empty file without an error message, while for a 2-ch wav file SoX always works like it should.

I did many tests to determine this behavior, and these tests were done from the SoX command line (completely outside of LameXP). For 6-ch wav files the error was always something like "Could not create temporary device".


Cheers
manolito

[LoRd_MuldeR]

Well, I was able to reproduce the problem with some multi-channel (here I mean: more than two channels) files, but not with all. Also I never saw an error message, only an empty file.

If you see "Could not create temporary device", then please try with --temp . so that SoX will put the Temp file into the current directory...

[Motenai Yoda]

I notice that sometimes normalizing by peak don't work well, analyzing the result file with audition it finds peaks over -0.5dB..

Edit: It's a lack of lossy compression

[Hobbe]

Thanks for the new version... But I get this error when I tried to encode a mp3 with album art..
unsupported image: 'C:\Users\*****\AppData\Local\Temp\7f6f2bd55a3e4905a01d7d2723996b41\735d2eb984d746819396f5d3289e3cf8.jpg'.
Specify JPEG/PNG/GIF image

Exited with code: 0x0001

Does't lame support jpg at all? or is it just a problem with this file?

[LoRd_MuldeR]

Hello, Hobbe. As you didn't post the complete log, it's a bit hard to guess.

But it looks like LameXP (or MediaInfo to be more precise) found a JPEG image in the input file (or you manually added cover art in LameXP's MetaInfo editor), but then the encoder (LAME?) refused to embed that picture into the output file.

Unless you provide an example, I can only speculate that either the JPEG file is broken/incomplete somehow or what appears to be a JPEG file at first glance turns out to not be a JPEG file...

(You may want to open 'C:\Users\John Doe\AppData\Local\Temp\xxxx\yyyy.jpg' in IrfanView (http://www.irfanview.de/) and check what happens)

[Hobbe]

Thanks... I did use mp3tag to add album art. This time I scaled down the picture to a smaller size and readded the art and now it works.. strange..

Can I add album art directly in LameXP? if so... how? =)

Any plans to make it possible to use Quicktime encoder?

[LoRd_MuldeR]

Thanks... I did use mp3tag to add album art. This time I scaled down the picture to a smaller size and readded the art and now it works.. strange..

Can I add album art directly in LameXP? if so... how? =)

Meta Data editor. Add the file, then click "View Details" and "Artwork". In the Artwork view, you can click "Edit" to load/change the album art.

Any plans to make it possible to use Quicktime encoder?

You probably mean the QuickTime/iTunes AAC encoder?

Well, I certainly can't include the QuickTime AAC encoder with LameXP due to licensing issues. If there is some OpenSource CLI front-end available for QuickTime AAC, I could add support for that in a similar way to FHG AAC encoder. Which means that people would still have to download and install QuickTime from the official web-site. Then copy the encoder DLL's to the correct place manually.

But due to a deep-rooted antipathy against QuickTime products, that probably won't happen soon ;)