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

[Hobbe]

Thanks for letting me know.. I have completely missed that! =)

Ok. I understand.. I have the same feeling like you regarding Quicktime.. But it produce great sounding aac files :)
Meanwhile, I'll try to use the FHG aac encoder :D

[LoRd_MuldeR]

LameXP v4.03 R2 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.1 Final (2011-11-05), 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.133))
* Updated mpg123 decoder to v1.13.4 (2011-09-07), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.51 (2011-11-11), compiled with ICL 12.1.6 and 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

No important changes since the first v4.03 release. Just updated the LAME and MediaInfo binaries to the latest versions.

[mike20021969]

After installing an update, I always have to set my personal preferences again - the output folder, disable sounds, uncheck .m3u option, disable shell integration etc...
Is it possible that when an update is installed that preferences are remembered?

This would be a welcome addition to this great program.
Thanks.

[LoRd_MuldeR]

After installing an update, I always have to set my personal preferences again - the output folder, disable sounds, uncheck .m3u option, disable shell integration etc...
Is it possible that when an update is installed that preferences are remembered?

This would be a welcome addition to this great program.
Thanks.

Possible, yes. But currently the settings for each version are store separately. And there is a reason for this ;)

Some settings change their range/meaning between different versions and, the way it currently is implemented, a rude surprise is avoided.

After all, I should implement an automatic "import" function that will import settings from previous versions - if and only if possible.

(Nonetheless, if you only install major updates, then you won't update and thus loose your settings very often. So this isn't high priority)

[Caroliano]

The Web Update and instalation windows should not be aways on top of everything... I'm writing it right now with the download window above the textbox...

Besides that, this is my favorite audio encoding tool. Thanks for the update!

[LoRd_MuldeR]

I made the Installer and Web Updater windows "top most", because Windows has the annoying tendency to show the GUI of newly created processes in the background.

Having to minimize all other windows in order to find the Installer (or Updater) window may be very confusing, especially to less experienced users.

Therefore I think making those windows "top most", in order to ensure they will be visible right away, is the the lesser of two evils. Also: How often do you install/update LameXP?

Unless you use Beta updates, you shouldn't see the updater more often than once every 2 or 3 months. And, while updating, focusing on the Updater isn't the worst thing...

(You can minimize the updater at any time, of course. Probably makes sense only, if your internet connection is extremely slow)

[LoRd_MuldeR]

Diary of an GUI developer :p

A small excursion: LameXP uses "background" threads to monitor the encoder/decoder processes (e.g. LAME or OggEnc2) in real-time. A "background" thread will read and parse all text output that its encoder/decoder process writes to the STDOUT or STDERR. And, as soon as the process has written a progress update, the "background" thread emits an update signal. The update signal will then be processed in the "main" (GUI) thread's event loop, causing the progress indicator to be updated. Until now, each "background" thread was emitting update signals as soon as possible and even if the progress hadn't changed at all. It has to be noted that some encoder/decoder processes write a whole lot of status messages to their STDOUT/STDERR, often resulting in the same progress value (percentage) being reported multiple times. This happens, for example, if the progress hasn't changed between two (or more) consecutive status messages. Unfortunately as a result our "background" threads will emit update signals at a high rate! While playing around with the profiler (AMD CodeAnalyst), it came to my attention that the LameXP front-end process was eating a substantial amount of CPU time, in certain cases. It was obvious that this was caused by too many update signals being emitted/processed. For this reason I implemented update signal coalescing today. This means: Now a "background" thread will emit an update signal if and only if the progress has increased by at least 3% - relative to the previous update signal that has been emitted. Depending on the individual encoder/decoder, this significantly reduces the amount of update signals the "main" thread has to process, which clearly reduces the CPU time consumed by the LameXP front-end process. That CPU time is now available to the encoder/decoder processes, which will speed-up the overall process, or to other processes running on the system. It comes at cost of slightly delayed progress indicator updates.

This CPU usage graph shows the CPU load produced by the LameXP front-end process for the very same transcoding job, before (left) and after (right) the optimization:
http://img823.imageshack.us/img823/3078/lamexpsignalcoalescing.th.png (http://img823.imageshack.us/img823/3078/lamexpsignalcoalescing.png)

And here is a more detailed analysis of the CPU time consumption for all processes running on the computer while transcoding, before (left) and after (right) the optimization:
http://img88.imageshack.us/img88/6562/lamexpsignalcoalescinga.th.png (http://img88.imageshack.us/img88/6562/lamexpsignalcoalescinga.png)

(That's a reduction of LameXP's CPU time consumption to 1/5 in this particular case - using 'mpg123' as decoder and 'OggEnc2' as encoder)

[Chikuzen]

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.

http://tmkk.pv.land.to/qtaacenc/
http://sites.google.com/site/qaacpage/ :p

[LoRd_MuldeR]

http://tmkk.pv.land.to/qtaacenc/
http://sites.google.com/site/qaacpage/ :p

Thanks! I will have a look at that one. Though, as said before, adding support for QuickTime AAC is not a priority for me ;)

[VzK]

These probably are dumb questions/suggestions:

Every time I open LameXP I have to clear 'Comment' field from Meta Data, it doesn't memorize the blank deleted info, both portable/install versions.
Then again when I'm editing tag infos on foobar there is always "LAME 32bits version 3.99.1 (http://lame.sf.net)" written in <encoding settings>. It would be cool if this could be personalized.

Regarding 32bits - I'm running under win7 x64 and it works fast without any problem but since there is a LAME 64-bit version available wouldn't make sense that be included/used?

I had the last version updated from the manager and today I noticed 'Adjust Bass (dB)' @ -1,00 and I'm positive I didn't change it.

It would be cool if it was possible to drag a .cue file instead of using the import tool. Lazy, I know.

Thanks for this indispensable app.

[LoRd_MuldeR]

Hello, VzK.

Every time I open LameXP I have to clear 'Comment' field from Meta Data, it doesn't memorize the blank deleted info, both portable/install versions.
Then again when I'm editing tag infos on foobar there is always "LAME 32bits version 3.99.1 (http://lame.sf.net)" written in <encoding settings>. It would be cool if this could be personalized.

LAME adds that signature to the ID3v2 tag all by itself, it's not triggered by LameXP.

It's probably a help for the developers. So if somebody sends in a "problematic" file to the LAME developers, they can easily know form which LAME version that file originated.

Even if I could, I wouldn't modify LAME to suppress its signature. And I wonder what you want to hide? It doesn't leak any person information!

Regarding 32bits - I'm running under win7 x64 and it works fast without any problem but since there is a LAME 64-bit version available wouldn't make sense that be included/used?

LameXP already contains a SSE2-optimized build (Intel-only) of LAME and a generic 'IA32' build with SSE2 runtime CPU-dispatching.

Including a 64-Bit build "just because we can" isn't a good idea. It would make LameXP.exe even bigger.

And, as the 64-Bit builds of LAME currently can't be build with Assembler-optimizations enabled, they would probably be even slower...

(I did a test with various compiler settings a while ago and the 64-Bit build was the slowest on my system)

I had the last version updated from the manager and today I noticed 'Adjust Bass (dB)' @ -1,00 and I'm positive I didn't change it.

You probably changed it accidentally with the Mouse Wheel when scrolling down the Advanced Options page, seriously ;)

(If not, I'll investigate it, as soon as you give me detailed instructions on how to reproduce the issue)

It would be cool if it was possible to drag a .cue file instead of using the import tool. Lazy, I know.Thanks for this indispensable app.

LameXP uses MediaInfo to detect the type of a file.

That's why you can throw a bunch of files onto LameXP and still it will be able to tell the type of each file and select the suitable decoder.

That's not possible with Cue Sheets, because these are simple Text files.

Well, we could try to guess that a file with extension .cue is a Cue Sheet, but file extensions are not unambiguous and might even be "wrong".

[LoRd_MuldeR]

Here is experimental QAAC (Apple QuickTime/iTunes AAC encoder) support :)

You will need to install the QAAC Add-in for LameXP from this location:
http://www.mediafire.com/file/8ifdnygiab4z5po/LameXP.qaac-addin.2011-11-22.zip

Last but not least, if you do not have an up-to-date QuickTime or iTunes installed yet, you will have to download and install that too :o

(Note: If both, Nero AAC and QAAC, are available, then LameXP will give preference to QAAC for now!)

[LoRd_MuldeR]

LameXP v4.04 Alpha-6:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (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)
* Updated LAME encoder to v3.99.2 Final (2011-11-18), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.134))
* Updated MediaInfo to v0.7.51+ (2011-11-19), compiled with ICL 12.1.6 and MSVC 10.0
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))

[littleD]

Hello Lord Mulder, do you take in account Intel Hyperthreading? When i was compressing on corei3mobile 2cores/4threads with two cores set in lamexp, my cpu wasnt full utilised. When i set to 4 cores, cpu went on 100% and compressing was faster. Not big deal cause we can manualy set this option, but since you automate parallel instance count, You might consider Hyperthreading too. Wonder if same apply to bulldozer.

[LoRd_MuldeR]

Hello Lord Mulder, do you take in account Intel Hyperthreading? When i was compressing on corei3mobile 2cores/4threads with two cores set in lamexp, my cpu wasnt full utilised. When i set to 4 cores, cpu went on 100% and compressing was faster. Not big deal cause we can manualy set this option, but since you automate parallel instance count, You might consider Hyperthreading too. Wonder if same apply to bulldozer.

In general, Hyperthreading doesn't need any kind of special support. In theory, all applications with multi-core support will benefit automatically. So does LameXP :)

Hyperthreading simulates two "logical" cores for each "physical" one. But from the operating systems point of view, HT just doubles the number of CPU cores.

In "Auto" mode, LameXP will detect the number of CPU cores (using the GetNativeSystemInfo (http://msdn.microsoft.com/en-us/library/windows/desktop/ms724340%28v=vs.85%29.aspx) function ) and adjusts the maximum number of parallel instances accordingly.

The number of CPU cores reported by GetNativeSystemInfo() should include all CPU cores, e.g. on a Quadcore with HT enabled, it should report eight cores.

Consequently on your Dualcore "Core i3 Mobile" with HT - if it really does have HT (isn't that for the i5 M's only?) - LameXP should detect and use four cores/instances.

Still this is only a maximum! That maximum number of parallel instanced can only be reached, if the number of files transcoded "at once" is at least as high as the maximum.

Moreover: Up to and including LameXP v4.03, the upper bound for the maximum number of instances was four! I implemented a less restrictive formula in LameXP v4.04.

(Also note that, if you overwrite LameXP's decision by manually setting the number of instances, it will run exactly the number of instances you have configured!)

For details please see:
http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0

[littleD]

Yes, it works as u say in stable 4.03 release. My last version i used was beta-6 snapshot and i wasnt sure if my cpu threads was recognized properly. Now i can't verify, beta expired :) And nice cpu/ram usage indicator addon btw :)
First mobile hyperthreaded cpu was intel's 1st gen corei3 series if any wanna know.

[LoRd_MuldeR]

Note that you can always run LameXP with "--console" option to check the number of CPU cores that have been detected.

Output should look like this:
CPU vendor id : GenuineIntel (Intel: 1)
CPU brand string : Intel(R) Core(TM)2 Quad CPU @ 2.40GHz
CPU signature : Family: 6, Model: 15, Stepping: 7
CPU capabilities : MMX: 1, SSE: 1, SSE2: 1, SSE3: 1, SSSE3: 1, x64: 1
Number of CPU's : 4

[LoRd_MuldeR]

LameXP v4.04 Alpha-7:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (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)
* Updated LAME encoder to v3.99.2 Final (2011-11-18), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.134))
* Updated MediaInfo to v0.7.51+ (2011-11-19), compiled with ICL 12.1.6 and MSVC 10.0
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)

[Brazil2]

Then again when I'm editing tag infos on foobar there is always "LAME 32bits version 3.99.1 (http://lame.sf.net)" written in <encoding settings>. It would be cool if this could be personalized.
The encoding settings tag can be removed using the -t parameter:

-t disable INFO/WAV header

Disable writing of the INFO Tag on encoding.
This tag in embedded in frame 0 of the MP3 file. It includes some information about the encoding options of the file,
and in VBR it lets VBR aware players correctly seek and compute playing times of VBR files.

When '--decode' is specified (decode to WAV), this flag will disable writing of the WAV header.
The output will be raw PCM, native endian format. Use -x to swap bytes.

This is having a funny side effect though: if the encoding settings tag is present then the LAME version is reported with an "r" at the end (e.g. 3.98r, 3.99r), but if it's disabled then the full version of the encoder is shown (e.g. 3.98.4, 3.99.3). At least it works like that with LAME versions provided by Rarewares (http://www.rarewares.org/mp3-lame-bundle.php) and Jacek Pazera's Lame Front-End (http://www.pazera-software.com/products/lame-front-end/).

[LoRd_MuldeR]

These are two different things:

The so called "LAME header" is an extension of the good old "Xing/Info header". The format of the extended Xing header is described here:
http://gabriel.mp3-tech.org/mp3infotag.html

In the LAME tag there are only 9 characters for the version info. The format for the 'VersionString ' field used to be "LAME3.XXr", but there was some confusion about that recently:
http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=91372&view=findpost&p=775750

At the same time, the "long" version string, such as "LAME 32bits version 3.99.1 (http://lame.sf.net)", is included in a normal id3v2 tag.


ID3 (version 2) Tag:
http://img202.imageshack.us/img202/2999/zynamicshexer1402011120.png

Xing+LAME Header:
http://img248.imageshack.us/img248/2999/zynamicshexer1402011120.png

[VzK]

LoRd_MuldeR, thanks for the exhaustive answer.

One more thing:
http://i.imgur.com/Y2nU7.png

I read that foreign characters are supported, did I do something wrong?
»single flac to various mp3 » import cue sheet » write meta info to encoded files option, no m3u file generated. Used v4.04 Alpha-7.

[LoRd_MuldeR]

Could you upload/attach the problematic CUE file please as-is?

LameXP handles Unicode characters properly, as long as the input is in the proper UTF-8 (http://en.wikipedia.org/wiki/Utf-8) format. I suspect that this is not the case here :scared:

Currently LameXP will assume that the input is UTF-8, iff a BOM (http://en.wikipedia.org/wiki/Byte_order_mark) is found. Otherwise it will interpret the input with your local 8-Bit Codepage (http://en.wikipedia.org/wiki/Code_page) - whatever that may be.

I know this this isn't very reliable, but storing text files with some local 8-Bit Codepage is extremely error-prone anyway, because for the app reading the file later, it will be impossible to know the correct Codepage. Assuming that the "local" Codepage is the right one, is just a wild guess. But probably the best we can do.

Using Unicode with proper UTF-8 encoding is the right way to store text files that contain "foreign" (Non-ASCII) characters! And a BOM should be prepended to indicate that this is UTF-8. Still the BOM is optional. Assuming that all text without a BOM is not UTF-8, is another wild guess. But again I don't know a better way...

(BTW: As for the console, you won't see proper Unicode output there anyway, unless you change font to "Lucidia Console")


[Small Update]

I hacked together a quick workaround that may work for your case:
http://www.mediafire.com/file/pqfj5ok7ogsuahn/LameXP.2011-12-08.Release-Static.Build-803.exe

If LameXP assumes that the input is not UTF-8, it will now test whether decoding the input with the "local 8-Bit" Codepage results in any '�' (U+FFFD) characters. In that particular case we can assume that the "local 8-Bit" Codepage is not the suitable one and thus we will fall back to the "Latin-1" Codepage. There is absolutely no guarantee that the Latin-1 Codepage will work any better than the local one. It's just another try (and will succeed with Western European encodings).

[VzK]

http://i.imgur.com/LWWr7.jpg
http://i.imgur.com/EyMfa.png

Original cue attached if you want to give a look anyway.

Great work LoRd_MuldeR! Thanks a lot!

[LoRd_MuldeR]

As I had assumed, your CUE file is not Unicode/UTF-8, but plain Latin-1 ;)

On an English or German version of Windows (actually many more), the Latin-1 Codepage is configured as the "local" Codepage by default.

That's why, on such systems, decoding the file with the "local" Codepage gives the desired result. And one might assume that this is always the case.

But it's not! Other localized versions of Windows have a different Codepage configured by default, giving potentially very different output :angry:

Solution: Open the CUE file in Notepad++, change the Encoding to the suitable one (here Latin-1) and then convert to UTF-8 (Unicode), with BOM.

[LoRd_MuldeR]

LameXP v4.04 Alpha-7.1:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (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)
* Updated LAME encoder to v3.99.2 Final (2011-11-18), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.134))
* Updated MediaInfo to v0.7.51+ (2011-11-19), compiled with ICL 12.1.6 and MSVC 10.0
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)

[Dogway]

I wanted to ask if you are going to implement an option for audio alignment. I had a .wav, encoded with LameXP to AAC, decoded to WAV back again, and compared both WAV in Audacity, and the second one had around 36ms positive delay. I didn't know this so everything I have done til now might be wrong :eek:
I was also looking for a list to know which encoders/decoders you use for each format.

I gathered some links of interest.

Questions about H.264 sync
http://forum.doom9.org/showthread.php?t=156163
NeroAacEnc and delay added during encoding
http://forum.doom9.org/showthread.php?t=144346
audio delay with mp4box
http://forum.doom9.org/showthread.php?t=145435
Possible bug in nero encoder?
http://forum.doom9.org/showthread.php?p=1420989
Audio Sync for MP3 and AAC files in AVISynth
http://forum.doom9.org/showthread.php?p=1426169

[LoRd_MuldeR]

The extra delay is a common "problem" with (lossy) audio compression formats.

One reason for this is that these formats usually work with fixed-size (in samples) "frames", which they will transform into the frequency domain.

But, because of the properties of the transform, overlapped transforms must be used and a so-called "window" function must be applied on the samples first.

And for that reason, some extra samples before and after each frame are required. But before the very first frame, starting at the very first sample, there are none!

That's why the encoder will prepend some "silent" samples in front of the very first input sample. And also append some after the last input sample.

In the MP3 format, there is no "official" way to indicate how many extra samples were added, in order to have the decoder remove them. LAME has it's own way.

(Whether an individual MP3 decoder will respect LAME's extra info header, that's a different question ^^)

See also:
* http://cas.web.cern.ch/cas/Denmark-2010/Caspers/Tektronix%20%20primer%20on%20overlapping%20FFT%20signals%202009%20CAS2010.pdf
* http://lame.sourceforge.net/tech-FAQ.txt

[Dogway]

So good, so it is just as padding in video processing. Now I understood better but the question is, will you add an option for this?
And the next question, where can I see all the modules used for each format in LameXP in order to know the possible settings, flaws, pros, cons, etc whynots.

[LoRd_MuldeR]

So good, so it is just as padding in video processing. Now I understood better but the question is, will you add an option for this?

Add an option for what?

If an audio encoder prepends samples to the source, it does this for good reason. It's a consequence of how audio compression works (seep previous post).

There is no simple option to turn it off ;)

It is possible to cut off the padded samples later, after decoding. But only if the decoder can know how many samples had been added by the encoder.

And this is a decoder feature, which is out of scope for LameXP.

Unless, of course, we are talking about the decoding of the sources (original files) that you feed into LameXP for conversion.

Actually I'm not quite sure whether the individual decoders used in LameXP, e.g. mpg123 for MP3 files or FAAD for AAC files, do remove padding, if possible.

(At least for MP3 files encoded by LAME it is possible to accurately remove the padded samples at playback/decoding-time)

And the next question, where can I see all the modules used for each format in LameXP in order to know the possible settings, flaws, pros, cons, etc whynots.

What do you consider a module?

Anyway, all code of LameXP can be found at its Git repository:
https://github.com/lordmulder/LameXP

[Dogway]

Option to fix it. In post-processing for example, just an idea.

You don't know how the input was encoded, but you know how you are going to decode it (to wav) and encode it again. So there's room to make things nice in LameXP scope. I'm not sure, I just got to know about this bug (I consider it a bug) but I think the delay is a constant value (http://forum.doom9.org/showthread.php?p=1238245#post1238245)so with a few tests you can get to know. But it's up to you to decide if this is LameXP scope, right now I think I can't use it anymore for my videos audio. Now it's only useful for music audio, and individual tracks of course, if you encode a session composed of tracks LameXP won't be suited either...
Fortunately I now know about it, and can use workarounds, many people will still encode delayed audio without knowing aka doing the wrong thing.

In video processing we also add some padding for some filters to comply the mod 16 requirement, or just to protect borders. But the padding is always cropped back after filtering.


I think you call them Tools.
https://github.com/lordmulder/LameXP/tree/master/res/tools

You have some kind of a list more towards suppported formats rather than used tools for input/output formats
http://gitorious.org/lamexp/lamexp/blobs/987dce8c3b99540bc7671ad4635ed3887d71e999/doc/FAQ.html#line39

That can make the cut if I were to test for delay issues and flag options.

[LoRd_MuldeR]

Option to fix it. In post-processing for example, just an idea.

No, the "encoder delay" is not a bug. And thus there is no "fix" per se. As explained before, the padding is a direct consequence of how audio compression works. Let's not overstate things ;)

And to make that clear: Any MP3 encoder (e.g. LAME) will cause an "encoder delay", though the delay may differ between different encoders. Also the front-end (e.g. LameXP) has no influence on that.

The problem with MP3 in particular is that there is no "official" way to indicate the amount of padding that had been added by the encoder, so the decoder can't remove it!

AFAIK in the design of Vorbis this has been handled much better, i.e. the "encoder delay" is stored in the stream in a standardized way and thus it will be removed properly by the decoder.

I don't know what the situation with AAC is, but I guess it is more or less the same as with MP3...

Some more info:
http://en.wikipedia.org/wiki/Gapless_playback


You don't know how the input was encoded, but you know how you are going to decode it (to wav) and encode it again. So there's room to make things nice in LameXP scope. I'm not sure, I just got to know about this bug (I consider it a bug) but I think the delay is a constant value so with a few tests you can get to know. But it's up to you to decide if this is LameXP scope, right now I think I can't use it anymore for my videos audio. Now it's only useful for music audio, and individual tracks of course, if you encode a session composed of tracks LameXP won't be suited either...
Fortunately I now know about it, and can use workarounds, many people will still encode delayed audio without knowing aka doing the wrong thing.

The processing chain is as follows:
Decode input -> Apply filters (if any) -> Encode output

The "encoder delay" is added in the very last step, so it is impossible to implement any workaround, obviously. Except having LAME add it's header to the MP3 file - which it does by itself.

Actually I just made a quick test and, indeed, the 'mpg123' decoder will respect the LAME header. Thus, if a LAME header is present, the padding samples are removed :cool:

If you encode a Wave file to MP3 with LameXP (and thus with LAME) and then decode that MP3 file to Wave again with LameXP (and thus with mpg123), the sample count remains unchanged!

You can try yourself with:
lame.exe -V2 uncompressed.wav compressed.mp3
mpg123.exe -v -w decompressed.wav compressed.mp3

You will see that "uncompressed.wav" and "decompressed.wav" will have to exactly same size in bytes. And in the audio editor you can check that they are perfectly aligned.

That's as much as we can do :)

(If some other decoder will be used to decode the MP3 files produced by LameXP/LAME and that decoder ignores the LAME header, then we cannot do anything about that)

[LoRd_MuldeR]

LameXP v4.04 Alpha-8:
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2011-12-10/

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (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)
* Updated LAME encoder to v3.99.2 Final (2011-11-18), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.134))
* Updated MediaInfo to v0.7.51+ (2011-11-19), compiled with ICL 12.1.6 and MSVC 10.0
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)

Found a bug that caused LameXP to never use the local 8-Bit Codepage when importing a Cue Sheet or Playlist. Instead UTF-8 was tried twice :o

This has been fixed. Also, when importing a Cue Sheet that is not UTF-8 with a proper BOM, LameXP will now allow the user to choose the desired 8-Bit Codepage.

For everybody who doesn't know what that means: You can simply keep "(System Default)" and click 'OK' when the Codepage dialog pops up ;)

[VzK]

Updated. :)

Found a typo:
http://i.imgur.com/Fs1Za.png

[LoRd_MuldeR]

Thank you. Fixed ;)
https://github.com/lordmulder/LameXP/commit/caabab7adf255f274350d4383bbf9d15f92e5bd1#diff-9

BTW, I added some info about the "encoder delay" to 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#c6d9dfed

[Reimar]

Using Unicode with proper UTF-8 encoding is the right way to store text files that contain "foreign" (Non-ASCII) characters! And a BOM should be prepended to indicate that this is UTF-8. Still the BOM is optional. Assuming that all text without a BOM is not UTF-8, is another wild guess. But again I don't know a better way...

I don't think that is correct, a BOM for UTF-8 to my knowledge is not only not necessary but actually invalid (it certainly does not serve as BOM, there is no byte order to mark for UTF-8).
In addition UTF-8 can be autodetected quite reliably, if you can parse it correctly as UTF-8 and you test text contains characters outside the ASCII range (>127) it almost certainly is UTF-8.

[Dogway]

Thank you. Fixed ;)
https://github.com/lordmulder/LameXP/commit/caabab7adf255f274350d4383bbf9d15f92e5bd1#diff-9

lol you never sounded so receptive when I noted similar typos... just curious : P

-Typo in Show Dropbox in Spanish would be "Mostrar DropBox"
Feel free to update the language file according to the translator's guide:
http://mulder.brhack.net/public/doc/lamexp_translate.html

[mariush]

I don't think that is correct, a BOM for UTF-8 to my knowledge is not only not necessary but actually invalid (it certainly does not serve as BOM, there is no byte order to mark for UTF-8).
In addition UTF-8 can be autodetected quite reliably, if you can parse it correctly as UTF-8 and you test text contains characters outside the ASCII range (>127) it almost certainly is UTF-8.

http://en.wikipedia.org/wiki/Byte_order_mark#UTF-8

0xEF,0xBB,0xBF is a valid combination to represent UTF-8 content.


The UTF-8 representation of the BOM is the byte sequence 0xEF,0xBB,0xBF. A text editor or web browser interpreting the text as ISO-8859-1 or CP1252 will display the characters  for this.

The Unicode Standard does permit the BOM in UTF-8,[2] but does not require or recommend its use.[3] Byte order has no meaning in UTF-8[4] so in UTF-8 the BOM serves only to identify a text stream or file as UTF-8.

One reason the UTF-8 BOM is not recommended is that many pieces of software without Unicode support nevertheless are able to handle UTF-8 inside a text but not at the start of a text. For instance, the bytes of UTF-8 can be placed between the quotes of string constants in many programming languages, and that language will write the correct UTF-8 to a file or to a display, despite the language not knowing anything about UTF-8. This provides an easy migration path to convert systems to Unicode and to remove all legacy encodings, without simultaneously upgrading the programming language. The unexpected three bytes of the BOM break this however, as they are located where they are certain to be a syntax error.

A leading BOM can also defeat software that uses pattern matching on the start of a text file, since it inserts 3 bytes before the pattern. Though commonly associated with the Unix shebang at the start of an interpreted script,[5] the problem is more widespread. For instance in PHP, the existence of a BOM will cause the page to begin output before the initial code is interpreted, causing problems if the page is trying to send custom HTTP headers (which must be set before output begins).

Many Windows programs (including Windows Notepad) add BOMs to UTF-8 files by default[citation needed].

[LoRd_MuldeR]

@Reimar:
Yes, the BOM symbol in UTF-8 does not serve to indicate the Byte Order (there is no Byte Order in single-byte sequences, yes) and it's optional. Still it's a valid character and often present. So if an UTF-8 BOM is found, we can assume that the text is UTF-8 indeed. The probability to find a UTF-8 BOM sequence just "by chance" is negligible. In the other case, when there is no UTF-8 BOM present, the text may still be valid UTF-8. But it maybe "some" local 8-Bit codepage just as well. It may not even be encoded in the Windows ANSI Codepage that happens to be configured on the individual computer. For all these reasons, if no UTF-8 BOM is found, LameXP will now pop up a small dialog, allowing the user to select the desired Codepage.

@Dogway:
I'm always thankful for bug-reports, including typos. But, as a matter of fact, I can only update the English and German translations. For all other languages I have to rely on other people to send my updated/corrected language files :o

[mariush]

Mulder, ideally you should show a window with a preview updated automatically when use selects a different codepage from a drop down list...

[LoRd_MuldeR]

Mulder, ideally you should show a window with a preview updated automatically when use selects a different codepage from a drop down list...

Ideally I should. Practically I think that is "nice to have" but over the top :)

[Brazil2]

LameXP v4.04 Alpha-8:
* Updated LAME encoder to v3.99.2 Final (2011-11-18), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.134))
FYI LAME v3.99.3 is out since 2011-11-26:
http://sourceforge.net/projects/lame/files/lame/3.99/lame-3.99.3.tar.gz/download
;)

[LoRd_MuldeR]

FYI LAME v3.99.3 is out since 2011-11-26:
http://sourceforge.net/projects/lame/files/lame/3.99/lame-3.99.3.tar.gz/download
;)

Compared to 3.99.2 there only was one minor fix that doesn't effect LameXP.
LAME 3.99.3 November 26 2011
Fix for tracker item [ 3441349 ] --tg does not handle genre number when adding unicode tag

(LameXP doesn't pass genres by number)

[Reimar]

@Reimar:
Yes, the BOM symbol in UTF-8 does not serve to indicate the Byte Order (there is no Byte Order in single-byte sequences, yes) and it's optional. Still it's a valid character and often present.

Yes, I was slightly off, it is not invalid it just is "not recommended".

In the other case, when there is no UTF-8 BOM present, the text may still be valid UTF-8. But it maybe "some" local 8-Bit codepage just as well. It may not even be encoded in the Windows ANSI Codepage that happens to be configured on the individual computer. For all these reasons, if no UTF-8 BOM is found, LameXP will now pop up a small dialog, allowing the user to select the desired Codepage.

Yes, that is a sensible solution. However the chances that a string containing a character of value > 127 parses as UTF-8 but is not UTF-8 is almost as negligible as the chances that something starting with UTF-8 BOM code is not UTF-8, since UTF-8 is a rather inefficient and wasteful encoding. (the first byte of value > 127 - which must at least have a value of 247 IIRC - indicates how many following bytes start with the bit pattern 10 - you'll have a hard time finding a word in any language in any encoding - except UTF-8 of course - that happens to conform to this).
For purely random data you should reach the same confidence as a UTF-16 BOM at about 8 bytes > 127 and the same as UTF-8 BOM at about 12.
But enough side-tracking, I'll shut up now and let you all get back to the topic.

[LoRd_MuldeR]

Yes, I was slightly off, it is not invalid it just is "not recommended".

Well, at least on Windows, having an UTF-8 BOM is quite common. For example, the Windows Notepad does add a BOM to UFT-8 files. Winamp does add it to .m3u8 playlists as well.

Last but not least, Notepad++ supports normal "UTF-8" (that is with BOM) and "UTF-8 without BOB" (aka "ANSI as UTF-8").

Yes, that is a sensible solution. However the chances that a string containing a character of value > 127 parses as UTF-8 but is not UTF-8 is almost as negligible as the chances that something starting with UTF-8 BOM code is not UTF-8, since UTF-8 is a rather inefficient and wasteful encoding. (the first byte of value > 127 - which must at least have a value of 247 IIRC - indicates how many following bytes start with the bit pattern 10 - you'll have a hard time finding a word in any language in any encoding - except UTF-8 of course - that happens to conform to this).
For purely random data you should reach the same confidence as a UTF-16 BOM at about 8 bytes > 127 and the same as UTF-8 BOM at about 12.
But enough side-tracking, I'll shut up now and let you all get back to the topic.

Deciding whether something will decode as valid UTF-8 or not isn't that trivial tough. Especially as I'm not planning to reinvent the wheel and implement my own UTF-8 decoder. Instead I just select the desired QTextCodec class and let it do its job. Also, as far as I understand, UTF-8 was designed in a way to allow for easy resynchronization after "invalid" or "missing" bytes. So decoding errors at one point don't necessarily mean that the rest can't be valid UTF-8...

[ToMaZz]

Hello again,

Is there any possibility to have .m4a extensions instead of .mp4 with NeroAAC codec? :rolleyes:
It is painfull because iTunes and some other apps treats mp4 as video file, so for example I cannot change cover for it like for m4a.

As a workaround I'm using some files renamer after every encoding with great LameXP. ;)

[SeeMoreDigital]

Hello again,
Hello again... This is your first post on the forum!

Is there any possibility to have .m4a extensions instead of .mp4 with NeroAAC codec?
LoRd_MuldeR has made it quite clear in the past that he wont do this

[LoRd_MuldeR]

Please see here:
http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#126abc5a

And here:
http://en.wikipedia.org/wiki/MPEG-4_Part_14#.MP4_versus_.M4A_filename_extensions

[LoRd_MuldeR]

LameXP v4.04 Alpha-9:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (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)
* Updated LAME encoder to v3.99.2 Final (2011-11-18), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.134))
* Updated MediaInfo to v0.7.51+ (2011-11-19), compiled with ICL 12.1.6 and MSVC 10.0
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)

Added proper support for UTF16 (LE and BE) encodings to the Playlist and Cue Sheet importer.

[ToMaZz]

Hello again... This is your first post on the forum!

It was on some LameXP/author homepage in the past - not on this forum.

Please see here:
http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#126abc5a

And here:
http://en.wikipedia.org/wiki/MPEG-4_Part_14#.MP4_versus_.M4A_filename_extensions

Thanks for reply. I see now that mp4 is correct extension.
..but still you can make life easier for users of LameXP by adding option of using incorrect m4a extension instead.
After weeks of using file renamer (allways after encoding) it is more and more irritating and painfull to do it manualy again.. and again.. and so on. ;)

[LoRd_MuldeR]

LameXP v4.04 Alpha-10

Added Chinese translation:
http://img585.imageshack.us/img585/429/lxpzh.jpg