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

[SeeMoreDigital]

Just a heads up ... they updated the FLAC library last month to 1.3.0, first update in 6 years apparently and the first performed by xiphorg maintainer team: https://xiph.org/flac/changelog.htmlNice one...

[Octo-puss]

The quality should remain the same though, flac being a lossless codec?... As in, there's no reason to reencode my discs even if this was seemingly pretty big update.

[LoRd_MuldeR]

The quality should remain the same though, flac being a lossless codec?...

It's lossless. So ;)

(In theory it is still possible that the old version had a bug that sometimes caused "wrong" output that has been fixed now. But I don't see anything like that on the changelog. So there really should be no difference in the quality)

As in, there's no reason to reencode my discs even if this was seemingly pretty big update.

From what I see, they mainly improved the CLI front-end, e.g. to support Unicode file names on Windows and to support Wave64/RF64 files. Also there were a bunch of build fixes. But I don't see anything that says "improved compression by X percent in average", so I don't see a reason to re-encode existing FLAC files.

[LoRd_MuldeR]

LameXP v4.08 Alpha-2:

Changes between v4.07 and v4.08 [unreleased]:
* Updated FLAC encoder/decoder to v1.3.0 (2013-05-27), compiled with ICL 13.0

[LoRd_MuldeR]

LameXP v4.08 Alpha-3:
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2013-06-17/

Changes between v4.07 and v4.08 [unreleased]:
* Updated FLAC encoder/decoder to v1.3.0 (2013-05-27), compiled with ICL 13.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-06-17)
* Fixed a superfluous "beep" sound that appeared on application startup

[Dogway]

Some suggestions over the span of years of use.

-Remove all the bells & whistles that I need to turn off every time I install a new version (actually main reason I don't update to new version), they make the software look amateurish as well. Minimalism is a plus.
-Remove the autosetted "Encoded with LameXP", it's annoying and extra work for people, it also makes it look as if you had ego issues.
-Allow m4a as AAC container, even it's not speced, it's a pain to have 2 (or 10) files on one folder without knowing whether they are audio or video. Some people me included don't use the same program to play each.
-Expose the real settings for AAC: VBR, TVBR, the Q scale 0-123 or 0-127, etc
-Launch is SLOW, probably because you decompress all the compressed executables. Not only it is slow, but it will wear SSD, and really, was all that necessary? Let the executables rest in a folder.
-Every time I choose an encoder my last used settings are removed.

I know that in an outburst of arrogance you will try to refute each of these and tell NO, NO, NO. But I had to note them down somewhere, and this is the thread. I'm sure I'm not the only one with these little annoyances, but anyway, take it or leave it.

[LoRd_MuldeR]

First of all I think that feature requests for a software that is offered to you for free could be brought up a bit more kindly.

Especially when you are complaining about program features/shortcomings without contributing any solutions, e.g. in form of patches or cash ... :scared:

But anyway:

-Remove all the bells & whistles that I need to turn off every time I install a new version (actually main reason I don't update to new version), they make the software look amateurish as well. Minimalism is a plus.

I'm not sure what "bells & whistles" is supposed to mean, but if you are referring to the fact that the application settings ate stored separately for each major version of LameXP, then that is by design - since settings between different versions of the program may be incompatible and this way we avoid problems. But how often does a new version major come out? Maybe three times a year. Is it that hard to change a few settings three times a year?

(If you don't want to participate in the development of the software, just don't gab every Alpha/Beta update, wait for the "Final" release - although your settings shouldn't "get lost" within a major version now)

-Remove the autosetted "Encoded with LameXP", it's annoying and extra work for people, it also makes it look as if you had ego issues.

I think some subtle and non-intrusive "promotion" must be allowed.

In case you want to embed an album- or title-specific comment, you have to edit the comment for every album/title anyway, right?

Otherwise, having the default comment embedded doesn't take away anything, does it ???

(If you want to be that ungrateful, you can still change the default comment in the source code. That should be a one-liner, even for the non-programmer)

-Allow m4a as AAC container, even it's not speced, it's a pain to have 2 (or 10) files on one folder without knowing whether they are audio or video. Some people me included don't use the same program to play each.

See here:
http://lamexp.sourceforge.net/doc/FAQ.html#126abc5a

I'm not going to change LameXP to output MP4 files with a wrong extension.

But maybe the existing "auto rename" feature can be extended to cover the file extension as well, which should be sufficient to handle this case for those who really need it.

-Expose the real settings for AAC: VBR, TVBR, the Q scale 0-123 or 0-127, etc

I think those are specific to QAAC. LameXP supports multiple AAC encoders with Nero AAC being the default.

Thus naming the option specifically for QAAC would be a bad idea, obviously.

The settings offered in the GUI are something like a "smallest common denominator" for all supported encoders and they are mapped to the specific settings of the individual encoder internally.

-Launch is SLOW, probably because you decompress all the compressed executables.

If ~2 seconds startup time (with A/V enabled) and almost instantaneously (with A/V disabled) is "slow", well, then 99.9% of all applications are that way.

The program is starting up slower on your systems? Don't shooting the messenger! Get your system fixed...

Most common cause of surprisingly slow performance is slow/buggy A/V software, but I have explained that about a hundred times.

(And I currently have no plans to change the "fully-selfcontained" design of LameXP)

See also:
http://muldersoft.com/temp/lamexp_startup.htm - note that you may need to zoom out a bit

Not only it is slow, but it will wear SSD, and really, was all that necessary? Let the executables rest in a folder.

You must be joking. SSD's are created to write several gigabytes of data every day, for a usage period of ~5 years. And all tests I have seen so far indicate all current SSD's handle this flawlessly.

Actually, in the "torture test" they were unable to "break" any of the SSD's, even when filling them with random data over and over again. Only some SSD's lost some performance over time, probably due to Firmware bugs.

Also your web-browser cache alone probably writes more data to the HDD/SSD within a few minutes of normal usage than starting up LameXP does. Let alone all the other applications, hibernation, etc...

Honestly, I have my SSD for ~3 years now (as system drive) and I use this machine heavily for software development and everything else 24/7. Guess what, in 3 years the "wear out" indicator has decreased from 100% to 98%. Wow!

The super-paranoid user still may move its TEMP directory away from the SSD (system drive) to a classical HDD partition. Just edit %TMP% as desired...

-Every time I choose an encoder my last used settings are removed.

No idea what that is supposed to mean, but probably relates to the first point.

[mike20021969]

If ~2 seconds startup time (with A/V enabled) and almost instantaneously (with A/V disabled) is "slow", well, then 99.9% of all applications are that way.

The program is starting up slower on your systems? Don't shooting the messenger! Get your system fixed...


2 seconds? Then it has always "launched slow" for me too (around 17 seconds).

Adobe Audition launches in <5 seconds.

My system runs flawlessly. So what sort of things are we supposed to be looking out for to "get fixed"?

[LoRd_MuldeR]

As you can see here, I get around ~2 seconds with A/V enabled and almost no delay without A/V:
See also:
http://muldersoft.com/temp/lamexp_startup.htm - note that you may need to zoom out a bit

That is on my antiquated Q6600 and using a rather old 40 GB Intel SSD from around 2010. But it seems the SSD doesn't make much of a difference here, since I still get the same speeds when I move %TMP% to my HDD. That's probably because the amount of data written by LameXP is too small and thus still fits into the HDD's write cache.

The most important factor, in my experience, is anti-virus software. Some are unbearably slow! Among those with acceptable speed, in my own experience, are Avira and MSE. But I suggest to try yourself...

(In essence, try to temporarily disable/uninstall everything that hooks into other processes and potentially effects I/O behavior!)

[mike20021969]

As you can see here, I get around ~2 seconds with A/V enabled and almost no delay without A/V:

Yeah, it looks like AVG does delay that start up time.

Disabling it makes LameXP launch in ~4 seconds :)

Why would it (AVG/AntiVirus) affect LameXP more than other programs?

[LoRd_MuldeR]

Yeah, it looks like AVG does delay that start up time.

Disabling it makes LameXP launch in ~4 seconds :)

That's consistent with my experience of AVG's slowness. At least they stopped defaming LameXP as being malware :p

Why would it (AVG/AntiVirus) affect LameXP more than other programs?

Hard to say without knowing their code ;)

Maybe a "smart" A/V software remembers the Hash (e.g. Sha-2) of files it already scanned earlier and found to be "clean". So when the same file is encountered again later (even at a different location!), only the Hash needs to be computed (very fast) but the actual "scan" (slow) can be skipped this time. Other A/V software may not be that smart and re-scan the same file over and over again. Just like Sisyphus.

Another possibility: A/V software #1 may be paranoid and scan the file as soon as it's written to the disk, e.g. when the file is about to be closed after the writing operation. Of course this unnecessarily delays the fclose() operation and thus the whole "extraction" process! A/V software #2 might be a bit more intelligent and scan the file only when it actually is accessed for reading, thus not delaying the "extraction" process at all. This will move the "delay" to a later time though. Actually, A/V software #3 might be even smarter: It waits until the file has been written and has been closed, then scans the file in parallel (without blocking anything!). And when the file is access for reading later, it probably has been scanned already.

Last but not least, the pure processing speed of the "scanning" engines used by different A/V programs may simply be different. Some even have to talk to a server for getting the job done...

[LoRd_MuldeR]

LameXP v4.08 Alpha-4:

Changes between v4.07 and v4.08 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-3
* Updated Qt runtime libraries to v4.8.5 RC-1 (2013-05-31), compiled with MSVC 11.0
* Updated FLAC encoder/decoder to v1.3.0 (2013-05-27), compiled with ICL 13.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-06-17)
* Fixed a potential deadlock during startup when %TMP% points to an invalid folder
* Fixed a superfluous "beep" sound that appeared on application startup

[trunket]

Hi LoRd_MuldeR,

Thank you for your great LameXP app. I've been going through this rather long thread looking for some things I'd like to see in LameXP, but since I couldn't find it very well I am taking the risk of mentioning something that has already been brought up before. So that was my disclaimer :)

Anyway, I was wondering if you would mind adding the option to retain encoding settings/options for the various encoders. In the config.ini file (whether using portable or regular version) it does list the settings when I set them, but when I change to encode from, say, MP3 to FLAC, and I go back to MP3, the settings I had previously used are reset again to your/the app's defaults or something. Why is this? To me, if one has a specific encoding option in mind per track, it would be logical to check and change the settings, yes. But if you have found a good overall encoding method for your portable player or PC or what have you, it is far more likely to choose that encoding method again than it is to not use it again. Since with your method (of not saving personal settings when switching between formats) you'd have to change encoding options anyway, it wouldn't negatively impact anyone preferring your method :) So, clearly this speaks in favor of retaining encoding options for each encoder. I hope you understand what I was trying to say :)

Further I applaud you for adding many detailed options for encoding into your app (like all the channel modes for LAME, etc.) which is something I much appreciate. I always keep a local copy of your app around (I use several quality frontends) and made a little icon for my own LameXP app folder:
http://img835.imageshack.us/img835/1622/r86n.png (http://imageshack.us/photo/my-images/835/r86n.png/)

EDIT: I noticed I couldn't turn off/unselect checking for (Beta) updates in your latest development release. Is this by design? I'd like to turn it off for my local copy, regardless of it being a development release. My reasoning is (not unlike with the encoding settings argument) that if one wants to try developmental releases, one should understand there will be subsequent (and more stable) releases. I guess I just have this 'thing' about having to be able to turn off online checking with any app ;)

[LoRd_MuldeR]

Anyway, I was wondering if you would mind adding the option to retain encoding settings/options for the various encoders. In the config.ini file (whether using portable or regular version) it does list the settings when I set them, but when I change to encode from, say, MP3 to FLAC, and I go back to MP3, the settings I had previously used are reset again to your/the app's defaults or something. Why is this? To me, if one has a specific encoding option in mind per track, it would be logical to check and change the settings, yes. But if you have found a good overall encoding method for your portable player or PC or what have you, it is far more likely to choose that encoding method again than it is to not use it again. Since with your method (of not saving personal settings when switching between formats) you'd have to change encoding options anyway, it wouldn't negatively impact anyone preferring your method :) So, clearly this speaks in favor of retaining encoding options for each encoder. I hope you understand what I was trying to say :)

It's not that the settings get reset when you change the encoder. It's simply that LameXP currently does not store the encoder settings (encoding mode + bitrate/quality value) separately for each encoder. Instead it's stored only once! So if you switch from MP3 to, e.g., FLAC, then move the bitrate/quality slider and finally switch back to MP3, your MP3 settings have changed too. Same goes with the encoding mode (CBR vs. ABR vs. VBR). I could change the program to maintain the state separately for each encoder, but this will require quite some work...

EDIT: I noticed I couldn't turn off/unselect checking for (Beta) updates in your latest development release. Is this by design? I'd like to turn it off for my local copy, regardless of it being a development release. My reasoning is (not unlike with the encoding settings argument) that if one wants to try developmental releases, one should understand there will be subsequent (and more stable) releases. I guess I just have this 'thing' about having to be able to turn off online checking with any app ;)

Yes, it is by design. With stable versions you can choose whether you want to check for updates in the "default" or the "beta" channel. Only the latter will find pre-release (Beta) updates, while the former is restricted to new stable versions. However, once you have a beta version installed, it only makes sense to check the "beta" channel for updates. That's because beta versions always are newer than the latest stable release, so you can never find any updates for beta versions in the "default" channel. Note that when there currently are no new beta versions available (e.g. shortly after a release), then both, the "default" and "beta" channel, simply point to the latest stable release. It's also during that "phase" when old beta versions (older than the current stable release) will update to the current stable release...

[trunket]

So if you switch from MP3 to, e.g., FLAC, then move the bitrate/quality slider and finally switch back to MP3, your MP3 settings have changed too. Same goes with the encoding mode (CBR vs. ABR vs. VBR). I could change the program to maintain the state separately for each encoder, but this will require quite some work...
OK, so I would think it'd be a great thing to save the settings if possible. All the other frontends I've used do retain such settings even when switching between formats, and I think *most* people are looking for this or expecting this. But I understand if it is hard to do. When I looked at your config.ini file (I was using the portable version you made) I was seeing things like: AdvancedOptions\LAME\ChannelMode=0 so I was thinking maybe do the same for just LAME\VBR\ etc. so when switching back to LAME from another format, it will pick up the settings from there again.

Yes, it is by design. With stable versions you can choose whether you want to check for updates in the "default" or the "beta" channel. Only the latter will find pre-release (Beta) updates, while the former is restricted to new stable versions. However, once you have a beta version installed, it only makes sense to check the "beta" channel for updates. That's because beta versions always are newer than the latest stable release, so you can never find any updates for beta versions in the "default" channel. Note that when there currently are no new beta versions available (e.g. shortly after a release), then both, the "default" and "beta" channel, simply point to the latest stable release. It's also during that "phase" when old beta versions (older than the current stable release) will update to the current stable release...

OK, I understand then ;)

[LoRd_MuldeR]

LameXP v4.08 Alpha-6:

Changes between v4.07 and v4.08 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-3
* Encoder settings (RC mode + bitrate/quality) are now stored separately for each encoder
* Updated Qt runtime libraries to v4.8.5 RC-1 (2013-05-31), compiled with MSVC 11.0
* Updated FLAC encoder/decoder to v1.3.0 (2013-05-27), compiled with ICL 13.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-06-17)
* Fixed a potential deadlock during startup when %TMP% points to an invalid folder
* Fixed a superfluous "beep" sound that appeared on application startup
* Fixed Ogg Vorbis quality modes "-1" and "-2" (they were clipped to "0" before)
* Fixed a bug that could cause the output directory to be reset mistakenly

[LoRd_MuldeR]

LameXP v4.08 Beta-1:

Changes between v4.07 and v4.08 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-3
* Encoder settings (RC mode + bitrate/quality) are now stored separately for each encoder
* Updated Qt runtime libraries to v4.8.5 (2013-05-31), compiled with MSVC 11.0
* Updated FLAC encoder/decoder to v1.3.0 (2013-05-27), compiled with ICL 13.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-07-10)
* Updated MediaInfo to v0.7.64 (2013-07-05), compiled with ICL 13.1 and MSVC 10.0
* Updated GNU Wget binary to v1.13.4 (2011-09-17)
* Fixed a potential deadlock during startup when %TMP% points to an invalid folder
* Fixed a superfluous "beep" sound that appeared on application startup
* Fixed the Ogg Vorbis quality modes "-1" and "-2" (those were clipped to "0" before)
* Fixed a bug that could cause the output directory to be reset mistakenly

[rhaz]

Hi. Latest stable version fails at decoding MP3s to WAVs, I tried now the latest 30-day beta version and it works fine. Also Drag&Drop do not work in both stable and beta on Win8x64. When dragging .mp3 onto the box or program window, simply nothing happens.

[manolito]

Works fine here (WinXP SP3)...:confused:

Latest stable version 4.07. MP3 to WAV no problems, does not matter if normalization is checked or not. Drag and Drop also working fine here.

I suppose there is something going on about your system...


Cheers
manolito

[rhaz]

Also 'Browse Output File Location' doesn't work. And XP and Win8 are a bit different I'd say, not same. So if it works on XP it doesn't mean anything.

[LoRd_MuldeR]

Hi.

MP3 to Wave works fine me. So what exactly does not work for you? And what does your log say? :confused:

As for Drag&Drop, works fine for me on Windows XP, Windows 7 and Windows 8.

However be sure you do not launch LameXP with elevated rights, as this would "block" Drag&Drop (besides that it is not needed at all).

"Browse Output File Location" also works for me just fine on Windows 8...

[mastrboy]

Can lamexp handle m2ts (pcm, blu ray files) for input?
So tired of writing cmd scripts for eac3to :P

[LoRd_MuldeR]

Can lamexp handle m2ts (pcm, blu ray files) for input?

Nope. You'll need to demux the audio stream with something like tsMuxeR (http://www.videohelp.com/tools/tsMuxeR) first.

[SeeMoreDigital]

I got a new build today 4.08 Beta-2 dated 2013-07-23.... ;)

[LoRd_MuldeR]

I got a new build today 4.08 Beta-2 dated 2013-07-23.... ;)

So? :confused:

[LoRd_MuldeR]

LameXP v4.08 Beta-2:

Changes between v4.07 and v4.08 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-3
* Encoder settings (RC mode + bitrate/quality) are now stored separately for each encoder
* Updated Qt runtime libraries to v4.8.5 (2013-05-31), compiled with MSVC 11.0
* Updated FLAC encoder/decoder to v1.3.0 (2013-05-27), compiled with ICL 13.0
* Updated Opus encoder/decoder libraries to v1.1-beta and Opus-Tools to v0.1.6 (2013-07-22)
* Updated MediaInfo to v0.7.64 (2013-07-05), compiled with ICL 13.1 and MSVC 10.0
* Updated GNU Wget binary to v1.13.4 (2011-09-17)
* Fixed a potential deadlock during startup when %TMP% points to an invalid folder
* Fixed a superfluous "beep" sound that appeared on application startup
* Fixed the Ogg Vorbis quality modes "-1" and "-2" (those were clipped to "0" before)
* Fixed a bug that could cause the output directory to be reset mistakenly

[LoRd_MuldeR]

LameXP v4.08 RC-1:

Changes between v4.07 and v4.08 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-3
* Encoder settings (RC mode + bitrate/quality) are now stored separately for each encoder
* Updated Qt runtime libraries to v4.8.5 (2013-05-31), compiled with MSVC 11.0
* Updated FLAC encoder/decoder to v1.3.0 (2013-05-27), compiled with ICL 13.0
* Updated Opus encoder/decoder libraries to v1.1-beta and Opus-Tools to v0.1.6 (2013-07-22)
* Updated MediaInfo to v0.7.64 (2013-07-05), compiled with ICL 13.1 and MSVC 10.0
* Updated GnuPG to v1.4.14 (2013-07-25), compiled with GCC 4.8.1
* Updated GNU Wget binary to v1.13.4 (2011-09-17)
* Fixed a potential deadlock during startup when %TMP% points to an invalid folder
* Fixed a superfluous "beep" sound that appeared on application startup
* Fixed the Ogg Vorbis quality modes "-1" and "-2" (those were clipped to "0" before)
* Fixed a bug that could cause the output directory to be reset mistakenly

[LoRd_MuldeR]

LameXP v4.08 RC-2:

Changes between v4.07 and v4.08 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-3
* Encoder settings (RC mode + bitrate/quality) are now stored separately for each encoder
* Updated Qt runtime libraries to v4.8.5 (2013-05-31), compiled with MSVC 11.0
* Updated FLAC encoder/decoder to v1.3.0 (2013-05-27), compiled with ICL 13.0
* Updated Opus encoder/decoder libraries to v1.1-beta and Opus-Tools to v0.1.6 (2013-07-22)
* Updated MediaInfo to v0.7.64 (2013-07-05), compiled with ICL 13.1 and MSVC 10.0
* Updated GnuPG to v1.4.14 (2013-07-25), compiled with GCC 4.8.1
* Updated GNU Wget binary to v1.13.4 (2011-09-17)
* Updated language files (big thank-you to all contributors !!!)
* Fixed a potential deadlock during startup when %TMP% points to an invalid folder
* Fixed a superfluous "beep" sound that appeared on application startup
* Fixed the Ogg Vorbis quality modes "-1" and "-2" (those were clipped to "0" before)
* Fixed a bug that could cause the output directory to be reset mistakenly
* Implemented "natural order" string comparison/sorting, using strnatcmp() by Martin Pool

[LoRd_MuldeR]

LameXP v4.08 has been released :)
http://lamexp.sourceforge.net/ | http://lamexp.berlios.de/

Changes between v4.07 and v4.08 [2013-09-04]:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-3
* Encoder settings (RC mode + bitrate/quality) are now stored separately for each encoder
* Updated Qt runtime libraries to v4.8.5 (2013-05-31), compiled with MSVC 11.0
* Updated FLAC encoder/decoder to v1.3.0 (2013-05-27), compiled with ICL 13.0
* Updated Opus encoder/decoder libraries to v1.1-beta and Opus-Tools to v0.1.6 (2013-07-22)
* Updated MediaInfo to v0.7.64 (2013-07-05), compiled with ICL 13.1 and MSVC 10.0
* Updated GnuPG to v1.4.14 (2013-07-25), compiled with GCC 4.8.1
* Updated GNU Wget binary to v1.13.4 (2011-09-17)
* Updated language files (big thank-you to all contributors !!!)
* Fixed a potential deadlock during startup when %TMP% points to an invalid folder
* Fixed a superfluous "beep" sound that appeared on application startup
* Fixed the Ogg Vorbis quality modes "-1" and "-2" (those were clipped to "0" before)
* Fixed a bug that could cause the output directory to be reset mistakenly
* Implemented "natural order" string comparison/sorting, using strnatcmp() by Martin Pool

[Octo-puss]

Please don't forget to update the portable build as well :P

[LoRd_MuldeR]

I have uploaded a new "portable" build.

[Octo-puss]

Thank you!

[Motenai Yoda]

Hi! With the 4.0.8 final-1 it doesn't recognize fhgaac (I'm on w8).

Also as Dogway has claimed required, why don't change the slider's scale for each aac encoder? (now I don't know how it works, but if is by lists of possibly values as I think, should be quite simple to add an if, or a switch case, statements to change them.)

byez

[LoRd_MuldeR]

Hi! With the 4.0.8 final-1 it doesn't recognize fhgaac (I'm on w8).

Works for me :confused:

Are you 100% sure all the required DLL files are in the correct place?

http://i.imgur.com/ixsJm0dl.jpg (http://i.imgur.com/ixsJm0d.jpg)
http://i.imgur.com/jWaFHXel.jpg (http://i.imgur.com/jWaFHXe.jpg)

Also as Dogway has claimed required, why don't change the slider's scale for each aac encoder? (now I don't know how it works, but if is by lists of possibly values as I think, should be quite simple to add an if, or a switch case, statements to change them.)

Surely, this would be possible. But it would be bad designed, since it adds even more complexity to the GUI code.

I rather prefer to keep the GUI code agnostic of the specific AAC encoder and, instead, keep the details in the individual encoder class.

The ultimate goal is to keep the GUI code completely agnostic of any encoder. But this will require a new "configuration options" interface to be implemented by the encoder classes, so the GUI can query the supported encoding modes, the supported bitrates as well as the supported VBR levels from the selected encoder - rather than having all that knowledge hardcoded in the GUI code.

But this will be a rather massive redesign of the inner workings...

[Motenai Yoda]

there are the exact same files, maybe different versions? I took from your pack and last winamp installer.

edit: now I make a clean reinstall with all new files, and work.

edit2: I didn't mean in the gui code, but a method that change that list into an "AACEncodersWrapper" class (or something like this) in the way that each "XXXEncodersWrapper" class can manage XXX lists internally.

But now that it's switched from naac to fhgaac, the slider's scale for VBR mode has yet changed. 0.o

[LoRd_MuldeR]

edit2: I didn't mean in the gui code, but a method that change that list into an "AACEncodersWrapper" class (or something like this) in the way that each "XXXEncodersWrapper" class can manage XXX lists internally.

But now that it's switched from naac to fhgaac, the slider's scale for VBR mode has yet changed. 0.o

Sorry, I have no idea what you mean :confused:

[LoRd_MuldeR]

there are the exact same files, maybe different versions? I took from your pack and last winamp installer.

edit: now I make a clean reinstall with all new files, and work.

edit2: I didn't mean in the gui code, but a method that change that list into an "AACEncodersWrapper" class (or something like this) in the way that each "XXXEncodersWrapper" class can manage XXX lists internally.

But now that it's switched from naac to fhgaac, the slider's scale for VBR mode has yet changed. 0.o

Sorry, I have no idea what you mean :confused:

Anyway, today I started refactoring all the encoder-specific code out of the GUI code:
http://pastie.org/private/gpbkatoeas1kdtmk5te92g

One of my most productive days was throwing away 1,000 lines of code - Ken Thompson

[LoRd_MuldeR]

LameXP v4.09 Alpha-1:

Changes between v4.08 and v4.09 [unreleased]:
* Improved internal encoder API, so each encoder can define its own configuration options
* Complete overhaul of the file analyzer, resulting in up to 2.5x faster file import speed

I have almost finished moving the encoder-specific options out of the GUI code. Now each encoder can expose its own configurations options, through the new encoder API. This also means that now each of the three AAC encoders can have its own separate configurations options! Furthermore, the file analyzer has been rewritten completely. The new code is much faster. In my test, the time for importing about 1000 files decreased from 116 seconds to 46 seconds (about 2.5x faster).

[Sparktank]

Thanks for the update. :)

It's been a long time since I used this so this should definitely be fun to play with.

[LoRd_MuldeR]

FWIW, I made made a short clip that shows LameXP v4.08 vs. LameXP v4.09 while importing the very same set of 1160 files:
http://www.mediafire.com/download/o5ggo5xmlwowbue/lamexp_importManyFiles_v408_VS_v409.zip

(Note that these runs were captured one after another and stacked together afterwards. Also, I have a feeling that without the capturing software, the difference is even larger)

[mike20021969]

LameXP v3.08 vs. LameXP v3.09

Old version numbers?

[LoRd_MuldeR]

Whoops. Should be 4.xx, of course ;)

EDIT: Fixed!

[LoRd_MuldeR]

LameXP v4.09 Alpha-2:

Changes between v4.08 and v4.09 [unreleased]:
* Improved internal encoder API, so each encoder can define its own configuration options
* Complete overhaul of the file analyzer, resulting in up to 2.5x faster file import speed
* Updated mpg123 decoder to v1.16.0 (2013-10-06), compiled with GCC 4.8.1
* Various bugfixes and code improvements

[LoRd_MuldeR]

LameXP v4.09 Alpha-3:

Changes between v4.08 and v4.09 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 RTM
* Improved internal encoder API, so each encoder can define its own configuration options
* Complete overhaul of the file analyzer, resulting in up to 2.5x faster file import speed
* Updated mpg123 decoder to v1.16.0 (2013-10-06), compiled with GCC 4.8.1
* Updated GnuPG to v1.4.15 (2013-10-05), compiled with GCC 4.8.1
* Various bugfixes and code improvements

[LoRd_MuldeR]

LameXP v4.09 Alpha-4:

Changes between v4.08 and v4.09 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 RTM
* Complete overhaul of the file analyzer, resulting in up to 2.5x faster file import speed
* Reworked the application initialization code, resulting in notably faster startup speed
* Improved file analyzer to retain the original ordering of files imported from a playlist
* Improved internal encoder API, so each encoder can define its own configuration options
* Updated mpg123 decoder to v1.16.0 (2013-10-06), compiled with GCC 4.8.1
* Updated GnuPG to v1.4.15 (2013-10-05), compiled with GCC 4.8.1
* Various bugfixes and code improvements

[LoRd_MuldeR]

LameXP v4.09 Alpha-5:

Changes between v4.08 and v4.09 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 RTM
* Complete overhaul of the file analyzer, resulting in up to 2.5x faster file import speed
* Reworked the application initialization code, resulting in notably faster startup speed
* Improved file analyzer to retain the original ordering of files imported from a playlist
* Improved internal encoder API, so each encoder can define its own configuration options
* Updated mpg123 decoder to v1.16.0 (2013-10-06), compiled with GCC 4.8.1
* Updated GnuPG to v1.4.15 (2013-10-05), compiled with GCC 4.8.1
* Various bugfixes and code improvements

[SeeMoreDigital]

It sure does start up faster now :)

[LoRd_MuldeR]

LameXP v4.09 Alpha-6:

Changes between v4.08 and v4.09 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 RTM
* Complete overhaul of the file analyzer, resulting in up to 2.5x faster file import speed
* Reworked the application initialization code, resulting in notably faster startup speed
* Improved file analyzer to retain the original ordering of files imported from a playlist
* Improved internal encoder API, so each encoder can define its own configuration options
* Improved dropbox widget, including proper multi-monitor support
* Updated mpg123 decoder to v1.16.0 (2013-10-06), compiled with GCC 4.8.1
* Updated GNU Wget binary to v1.14.0 (2012-08-05), compiled with GCC 4.8.1
* Updated GnuPG to v1.4.15 (2013-10-05), compiled with GCC 4.8.1
* Various bugfixes and code improvements

Interestingly, I noticed that the previous WGet binary would crash on my old WinXP laptop, while it did not crash on any of my WinXP VM's (that I normally use for testing) or on any of my other machines. So I compiled a new binary from the sources. To my surprise, the new binary still causes an unhanded exception. It's easy to reproduce in GDB (see here (http://i.imgur.com/h8938zV.png)). And after I finally managed to make a debug binary of WGet (it's not straight forward to make MinGW link against the debug MSVCRT), I realized that the problem originates from a "hack" in WGet where they close the same file descriptor twice, ending up in MSVCRT calling CloseHandle() with an invalid handle value. Now, does anybody have an idea why this normally doesn't trigger a crash (just fails silently), except on one specific system? I guess this is the awesomeness of "undefined behavior" caused by issuing Syscalls with invalid handle values... :rolleyes:

[real.finder]

hi LoRd_MuldeR :)

Simple suggestion about the wav 4G issue

a wav file (the temporary one) can be split by size (every 4G or 3.9G ((or something else)) becomes section) if the file is larger than 4g before input in Encoders

Then the files that were encoded separately will be merged into the final file in the end

-----


And another thing, if I encoded flac 5.1 into ogg in lamexp, the order of channels will be different

thanks :)

[LoRd_MuldeR]

Simple suggestion about the wav 4G issue

a wav file (the temporary one) can be split by size (every 4G or 3.9G ((or something else)) becomes section) if the file is larger than 4g before input in Encoders

Then the files that were encoded separately will be merged into the final file in the end

Not possible in reality for various reasons:

(1) For this to work, every decoder we use would have to support an option to split "ultralarge" Wave files. AFAIK, currently none of the decoders we use supports this option.

(2) Even if we could resolve the first point, we would still need to join the encoded files. This is easy with a "raw" format like MP3, since we can simply do a binary concatenation. But it is very difficult with containers like MP4 or OGG, where you have global headers and stuff. For those formats we would either have to implement our own MP4/OGG muxer or use something like MP4Box.

(3) Even if we could resolve the second point, there's another problem: Most compressed audio formats introduce some padding at the beginning and/or the end of the audio stream. So if you encode the audio in several "chunks" (separate input Wave files), then every chunk gets this padding. Now, if you join together those chunks later, you will get a short "silence" at every junction point, because of the padding.


Proper solution for this would be using Wave64 files instead of RIFF/WAV. But that won't be possible until all (or at least most) of the encoders/decoders start supporting Wave64 :rolleyes:

(I think at this moment, only ValDec from AC3Filter Tools is able to create Wave64 files, all other tools don't even read them)

And another thing, if I encoded flac 5.1 into ogg in lamexp, the order of channels will be different

This would indicate either the Ogg decoder creates a Wave file with "wrong" (non-standard) channel mappings or the FLAC encoder assumes a "wrong" (non-standard) channel mappings when reading Wave files.

In any of those cases, this would have to be fixed either in OggDec or in FLAC. There's not much I can do here...

(Well, I could try to implement a workaround by re-ordering the channels in the intermediate Wave file using SoX, but that would require yet another processing step. And it's an ugly hack)