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

[amayra]

General
Complete name : D:\Downloads\Music\videoplayback_15.m4a
Format : dash
Codec ID : dash (iso6/mp41)
File size : 3.70 MiB
Duration : 4 min 4 s
Overall bit rate : 127 kb/s
Encoded date : UTC 2016-10-29 07:49:10
Tagged date : UTC 2016-10-29 07:49:10

Audio
ID : 1
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 4 min 4 s
Bit rate : 126 kb/s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 kHz
Frame rate : 43.066 FPS (1024 spf)
Compression mode : Lossy
Stream size : 3.66 MiB (99%)
Encoded date : UTC 2016-10-29 07:49:10
Tagged date : UTC 2016-10-29 07:49:10

[ggtop]

nice :D

ggtop

[LoRd_MuldeR]

General
Complete name : D:\Downloads\Music\videoplayback_15.m4a
Format : dash
Codec ID : dash (iso6/mp41)

Despite .m4a file extensions, this is actually not normal MP4 format, but DASH (Dynamic Adaptive Streaming over HTTP).

It appears that the FAAD decoder, as used by LameXP, does not support DASH format, so simply adding "dash" to the list of supported formats wouldn't help.

However, passing the file trough MP4Box (https://www.sendspace.com/file/1ts5nr) once seems to "fix" the file, so that LameXP (FAAD) can handle it:
mp4box.exe -add videoplayback_15.m4a -new videoplayback_15.FIXED.mp4

[LoRd_MuldeR]

LameXP v4.14 RC-4

Changes between v4.13 and v4.14 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2015 with Update-2
* Fixed the location of temporary intermediate files for SoX-based audio effects
* Fixed embedding of meta tags with OggEnc2 when reading directly from OGG/FLAC input file
* Enabled the "built-in" resampler for QAAC encoder
* The "Algorithm Quality" slider now also affects the QAAC encoder
* Added "AVX" (Advanced Vector Extensions) to CPU feature detection code
* Updated Opus encoder/decoder libraries to v1.2-alpha and Opus-Tools to v0.1.9 (2016-11-02)
* Updated LAME encoder to v3.100 Alpha-2 (2016-01-29), compiled with ICL 15.0 and MSVC 12.0
* Updated FLAC encoder/decoder to v1.3.1 (2016-10-04), compiled with ICL 17.0 and MSVC 12.0
* Updated MediaInfo to v0.7.88 (2016-08-31), compiled with ICL 15.0 and MSVC 12.0
* Updated mpg123 decoder to v1.23.8 (2016-09-27), compiled with GCC 6.2.0
* Updated ALAC decoder to refalac v1.61 (2016-10-02)
* Updated WavPack decoder to v4.80.0 (2016-03-28), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.21 (2016-08-17), compiled with GCC 6.1.0
* Updated QAAC add-in to the to QAAC v2.61 (2016-10-02)
* Updated FhgAacEnc add-in to "Case" edition (2015-10-24)
* Improved auto-update function (faster Internet connectivity check)

[LoRd_MuldeR]

LameXP v4.14 RC-5

Changes between v4.13 and v4.14 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2015 with Update-2
* Fixed the location of temporary intermediate files for SoX-based audio effects
* Fixed embedding of meta tags with OggEnc2 when reading directly from OGG/FLAC input file
* Enabled the "built-in" resampler for QAAC encoder
* The "Algorithm Quality" slider now also affects the QAAC encoder
* Added "AVX" (Advanced Vector Extensions) to CPU feature detection code
* Updated Opus encoder/decoder libraries to v1.2-alpha and Opus-Tools to v0.1.9 (2016-11-04)
* Updated LAME encoder to v3.100 Alpha-2 (2016-01-29), compiled with ICL 15.0 and MSVC 12.0
* Updated FLAC encoder/decoder to v1.3.1 (2016-10-04), compiled with ICL 17.0 and MSVC 12.0
* Updated MediaInfo to v0.7.90 (2016-10-31), compiled with ICL 17.0 and MSVC 12.0
* Updated mpg123 decoder to v1.23.8 (2016-09-27), compiled with GCC 6.2.0
* Updated ALAC decoder to refalac v1.61 (2016-10-02)
* Updated WavPack decoder to v4.80.0 (2016-03-28), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.21 (2016-08-17), compiled with GCC 6.1.0
* Updated QAAC add-in to the to QAAC v2.61 (2016-10-02)
* Updated FhgAacEnc add-in to "Case" edition (2015-10-24)
* Improved auto-update function (faster Internet connectivity check)

[LoRd_MuldeR]

LameXP v4.14 RC-6

Changes between v4.13 and v4.14 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2015 with Update-2
* Fixed the location of temporary intermediate files for SoX-based audio effects
* Fixed embedding of meta tags with OggEnc2 when reading directly from OGG/FLAC input file
* Fixed encoding of non-Stereo sources with NeroAAC, when "HE-AAC v2 (SBR+PS)" is selected
* Fixed a bug that would cause the encoding job to fail, when an audio filter is skipped
* Enabled the "built-in" resampler for QAAC encoder
* The "Algorithm Quality" slider now also affects the QAAC encoder
* Added "AVX" (Advanced Vector Extensions) to CPU feature detection code
* Updated Opus encoder/decoder libraries to v1.2-alpha and Opus-Tools to v0.1.9 (2016-11-04)
* Updated LAME encoder to v3.100 Alpha-2 (2016-01-29), compiled with ICL 15.0 and MSVC 12.0
* Updated FLAC encoder/decoder to v1.3.1 (2016-10-04), compiled with ICL 17.0 and MSVC 12.0
* Updated MediaInfo to v0.7.90 (2016-10-31), compiled with ICL 17.0 and MSVC 12.0
* Updated mpg123 decoder to v1.23.8 (2016-09-27), compiled with GCC 6.2.0
* Updated ALAC decoder to refalac v1.61 (2016-10-02)
* Updated WavPack decoder to v4.80.0 (2016-03-28), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.21 (2016-08-17), compiled with GCC 6.1.0
* Updated QAAC add-in to the to QAAC v2.61 (2016-10-02)
* Updated FhgAacEnc add-in to "Case" edition (2015-10-24)
* Improved auto-update function (faster Internet connectivity check)

[LoRd_MuldeR]

LameXP v4.14 Final
https://sourceforge.net/projects/lamexp/files/latest/download

Changes between v4.13 and v4.14 [2016-11-19]:
* Upgraded build environment to Microsoft Visual Studio 2015 with Update-2
* Fixed the location of temporary intermediate files for SoX-based audio effects
* Fixed embedding of meta tags with OggEnc2 when reading directly from OGG/FLAC input file
* Fixed encoding of non-Stereo sources with NeroAAC, when "HE-AAC v2 (SBR+PS)" is selected
* Fixed a bug that would cause the encoding job to fail, when an audio filter is skipped
* Enabled the "built-in" resampler for QAAC encoder
* The "Algorithm Quality" slider now also affects the QAAC encoder
* Added "AVX" (Advanced Vector Extensions) to CPU feature detection code
* Updated Opus encoder/decoder libraries to v1.2-alpha and Opus-Tools to v0.1.9 (2016-11-04)
* Updated LAME encoder to v3.100 Alpha-2 (2016-01-29), compiled with ICL 15.0 and MSVC 12.0
* Updated FLAC encoder/decoder to v1.3.1 (2016-10-04), compiled with ICL 17.0 and MSVC 12.0
* Updated MediaInfo to v0.7.90 (2016-10-31), compiled with ICL 17.0 and MSVC 12.0
* Updated mpg123 decoder to v1.23.8 (2016-09-27), compiled with GCC 6.2.0
* Updated ALAC decoder to refalac v1.61 (2016-10-02)
* Updated WavPack decoder to v4.80.0 (2016-03-28), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.21 (2016-08-17), compiled with GCC 6.1.0
* Updated QAAC add-in to the to QAAC v2.61 (2016-10-02)
* Updated FhgAacEnc add-in to "Case" edition (2015-10-24)
* Improved auto-update function (faster Internet connectivity check)
* Updated language files (big thank-you to all contributors !!!)

[manolito]

Thanks very much for the new version... :thanks:

Did a couple of quick tests, no problems so far. I still have to change my desktop colors to 16bit (the newer build environment did not change this).

One question about the FHG AAC encoder add-in:
In the change log I found this:
Updated FhgAacEnc add-in to "Case" edition (2015-10-24)
But the manual does not even mention the FHG encoder, and on your website I could only find ancient FHG add-ons from 2012.

This old FHG add-in does no longer work, so it would be nice if you could provide a link and instructions for this new "Case" edition.


Cheers
manolito

[manolito]

Looks like I spoke too soon...

I have massive problems loading source files into LameXP. I frequently get this window:
http://www77.zippyshare.com/scaled/GMR9KHOk/file.html (http://www77.zippyshare.com/v/GMR9KHOk/file.html)

This happens with MP3 and WAV sources so far (have not tested other formats yet). All my other audio converters work just fine with these files. And the real funny thing is that if I copy such a source file in Explorer to the same location (the new file name will be "Copy Of ...") then LameXP will accept this file without errors.

Looks like a bug to me...


Cheers
manolito

[LoRd_MuldeR]

One question about the FHG AAC encoder add-in:
In the change log I found this:

But the manual does not even mention the FHG encoder, and on your website I could only find ancient FHG add-ons from 2012.

This old FHG add-in does no longer work, so it would be nice if you could provide a link and instructions for this new "Case" edition.

See here:
https://sourceforge.net/projects/lamexp/files/Miscellaneous/Add-ins/fhgaac/

Please follow closely the INSTRUCTIONS to set up everything as needed. You'll need to find a download of Winamp and "borrow" the required files.


I have massive problems loading source files into LameXP. I frequently get this window:
http://www77.zippyshare.com/scaled/GMR9KHOk/file.html (http://www77.zippyshare.com/v/GMR9KHOk/file.html)

This happens with MP3 and WAV sources so far (have not tested other formats yet). All my other audio converters work just fine with these files. And the real funny thing is that if I copy such a source file in Explorer to the same location (the new file name will be "Copy Of ...") then LameXP will accept this file without errors.

This sounds strange, indeed :confused:

There has not been any noteworthy change to the file analysis code since the previous release. But, as always, the MediaInfo binary has been updated to the latest version.

So, what does MediaInfo.exe (https://sourceforge.net/projects/muldersoft/files/MediaInfo%20%28CLI%2BGUI%29/MediaInfo-CLI.2016-11-04.zip/download) have to say when you run it directly and let it analyze the file, from its original path? Does changing the file's path affect MediaInfo's output in some way?

And, most important, what does the log (http://lamexp.sourceforge.net/doc/Manual.html#diagnostic-output) say?

(BTW: Just added ~4700 MP3 files without problem. Any chance you are running some "Anti-Virus" crap that might be interfering?)

[SeeMoreDigital]

Looks like I spoke too soon...

I have massive problems loading source files into LameXP. I frequently get this window:
http://www77.zippyshare.com/scaled/GMR9KHOk/file.html (http://www77.zippyshare.com/v/GMR9KHOk/file.html)

This happens with MP3 and WAV sources so far (have not tested other formats yet).
That's odd...

I've just tried inputting a couple of .wav and .mp3 files (with and without meta-data) and not had any problems. It's all good :)

Cheers and thanks LoRd_MuldeR

[Taurus]

That's odd...

I've just tried inputting a couple of .wav and .mp3 files (with and without meta-data) and not had any problems. It's all good :)

Cheers and thanks LoRd_MuldeR
The same here :thanks: o' Lord

[manolito]

Meanwhile I had gone back to the older stable version 4.13 (which of course fixed the problem). Now I reinstalled 4.14 again, but I got the same problems.

And no, there is no resident AV software on my computer (slows it down too much... :D )

I used WAV files for my tests to rule out any MP3 MetaData problems. Looks like the built-in MediaInfo version does not like my ancient Non-SSE2 CPU and/or my WinXP.

When I run "lxp_mediainfo.exe" from the temp folder, it does not crash, but the output is totally garbled and unreadable. My OS is set to German and Codepage 850.

Here is the debug output of LameXP with a WAV file and a copy of the same file:

Analyzing: I:/01 Untitled 01.wav
Rejected file of unknown type: I:/01 Untitled 01.wav
All files added.

Analyzing: I:/Kopie von 01 Untitled 01.wav
All files added.


Cheers
manolito


//EDIT//
Renaming the rejected file to "test.wav" did not change anything, the file was still rejected

[SeeMoreDigital]

Does MediaInfo read your .wav contained file? If-so please post what it reports, in full, as a 'text' file?


Cheers

[LoRd_MuldeR]

I used WAV files for my tests to rule out any MP3 MetaData problems. Looks like the built-in MediaInfo version does not like my ancient Non-SSE2 CPU and/or my WinXP.

It does work fine on my Windows XP with SP-3 test system. I don't have a machine with non-SSE2 processor though, because my old Athlon XP died a few years ago.

Anyway, the "i386" MediaInfo binary, that is included with LameXP, was compiled with the /IA32 compiler switch and therefore is supposed to work on all 32-Bit x86 processors.

The only other MediaInfo binary included with LameXP is the "x64" one - which wouldn't even launch on your computer. So, LameXP obviously must be using the "i386" one.

When I run "lxp_mediainfo.exe" from the temp folder, it does not crash, but the output is totally garbled and unreadable. My OS is set to German and Codepage 850.

Can you please do mediainfo.exe "c:\some path\some file.wav" > output.txt and provide the resulting "output.txt" file?

If latest MediaInfo is not working on your machine, how can changing the file's path make any difference? :confused:

Here is the debug output of LameXP with a WAV file and a copy of the same file:

If MediaInfo output is "garbled" already, it is clear that LameXP won't be able to parse it.

[manolito]

The following command:
lxp_mediainfo.exe "c:\test\Kopie von 01 Untitled 01.wav" >i:\output.txt

always produces an "output.txt" file with a size of 0 bytes. No matter if I use a source file which is recognized by LameXP or if I use a file which is rejected.

And my installed MediaInfo version 7.90 produces the following results:

Allgemein
Vollständiger Name : C:\test\test.wav
Format : Wave
Dateigröße : 41,7 MiB
Dauer : 4min 7s
Modus der Gesamtbitrate : konstant
Gesamte Bitrate : 1 411 Kbps

Audio
Format : PCM
Format-Einstellungen für Endianess : Little
Format-Einstellungen für Sign : Signed
Codec-ID : 1
Dauer : 4min 7s
Bitraten-Modus : konstant
Bitrate : 1 411,2 Kbps
Kanäle : 2 Kanäle
Samplingrate : 44,1 KHz
BitDepth/String : 16 bits
Stream-Größe : 41,7 MiB (100%)



Allgemein
Vollständiger Name : C:\test\Kopie von 01 Untitled 01.wav
Format : Wave
Dateigröße : 41,7 MiB
Dauer : 4min 7s
Modus der Gesamtbitrate : konstant
Gesamte Bitrate : 1 411 Kbps

Audio
Format : PCM
Format-Einstellungen für Endianess : Little
Format-Einstellungen für Sign : Signed
Codec-ID : 1
Dauer : 4min 7s
Bitraten-Modus : konstant
Bitrate : 1 411,2 Kbps
Kanäle : 2 Kanäle
Samplingrate : 44,1 KHz
BitDepth/String : 16 bits
Stream-Größe : 41,7 MiB (100%)

As you can see the results are identical for the rejected file (test.wav) and the accepted file.

[manolito]

OK guys, I am throwing in the towel...

I went back to the previous stable version 4.13, and I will consider this version as static as far as I am concerned. Looking at the change log I do not think that I am giving up on anything. Most audio encoders are quite mature, at least the ones I use have not improved significantly over the last 2 years. And the old LameXP shortcomings (not being able to convert large multi-channel files where the intermediate WAV file is larger than 2GB) are the same in the latest version.

This post from the FFmpeg forum sums up my feelings about using older computers and Operating Systems quite perfectly:
https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=2&t=2937&start=10#p11608

Newer is NOT always better... :devil:
But of course I am aware that I am one of the very few people who see it that way. So I will stop to annoy you with my requests to make your software compatible with my hardware and OS.

And this will be my last post within this thread...


Cheers
manolito

[LoRd_MuldeR]

FWIW, today I installed a Windows XP inside a Bochs-based VM, with Pentium 3 emulation. The latest MediaInfo crashed with exception code 0xC000001D (STATUS_ILLEGAL_INSTRUCTION).

:angry:

[LoRd_MuldeR]

FWIW, today I installed a Windows XP inside a Bochs-based VM, with Pentium 3 emulation. The latest MediaInfo crashed with exception code 0xC000001D (STATUS_ILLEGAL_INSTRUCTION).

:angry:

And yeah, my previous MediaInfo build works fine on the same VM. Smells fishy...

(investigating)

[SeeMoreDigital]

And yeah, my previous MediaInfo build works fine on the same VM. Smells fishy...

(investigating)The joys of XP eh ;)

[LoRd_MuldeR]

The joys of XP eh ;)

More the joys of compilers generating SSE2 (or higher) instructions when they are supposed to not do ;)

[jpsdr]

Could it be that the code use intrinsic...? In that case, the instructions are generated, and maybe there is not even a warning in the compiler.

[LoRd_MuldeR]

Could it be that the code use intrinsic...? In that case, the instructions are generated, and maybe there is not even a warning in the compiler.

I don't think MediaInfo recently started using SSE2 intrinsics. Especially since he said that the "installed version" (probably: official binaries) of MediaInfo works okay.

Suspecting a compiler bug. Wouldn't be the first time a compiler generates "enhanced" instructions when it shouldn't...

[K.i.N.G]

Anyone know if it is possible to convert an 7.1 atmos track to AAC 7.1 with atmos?
Or do only True-HD and DTS:x support atmos data?

[SeeMoreDigital]

Anyone know if it is possible to convert an 7.1 atmos track to AAC 7.1 with atmos?
Or do only True-HD and DTS:x support atmos data?In short... No it's not possible to do what you require!

Currently the spatial/object based 'meta-data' information can only be processed and decoded by dedicated Dolby and DTS hardware decoder chip-sets.

[LoRd_MuldeR]

Here is a new TEST build:
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2016-12-16/LameXP-ALPHA.2016-12-26.Release-Static.Build-1950.exe/download

This should fix the MediaInfo issues some people have been experiencing on processors without SSE2 support (it appears that runtime CPU dispatching is severely broken for such processors, so I don't use it anymore).

[sebus]

What are the options to encode .wav to ALAC .mp4 with qaac64

Adding the option to advanced for qaac --alac gives the error as the options are exclusive

I see no logical checkbox for alac only

sebus

[LoRd_MuldeR]

What are the options to encode .wav to ALAC .mp4 with qaac64

Adding the option to advanced for qaac --alac gives the error as the options are exclusive

I see no logical checkbox for alac only

sebus

Sorry, there is no option for encoding to ALAC format, but you can encode from ALAC format.

What would be the reason to encode to ALAC, when you have FLAC available?

FLAC is a completely open format, it is the de-facto standard for lossless audio with very good support in soft- and hardware (while ALAC is rare outside the Apple universe), it compresses at least as good as ALAC, and it's faster than ALAC:
http://wiki.hydrogenaud.io/index.php?title=Lossless_comparison#Comparison_Table

[sebus]

I have old gen 4 iPod (converted from 40Gb HDD to 64Gb SD) connected to Onkyo Receiver via Universal Port, iPod means no flac

And while I can play flac from USB or DLNA server, having local old iPod loaded with various alac files is yet another option

Oh well, I can do conversion with a batch file after all, but having it included in LXP would be helpful

sebus

[SeeMoreDigital]

Welcome to the wonderful 'limited world' of Apple playback devices :scared:

[quitemice]

First of all i want to say that i use and like this excellent program very much!! it does what it is supposed to do, and it works excellent!

But i have a few issues with it, although that aren't issues with the working of this program.

1. I want to know why you choose to unpack the necessary codecs etc from the main executable every time you start the program? In my opinion this is unnecessary? especially on ssd?

2. Why are the settings not saved when upgrading the program with a new version? I know the settings are written to the new config file but the program apparently doesn't use it? every time i update this program the settings are gone and i have to re do all the settings i made.

3. would you consider to remove the sound effects? or disable them by default?

I know this program is opensource and i could make my own version but i'm not skilled enough to do that.

I'm NOT criticizing your work though

[LoRd_MuldeR]

1. I want to know why you choose to unpack the necessary codecs etc from the main executable every time you start the program? In my opinion this is unnecessary? especially on ssd?

Because it gives a very nice "all in one" application that just works "out of the box" and doesn't depend on anything. This way LameXP can also be used as a "portable" application. The user doesn't need to bother that some temporary files get extracted on startup (and will ne cleaned-up automatically on application shutdown), as it is completely transparent to the user. Most users probably never notice.

Especially with SSD, the extraction should be extremely fast. Takes less than a second on my system! If you ever see LameXP to take more than a few seconds to startup up, get rid of the crappy A/V software that is responsible!
http://lamexp.sourceforge.net/doc/Manual.html#performance-issues

(And please don't tell me that LameXP causes your SSD to "wear out" more quickly. SSD's wearing out quickly is a common myth, maybe a problem of the very earliest SSD's, but certainly not of today's ones - as tests have shown many times)


2. Why are the settings not saved when upgrading the program with a new version? I know the settings are written to the new config file but the program apparently doesn't use it? every time i update this program the settings are gone and i have to re do all the settings i made.

Settings are not "not saved", but stored separately for each major release. That's because new major releases can add new settings, removed old settings, or change the meaning of existing settings.

IMO it's better to keep things separate. If you changed any of the defaults in LameXP, then you can do so again in 10 seconds. Any maybe, in the meantime, you realized that you should stick with the defaults anyway...

You can even edit the INI file and rename the INI section from "old" to "new" version, so that the "new" version will try to read your "old" settings. That's on your own risk, of course ;)


3. would you consider to remove the sound effects? or disable them by default?

There are no plans to disable the sounds by default. You can disable them at any time though, if you don't like them.

[LoRd_MuldeR]

LameXP v4.15 Beta-1
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2017-03-25/LameXP-BETA.2017-03-25.Release-Static.Build-1958.exe/download

Changes between v4.14 and v4.15 [*unreleased*]:
* Fixed a bug in auto-rename feature, that caused problems when a meta-tag contained path separators
* Fixed included MediaInfo binary not working on processor without SSE2 support
* Some improvements for "high DPI" screens: Adjust initial window size according to DPI setting
* Updated Opus encoder/decoder libraries to v1.2-alpha2 (2017-03-03) and Opus-Tools to v0.1.10 (2017-02-22)
* Updated MediaInfo to v0.7.93 (2017-02-28), compiled with ICL 17.0 and MSVC 12.0

[quitemice]

Because it gives a very nice "all in one" application that just works "out of the box" and doesn't depend on anything. This way LameXP can also be used as a "portable" application. The user doesn't need to bother that some temporary files get extracted on startup (and will ne cleaned-up automatically on application shutdown), as it is completely transparent to the user. Most users probably never notice.

Especially with SSD, the extraction should be extremely fast. Takes less than a second on my system! If you ever see LameXP to take more than a few seconds to startup up, get rid of the crappy A/V software that is responsible!
http://lamexp.sourceforge.net/doc/Manual.html#performance-issues

(And please don't tell me that LameXP causes your SSD to "wear out" more quickly. SSD's wearing out quickly is a common myth, maybe a problem of the very earliest SSD's, but certainly not of today's ones - as tests have shown many times)




Settings are not "not saved", but stored separately for each major release. That's because new major releases can add new settings, removed old settings, or change the meaning of existing settings.

IMO it's better to keep things separate. If you changed any of the defaults in LameXP, then you can do so again in 10 seconds. Any maybe, in the meantime, you realized that you should stick with the defaults anyway...

You can even edit the INI file and rename the INI section from "old" to "new" version, so that the "new" version will try to read your "old" settings. That's on your own risk, of course ;)




There are no plans to disable the sounds by default. You can disable them at any time though, if you don't like them.

@lord mulder

Oke thanks for your explanation!

I think your reasons are legit, and yes it's not a big deal to enter my settings again.
But i'm not sure why you save the settings separately but never use them. I mean what's the point than to save them?

but like i said it's not a real problem, and i happily continue to work with this program :D

[LoRd_MuldeR]

LameXP v4.15 Beta-3

Changes between v4.14 and v4.15 [*unreleased*]:
* Fixed a bug in auto-rename feature, that caused problems when a meta-tag contained path separators
* Fixed included MediaInfo binary not working on processor without SSE2 support
* Some improvements for "high DPI" screens: Adjust initial window size according to DPI setting
* Updated Opus encoder/decoder libraries to v1.2-alpha2 (2017-03-03) and Opus-Tools to v0.1.10 (2017-02-22)
* Updated MediaInfo to v0.7.93 (2017-02-28), compiled with ICL 17.0 and MSVC 12.0
* Updated FAAD decoder to v2.7 from CVS in order to include latest libFAAD fixes (2016-11-11)
* Some tweaks to the auto-update function in order to speed-up the update check in most situations

[LoRd_MuldeR]

LameXP v4.15 Beta-4

Changes between v4.14 and v4.15 [*unreleased*]:
* Fixed a bug in auto-rename feature, that caused problems when a meta-tag contained path separators
* Fixed included MediaInfo binary not working on processor without SSE2 support
* Improved file name generation from meta-tags containing characters that are forbidden in file names
* Some improvements for "high DPI" screens: Adjust initial window size according to DPI setting
* Updated Opus encoder/decoder libraries to v1.2-alpha2 (2017-03-03) and Opus-Tools to v0.1.10 (2017-02-22)
* Updated MediaInfo to v0.7.93 (2017-02-28), compiled with ICL 17.0 and MSVC 12.0
* Updated SoX to v14.4.2 (2015-02-22) with Dynamic Audio Normalizer v2.10 (2017-04-14) effect included
* Updated FAAD decoder to v2.7 from CVS in order to include latest libFAAD fixes (2016-11-11)
* Some tweaks to the auto-update function in order to speed-up the update check in most situations

[LoRd_MuldeR]

LameXP v4.15 Beta-5 „Ingsoc“
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2017-04-22/LameXP-BETA.2017-04-22.Release-Static.Build-1984.exe/download

Changes between v4.14 and v4.15 [*unreleased*]:
* Fixed a bug in auto-rename feature, that caused problems when a meta-tag contained path separators
* Fixed included MediaInfo binary not working on processor without SSE2 support
* Improved file name generation from meta-tags containing characters that are forbidden in file names
* Some improvements for "high DPI" screens: Adjust initial window size according to DPI setting
* Updated Opus encoder/decoder libraries to v1.2-alpha2 (2017-03-03) and Opus-Tools to v0.1.10 (2017-02-22)
* Updated MediaInfo to v0.7.94+ (2017-04-21), compiled with ICL 17.0 and MSVC 12.0
* Updated SoX to v14.4.2 (2015-02-22) with Dynamic Audio Normalizer v2.10 (2017-04-14) effect included
* Updated FAAD decoder to v2.7 from CVS in order to include latest libFAAD fixes (2016-11-11)
* Some tweaks to the auto-update function in order to speed-up the update check in most situations

http://imageshack.com/a/img924/911/ilu6ox.jpg

[Romario]

LameXP v4.15 Beta-5 „Ingsoc“
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2017-04-22/LameXP-BETA.2017-04-22.Release-Static.Build-1984.exe/download



http://imageshack.com/a/img924/911/ilu6ox.jpg

Can you please optimize your fantastic program for AMD Ryzen arhitecture ? Can you do it before final version come ? Thank you.

Is there any audio codec, at the moment, being optimized for Ryzen ?

As ilustration, look at this image in my attachment, please

[mariush]

Lame MP3 is pretty much single threaded, it will pretty much use one cpu core to encode one audio file. If you want to use all the cores in your processor, you'd have to use an application like foobar2k or LameXP to encode multiple audio files at the same time. The standard FLAC is also kinda poor at multithreading, same goes for neroAAC AAC encoder (which i still use even though apparently there's some other software supposedly better).

You can speed up encodings by running multiple conversions in parallel (up to 16-20 of them on Ryzen would be fine I guess).

You've made several posts about optimizing things for Ryzen. Ryzen architecture doesn't really have some magic instructions that would hugely affect the performance, if some application is already optimized to use the existing instructions sets from other processors like Intel Skylake, they'll work well on Ryzen as well.

x264 for example will use as many cores and threads as it feels needed, so if you're doing some high resolution high fps encoding, it will use all those 12-16 threads very well.

* for mp3, there were some attempts at making a multithreaded lame mp3, but it still works by encoding multiple audio files in parallel internally, not just one audio file... see fcMP3Enc https://hydrogenaud.io/index.php/topic,73790.0.html

* For FLAC, if you want speed you could look into CueTools.FLACCL which can use your video card to speed up encoding of audio files using OpenCL (which works on AMD and nVidia cards)

and a bit unrelated, but you asked on the x264 thread... i'm not an expert so I'm not sure... but I don't think x264 would benefit from those AVX instructions.

[Romario]

Ok, thanks for answer. I respect your opinion.

But something must be changed, lame have not been developed, actively, for three or four years now.

But please look my image in attachment. Can you explain why is 7700k so much faster than 8-core 1800x? I can't explain that, it shows how much is LAME unoptimized...

Gesendet von meinem GT-I9295 mit Tapatalk

[lvqcl]

But please look my image in attachment.

"Attachments Pending Approval" is all I can see

[mariush]

I can't view the attachment because attachments have to be reviewed by moderators and approved before people can see them. Use websites like imgur.com to upload pictures if you feel like to.

But to answer your question:

Intel 7700k has a default frequency of 4.2 Ghz and boosts up to 4.5 Ghz if only a few of the four cores are used.
AMD 1800x has a default frequency of 3.6 Ghz and boosts up to 4 Ghz if only a few of the eight cores are used.

As LAME mp3 encoder only uses older instructions sets (mmx, sse) which are pretty much same speed on both architectures, we can concentrate just on the frequency of the processors.
Since the encoder is mostly single threaded, we can assume only one core or at most two cores will have some usage, so the Intel 7700k will run those cores at 4.5 Ghz and the Ryzen 1800x will run those cores at 4 Ghz. So naturally, if 7700k is considered the default speed (100%) , then ryzen 1800x should have about 89% the performance of the Intel cpu:

4.5 ghz ... 100%
4 ghz ... ? %

? % = 4 x 100 / 4.5 = 88.%

Naturally, there are minute (very small) differences in the execution speed of those assembly instructions and there may be some differentiators between systems that affect the speed very little (like ddr4 ram frequency for example)

The point is you would see the performance difference if you encode multiple audio tracks at the same time, so that all cores would be used.
Rip an audio CD to uncompress WAV files using Exact Audio Copy and optionally (if you don't have a SSD) create a RAM Disk using software like ImDisk Ramdisk (freeware) (https://sourceforge.net/projects/imdisk-toolkit/) ... you don't want the mechanical drive affect the encoding speed when you read 10-20 audio files from the hard drive at the same time.

With a 7700k processor, since it has 4 cores and 8 threads, you can realistically encode around 10-12 audio files at the same time, before individual encoders would begin to wait for processor time. Let's go with 10.
On the 1800x processor, since it has 8 cores and 16 threads, we could realistically go with around 20 simultaneous encodings at the same time.
Both processors will have all cores used at the same time, so they won't boost (often) to their maximum frequencies, so let's assume the Intel cpu would run at 4.2 Ghz and the AMD cpu would run at 3.6 Ghz.

No you have

10 x 4.2 ghz ---- 100 %
20 x 3.6 ghz ----- ? %

? % = 20 x 3.6 x 100 % / ( 10 x 4.2) = 2 x 3.6 x 100 / 4.2 = 171.42%

So as long as you'll keep all the cores on the Ryzen 1800x busy encoding up to 20 individual audio tracks at the same time, you may get almost 1.5x-2x the performance compared to the 7700k

Of course, these are just assumptions, you'd have to test it yourself if you have access to two such systems.

[Romario]

"Attachments Pending Approval" is all I can see
Well I see my attachment without any problem. Strange...


Edit: https://ibb.co/c87xT5 ( this is my attacment )

[Atak_Snajpera]

You expect to much from Zen in single threaded applications. IPC is not that great in single thread! ALU table clearly shows that Zen loves when you throw multiple tasks on execution units.
So Ryzen optimization is simple. Keep all cores busy at all time!
https://i.imgsafe.org/6da60ecb0f.png

[Romario]

How can I use optimised lame 3.99.5 builds? While LameXP doesn't allow to change which lame build I use.

Sent from my LG-P880

[manolito]

It is still possible to use custom builds of the LameXP built-in tools (even if the manual does not mention it).

From the older LameXP FAQ:
Is there a way to use custom tools (binaries) with LameXP instead of the "built-in" ones?

LameXP uses a number third-party tools. All of these tools are already "built-in" (with a few exceptions) and
thus it is NOT required to provide separate binaries. Usually it will NOT be necessary to replace any of
the "built-in" tools with a custom (user-provided) binary. If, however, you need to replace/update/downgrade
one of the binaries for a good reason, the recommended method is re-building LameXP from the sources. If you
don't know how to build LameXP from the sources, then you probably shouldn't be trying to replace the binary.

Having said that, there now is a more convenient method for using a custom tool version (binary) instead of
the "built-in" one. This method works WITHOUT re-building LameXP. However note that the following is intended
for testing and debugging purposes only! Also note that LameXP was specifically designed to work with the
"built-in" versions of the tools. It may not work properly or may not work at all with custom tool versions!

In order to replace a "built-in" binary, simply put the user-provided binary to the following location:
<install_folder>\tools\<build_number>\<tool_name>.exe
If, for example, you want to replace 'lame.exe' in Build #666 of LameXP, you would put it to the this path:
C:\Path to your LameXP install folder\tools\666\lame.exe
(It is intended that the '<build_number>' part of the path has to be adjusted with every update of LameXP)


Cheers
manolito

[LoRd_MuldeR]

Can you please optimize your fantastic program for AMD Ryzen arhitecture ? Can you do it before final version come ? Thank you.

Is there any audio codec, at the moment, being optimized for Ryzen ?

As ilustration, look at this image in my attachment, please

Development of LAME is pretty much dead. So don't expect any optimizations for "new" processors any time soon ;)

Having said that, there is no "magic" optimization that would make LAME run a lot faster on Zen architecture all of a sudden! Yes, LAME could probably benefit from using "modern" instruction set extensions, such as AVX or AVX2 – at the moment the assembler code in LAME only uses the SSE and SSE2 extensions – but this "problem" is not specific to the Zen architecture at all. TTBOMK, the Zen architecture did not even introduce a new instruction set extension.

The reason why Ryzen 1800X performs relatively "bad" with LAME mp3 encoder is because LAME – just like most audio encoders – is completely single-threaded. And, given the current state of LAME development, I doubt this is ever going to change. Furthermore, it is well known that single-core performance still is the "weak spot" of the Zen architecture (compared to Intel Core i7 processors), even though things have been improved quite a lot since Bulldozer architecture.

As others have pointed out: You will need to run many LAME instances in parallel to take full advantage of a Ryzen processor with 16 logic cores – which is exactly what LameXP does :)


Well I see my attachment without any problem. Strange...

Attachments need to be approved by a mod, before other users can see/access them. I wasn't close to a computer in the last couple of days, so I couldn't approve it until now.


How can I use optimised lame 3.99.5 builds? While LameXP doesn't allow to change which lame build I use.

You can make LameXP use a custom build of LAME by putting your custom binary at the proper place, just like it is described in the F.A.Q. article that manolito quoted (https://forum.doom9.org/showpost.php?p=1806010&postcount=1446) (not ported to new manual yet).

Don't expect any wonders, though! LameXP already ships with up-to-date binaries of LAME 3.100 Alpha – including 64-Bit build with AVX compiler-optimizations enabled. The "best" build is automatically selected, based on the CPU's capabilities.

Note: Those compiler optimizations have a lesser effect on performance. That's because all the "hot" functions, where the vast majority of the CPU time is spent, already are written as hand-optimized assembler code...

[Romario]

How you optimised these LAME builds ? With ICL15 or newest MSCS 2017 ?

While ICL work always much better on Intel processors.

[LoRd_MuldeR]

How you optimised these LAME builds ? With ICL15 or newest MSCS 2017 ?

While ICL work always much better on Intel processors.

ICL, whatever version was up-to-date when I last built LAME.

Note that ICL has an option to add an "optimized" code path (for all compatible processors, including AMD) and a separate option to "optimize" specifically for Intel processors (potentially breaking the binary for Non-Intel processors).

I always use the former ;)

But, as said before, those compiler optimizations have a lesser effect! All the "hot" code, where ~99% of the CPU time is spent, is hand-optimized assembler code that will not be effected by compiler optimizations at all.

[Romario]

ICL, whatever version was up-to-date when I last built LAME.

Note that ICL has an option to add an "optimized" code path (for all compatible processors, including AMD) and a separate option to "optimize" specifically for Intel processors (potentially breaking the binary for Non-Intel processors).

I always use the former ;)

But, as said before, those compiler optimizations have a lesser effect! All the "hot" code, where ~99% of the CPU time is spent, is hand-optimized assembler code that will not be effected by compiler optimizations at all.

Very good, thanks.

And what about other audio encoders ? What is the situation ? Is there any actively development for OGG, or AAC codecs, with plan for future optimisations ? Can you, please, give me most optimised binarys ?