LameXP v4.21 Final · Build #2382 (2023-12-29) [Archive] - Page 22

LoRd_MuldeR

3rd November 2014, 17:11

The feedback was :
- Encode is not clean, because there is "Encoded with LameXP" in the comment tag...:confused:

Yes, LameXP adds the comment as a meta tag, by default. But in what way is this "not clean", please? :confused:

If you don't like it, you can clear the comment field at any time or simply input your own comment text there. See the "Meta Data" tab.

Of course it also should be straight forward to edit or remove the meta tags of an existing FLAC file.

(Despite of its name, Mp3tag (http://www.mp3tag.de/en/) is capable of editing FLAC tags)

- The bit (or tag, don't know) HDCD is set to 0. 1 should had been better.
If it's something you don't know about, never mind.

I still have no idea what the purpose of that "HDCD" tag is.

And is FLAC supposed to add this automatically or is the front-end supposed to add it explicitly? In the latter case: Under what circumstances?

Well, at this point it's not even clear whether this so-called "HDCD tag" is a bit in the FLAC header or just a custom meta tag...

jpsdr

3rd November 2014, 19:53

But in what way is this "not clean", please? :confused:

Maybe i was not clear enough. This was the feedback from the person for who i made the mkv.
As i've stated, i found this comment nonsense.
But thanks for the tips for removing it.

I personnaly use and will still use your tool, i found it very usefull.
Thank for it.

Edit :
Ok, a little more information from "the complainer" :
Encoded with LameXP :

General
Complete name : P:\MPEG-2\AoT-SP1.flac
Format : FLAC
Format/Info : Free Lossless Audio Codec
File size : 30.7 MiB
Duration : 6mn 44s
Overall bit rate mode : Variable
Overall bit rate : 637 Kbps
Track name : AoT-SP1
Comment : Encodé avec LameXP
track : 25

Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 6mn 44s
Bit rate mode : Variable
Bit rate : 637 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Stream size : 30.7 MiB (100%)
Writing library : libFLAC 1.3.0 (UTC 2013-05-26)

Encoded with eac3to :

General
Complete name : I:\Op-1.flac
Format : FLAC
Format/Info : Free Lossless Audio Codec
File size : 19.3 MiB
Duration : 1mn 31s
Overall bit rate mode : Variable
Overall bit rate : 1 765 Kbps
VALID_BITS : 24
HDCD : 0

Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 1mn 31s
Bit rate mode : Variable
Bit rate : 1 765 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Stream size : 19.3 MiB (100%)
Writing library : libFLAC 1.2.1 (UTC 2007-09-17)

Don't tested with Foobar2000.

LoRd_MuldeR

3rd November 2014, 21:16

Can't reproduce :confused:

Input:
http://i.imgur.com/adHjQi7.png

Conversion Log:
LameXP v4.11 (Build #1577), compiled on 2014-10-10 at 15:39:16

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

C:/Users/MuldeR/AppData/Local/Temp/ecaabf31b42a09a6/lxp_sox.exe --i E:\Samples\Audio\Uncompressed_44khz_24.wav

Input File : 'E:\Samples\Audio\Uncompressed_44khz_24.wav'
Channels : 2
Sample Rate : 44100
Precision : 24-bit
Duration : 00:03:16.16 = 8650752 samples = 14712.2 CDDA sectors
File Size : 51.9M
Bit Rate : 2.12M
Sample Encoding: 24-bit Signed Integer PCM

Exited with code: 0x0000

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

C:/Users/MuldeR/AppData/Local/Temp/ecaabf31b42a09a6/lxp_flac.exe -8 --channel-map=none -T "title=Uncompressed 44khz 24" -T "comment=Kodiert mit LameXP" -T track=1 -f -o C:\Users\MuldeR\Music\Uncompressed_44khz_24.flac E:\Samples\Audio\Uncompressed_44khz_24.wav

flac 1.3.0, Copyright (C) 2000-2009, 2011-2013 Josh Coalson & Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flac' for details.
Uncompressed_44khz_24.wav: WARNING: skipping unknown chunk 'fact' (use --keep-foreign-metadata to keep)
wrote 21987923 bytes, ratio=0,424

Exited with code: 0x0000

Output:
http://i.imgur.com/0crca8Q.png

jpsdr

3rd November 2014, 22:23

In that case, maybe eac3to add something more on his own on the flac header, not added by flac.exe, but still compliant to flac standard/header...?

SeeMoreDigital

3rd November 2014, 22:33

jpsdr,

Out of interest, what application was used to back-up the HDCD?

I'm not aware of any audio CD back-up application that's able to make use of the HDCD flag even when creating PCM file back-up's!

jpsdr

3rd November 2014, 23:39

Absolutely none, it's just a 24 bit audio wave file extracted from a Blu-Ray m2ts. It's not from CD audio, and i don't know any application able to do it, and i didn't even know about HDCD 2 days ago...
I was just complained to about the fact i described, and so warned that LameXP may be less reliable because unable to handle this feature, but eac3to can... It seems that "this HDCD" may be used on other files/tracks than on CD. I don't know, and don't want to bother Lord Mulder too much if he also doesn't know about it.

foxyshadis

4th November 2014, 01:26

HDCD is modern ADPCM: Give more bits to soft sounds and less to loud sounds. The HDCD tag just tells the player (only dbPowerAmp understands it) to uncompress it back in 24bit when playing, otherwise it sounds much too loud. Your friend is definitely spouting nonsense if he wants the tag added, but he can add it himself if he wants, it's just a plain old tag.

jpsdr

4th November 2014, 10:02

Do you know, by any luck, on what kind of file you can find this tag, others than flac ?

SeeMoreDigital

4th November 2014, 10:37

Do you know, by any luck, on what kind of file you can find this tag, others than flac ?Perhaps you (and your friends) should obtain some actual HDCD disc's to determine the differences between a regular audio CD and an HDCD before moving onto the subject of audio encoders making use of the HDCD flag...

As for generating 24-bit Flac files from "24-bit audio wave file extracted from a Blu-Ray .m2ts" files. LameXP does not have any problems handling/encoding these. And given such content does not contain any HDCD data, the 24-bit Flac encode does not require any additional flagging!

It would seem somebody somewhere is getting themselves very confused. And spouting their confusion onto others!

Groucho2004

4th November 2014, 10:43

In that case, maybe eac3to add something more on his own on the flac header, not added by flac.exe, but still compliant to flac standard/header...?

Have a look at the eac3to change log, it's custom meta-data:
v2.67
* information about HDCD and real bitdepth is now stored into FLAC metadata

jpsdr

4th November 2014, 11:37

Ok, thanks for all these informations.

SeeMoreDigital

12th November 2014, 22:02

LoRd_MuldeR

12th November 2014, 22:54

Hi LoRd_MuldeR,

I'm currently running an evaluation version of Windows 10 64-bit. Before LameXP starts up I see the following message: -

http://i61.tinypic.com/2lw6fbd.png

Just thought you'd like to know... It seems to be working okay :)

See these commits, just a few hours ago:
* https://bitbucket.org/lord_mulder/lamexp/commits/add0de2472f9501fabb4f9bacbd82c0e0f94062f
* https://bitbucket.org/lord_mulder/lamexp/commits/0d583cd711ae1807b86d3c8e1d44bd8e7f0b886b

SeeMoreDigital

13th November 2014, 10:30

See these commits, just a few hours ago:
* https://bitbucket.org/lord_mulder/lamexp/commits/add0de2472f9501fabb4f9bacbd82c0e0f94062f
* https://bitbucket.org/lord_mulder/lamexp/commits/0d583cd711ae1807b86d3c8e1d44bd8e7f0b886bAmazing :)

LoRd_MuldeR

25th November 2014, 23:09

LameXP Test-Build r1598 :eek:

This is the first version after major refactoring of the LameXP codebase. Actually, that process is still in progress and will not be completed anytime soon. The reason is that, over the years, a lot of code had accumulated in the LameXP project that was not specific to LameXP at all. Even worse, a lot of that code is required in other projects (Simple x264 Launcher, MediaInfoXP, DoubleFileScanner, etc) too. So far, this had been handled in a "copy and past" fashion, which has lead to loads of redundant code. In the past few days I finally took the opportunity to refactor all the code in LameXP that is not specific to LameXP into a separate library. My goal is to use that library also in all the other projects, once it is complete.

If all went well so far, users should not notice a difference. Anyway, take this version with a grain of salt and please report any regressions you may notice...

SeeMoreDigital

26th November 2014, 11:03

Hello,

I've just tried running the new build using Win10 64-bit Build 9879. And I got this: -

http://i60.tinypic.com/2hp1469.jpg

What does it all mean? Cheers

foxyshadis

26th November 2014, 11:48

http://pldh.net/media/dreamworld/054.png

I'd double-check that all the files were extracted with folders, and barring that see if permissions don't deny anything; that would show up if the imageformats folder is missing or can't be read for some reason.

Mulder, I hate to say it, but I just put this on my new laptop for the first time, and this is one of the more unpleasant "first impressions" of a software I've ever used, up there with Autodesk or Adobe. Four popups in a row, two of which couldn't be clicked away without waiting a few seconds. If I didn't appreciate LameXP's usefulness, I'd immediately remove it.

Regarding AAC popup: I would make that happen when you click on the AAC format, no sooner, rather than greying it out. Actually I'd make it a big warning on the panel, not a pop-up, but sometimes you just have to get in someone's face.

Regarding updates: Holy hell, do that in the background. Reminds me of smplayer's obnoxious "no updates found!" popup every reboot.

Regarding translations: Is annoying thousands of people who can't contribute worth the hope that one might?

SeeMoreDigital

26th November 2014, 12:18

I'd double-check that all the files were extracted with folders, and barring that see if permissions don't deny anything; that would show up if the imageformats folder is missing or can't be read for some reason.

Everything looks to have extracted and the imageformats folder is present. And I tried copying the files within the imageformats folder and placing them within the main folder: -

http://i61.tinypic.com/2qa74mc.jpg

lethedoom

26th November 2014, 16:59

PROBLEM HAS RESOLVED

LameXP Test-Build r1598 is not available.

http://sourceforge.net/projects/lame...5.zip/download

leads to a dead download link or alternatively to

http://sourceforge.net/projects/lamexp/files/Snapshots%20(BETA)/

where 2014-10-05 is now the latest posting. I recall seeing a later file (11/17 ?) which is now gone.

Now it is even worse--basically offline.

The sourceforge.net website is temporarily in static offline mode.
Only a very limited set of project pages are available until the main website returns to service.

SF.net Operations @sfnet_ops
There's instability and frequent 500 errors on the SourceForge site currently. We're working on getting this fixed as soon as we can

LameXP Test-Build r1598 opened without problems and functioned as well as earlier versions. Thanks for your generosity.

I don't know what QAAC is about.Log images attached.

mariush

26th November 2014, 20:23

Latest Avira detects lxp_mpg123.exe as infected with TR/Crypt.XPACK.Gen ... lamexp (1582) crashes with an error "unable to lock file" or something like that.

I agree that the message box with forced delay of 8-10s is over the top.

LoRd_MuldeR

27th November 2014, 01:44

I've just tried running the new build using Win10 64-bit Build 9879. And I got this: -

What does it all mean? Cheers

First of all, it means that I have the message and the title interchanged in that error dialog box :p

Secondly, it means that Qt failed to load its Image I/O plug-in's for some reason :eek:

Actually I was able to reproduce this error on my Windows 10 Preview VM, while it works perfectly fine for me on my Windows XP VM as well as on my Windows 8.1 VM and on my "main" Windows 7 machine :confused:

Either this is some regression in the Preview of Windows 10 that they will fix (hopefully) before the RTM. Or they intentionally changed the DLL loading behavior in a way that breaks Qt's plug-ins :rolleyes:

Everything looks to have extracted and the imageformats folder is present. And I tried copying the files within the imageformats folder and placing them within the main folder

Image I/O plug-ins need to be in the "imageformats" sub-folder for Qt to recognize them:
http://i.imgur.com/HWrzPEP.jpg

Latest Avira detects lxp_mpg123.exe as infected with TR/Crypt.XPACK.Gen ... lamexp (1582) crashes with an error "unable to lock file" or something like that.

If you are an Avira user, you may wish to send a report to the Avira support, so they can fix the bug in their software. Otherwise, just ignore ;)

See also:
http://muldersoft.com/docs/lamexp_faq.html#96205e91

Mulder, I hate to say it, but I just put this on my new laptop for the first time, and this is one of the more unpleasant "first impressions" of a software I've ever used, up there with Autodesk or Adobe. Four popups in a row, two of which couldn't be clicked away without waiting a few seconds. If I didn't appreciate LameXP's usefulness, I'd immediately remove it.

Please note that this is a pre-release beta build and neither the "call for translators" notification nor the "debug console" window is present in regular release builds.

Also note that the notice about the missing AAC encoder will appear only if you haven't installed the Nero AAC encoder yet. Once the Nero AAC binary has been put into the correct place, you'll never see the notice again.

Reviewers even explicitly praise the notification, because "the task is not too difficult to carry out as everything is provided for the job: link to the download file, folder location and step by step instructions".

(Of course I'd prefer to have AAC encoder built-in too, but Nero AAC cannot be redistributed for legal reasons. QAAC isn't a practicable alternative here either, because it depends on the proprietary Apple/QuickTime DLL's)

Regarding updates: Holy hell, do that in the background. Reminds me of smplayer's obnoxious "no updates found!" popup every reboot.

Many users prefer if the application will not talk to external servers "behind the user's back". Obviously, you can't do it right for everybody.

(If with "smplayer" you are referring to my "MPlayer for Windows" package, then the included auto-updater does not check for updates on every reboot. It only does so once every 30 days)

I don't know what QAAC is about. Log images attached.

It means that the optional QAAC add-in is not currently present. If you want to use QAAC (instead of Nero AAC), you may download the required add-in from here (http://sourceforge.net/projects/lamexp/files/Miscellaneous/Add-ins/).

lethedoom

27th November 2014, 06:18

Avast anti-virus stopped the test version from opening. The program then accepted assurance file was safe and could be excluded from scanning.I restored the sequestered files, deleted the record form the virus chest and then was able to open and use the test version. I was unable to satisfy the information requirements of the false positive submission form, so other Avast users may have the same problem.

mariush

27th November 2014, 06:33

The executable is compressed with UPX 3.91 (executable compressor), which is often used by "bad people" to reduce the executable size of viruses, trojans etc ... it's a good valid compressor, but a bad reputation due to the above mentioned things.

You could just unpack the executable (436,238 bytes uncompressed vs 169,998 bytes compressed) and you've solved the antivirus problem instead of just asking people to disable antivirus software or stop using lamexp until antivirus updates signature database (which could be 1-2 weeks).

LoRd_MuldeR

29th November 2014, 03:03

Hello,

I've just tried running the new build using Win10 64-bit Build 9879. And I got this:

http://i60.tinypic.com/2hp1469.jpg

Okay, I now know what caused the problem!

I compiled the program and the "core" Qt DLL's with the current VS2013.4, but for some reason I accidentally included the Qt Plug-in DLL's compiled with VS2010 :o

Mixing DLL's that are linked against different C-Runtimes is a bad idea anyway. But since the VS2010 Runtime DLL's weren't included in the package, the Plug-in DLL's didn't load at all.

(It will be fixed in the next build)

LoRd_MuldeR

29th November 2014, 03:06

LameXP Test-Build r1603 :eek:

New build after more refactoring work has been done. This time hopefully with the correct plug-in DLL's included ;)

lethedoom

29th November 2014, 07:41

SeeMoreDigital

29th November 2014, 11:14

LameXP Test-Build r1603 :eek:
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2014-11-29/LameXP-TEST.2014-11-29.zip/download

New build after more refactoring work has been done. This time hopefully with the correct plug-in DLL's included ;)I'm happy to confirm it's working a treat now with Win10 64-bit Build 9879 :)

LoRd_MuldeR

29th November 2014, 14:28

I extracted the new test folder and scanned it with Avast which reported no threat. LameXP Test-Build r1603 opened without the debug console and successfully converted flac files to mp3. Is this a beta or an unlabelled 4.11 final ?

This is far from anything "final" at this point, as the refactoring process is still going on ;)

I'm happy to confirm it's working a treat now with Win10 64-bit Build 9879 :)

Good to know!

lethedoom

29th November 2014, 17:36

Today Avast deemed the LameXP Test-Build r1603 application a virus and killed it. I tried to download the zip file again and it would not permit the download. I cannot satisfy their demand for information on their false positive form . It is not clear if 'Lord Mulder' as publisher or 'LameXP' as program is deemed not clear enough. I will try to let them know the problem.

I submitted the ticket and hope they respond favorably.If you contact them directly perhaps they can resolve the problem for future iterations.

Posted on: 29 November 2014 18:27
I downloaded from http://sourceforge.net/projects/lamexp/files/Snapshots (BETA)/ the LameXP-TEST.2014-11-29.zip
yesterday. I extracted the files and scanned both the zip and extracted files folders and avast found no threat. I opened the beta application and used it. This morning when I opened the same application Avast identified it as a virus and put it in the chest. I went to the chest and right clicked on the file and chose restore and add to exclusions. I attempted to fill out a false positive form but either 'Lord Mulder' or 'Source Forge' as publisher or 'LameXP' as program was deemed insufficiently informative and form refused to submit. This is a beta program distributed in a zip file which Avast on second thought has labelled Win32:Evo-gen {Susp}. I know what I am doing, I trust Lord Mulder even though he is too stubborn to change his zip program. Please check this folder from http://hivelocity.dl.sourceforge.net/project/lamexp/Snapshots (BETA)/2014-11-29/LameXP-TEST.2014-11-29.zip :

LameXP-TEST.2014-11-29.zip < 16 hours ago 21.4 MB 66 weekly downloads i
SHA1:

09c3216a2decb4f0c980026015b5e0f97c4cf842

MD5:

aac1af01da9ba2ddbc9a76cf699ae70e

Downloads (All-Time):

6
If you agree it is not in fact malware please find a way to recognize the false positive and allow me to receive the folder and use the beta application.v

mariush

29th November 2014, 22:30

lethedoom, when LameXP starts it creates a temporary folder on your hard drive and extracts several applications into that folder.

One of those applications is called lxp_mpg123.exe and that's probably the file that's one of the reasons antivirus software may report it as virus.
That's now the case with Avira and Ikarus as you can see here: https://www.virustotal.com/en/file/eddb524969865500ae44dd9a80a679d342ee6755e3bda5877f9fa3729b396038/analysis/1417295691/ (virustotal report for lxp_mpg123.exe).

LameXP.exe itself is compressed with UPX, the same executable compressor that's used in lxp_mpg123.exe

UPX is a legitimate compressor but the compression techniques it uses are often used in warez and trojans and dubious applications so it's normal that some antivirus software will do a false positive from time to time.

Mulder, I personally really don't see the point of compressing the executables with UPX.

upx says: 18203136 <- 16486912 90.57% win32/pe lame.exe

So you've saved a bit fat 2 MB by compressing your executable but you added the risk of antivirus software detecting your application as malware.

In the world of 1-4 TB hard drives people won't care that your application is 30-50 MB instead of 20 MB.
There's also no point in compressing those external executables when you can already compress them inside your main executable. As a suggestion - and I'm not sure, didn't bother to check source code, probably this is how you already do it now - you could 7z the files and embed the 7z inside the executable and you have a free 7z decoder library to unpack the contents nice and fast.

In addition, there's really no point in extracting all those files every time the application launches. Why not unpack the needed application when an encoding job is actually started?

Also... nowadays it really doesn't matter that much but in the past people with SSD drives would probably have cared about programs writing stuff to their boot drive at every launch.

And btw, I went into Advanced options and unchecked "Stored temporary files" and selected another folder and those executables are still unpacked there in the system default temp directory.

LoRd_MuldeR

30th November 2014, 16:16

UPX is a legitimate compressor but the compression techniques it uses are often used in warez and trojans and dubious applications so it's normal that some antivirus software will do a false positive from time to time.

I agree with this. But the conclusion to draw can not be that legitimate software should stop using a legitimate compressor, just because some malware uses the legitimate compressor!

The job of an Antivirus is to block malware while not affecting legitimate software in any kind of way. If legitimate software is affected, this is a bug in the Antivurs software and needs fixing in the Antivirus software.

Suspecting software of being malware, just because it uses an EXE packer, is just plain stupid! It's an invalid generalization, just like:
"Since 99% of all terrorists had bread for breakfast the day they went on rampage, all people who eat bread for breakfast probably are terrorists".

Antivirus software must be aware of "EXE packers", yes. But by analyzing the decompressed binary code in memory, not by analyzing the compressed code in the EXE file or, even worse, by stupid/invalid generalizations.

If we are at the point where Antivirus companies decided which legitimate techniques may be used by software developers and which legitimate techniques have to be avoided, because otherwise you will be blocked, there is only one name for this: Blackmail. And this cannot (and will not) be tolerated. So, this alone, is more than enough reason to continue using UPX, until even that last intellectually challenged person at those Antivirus companies has finally understood it.

Fortunately, Windows 8 ships with a (decent) free Antivirus software, so less and less people will pay for (crappy) Antivirus products. So, hopefully, most of the Antivirus companies will either change their field of business or go bankrupt...

[/rant]

In addition, there's really no point in extracting all those files every time the application launches. Why not unpack the needed application when an encoding job is actually started?

It was major design decision to completely setup the application "environment" during the startup sequence. It means that, once the application has been started, we can be sure that all the required tools are in place and can be used when needed. If anything goes wrong during initialization, the application won't even launch. So you get either a 100% working state or nothing at all. You never get the application in some semi-broken state.

Extracting the tools "on demand" would be possible, but then errors would be much more difficult to handle. If anything goes wrong during extraction, it would probably happen in some background worker thread where the tool happens to be accessed for the first time. Propagating the error to our GUI/Main thread and finally having to stop all the other worker threads, before we can shut down "gracefully" would be much more complex and error prone than the current method...

And btw, I went into Advanced options and unchecked "Stored temporary files" and selected another folder and those executables are still unpacked there in the system default temp directory.

This option only controls where intermediate Wave files will be located. Extracting the tools happens in a much earlier stage of the initialization process, long before any user options are loaded.

mariush

30th November 2014, 17:36

So what are you really trying to do, are you on a crusade against antivirus software, or are you simply trying to write good software?

At some point, you drop the idealism and put your "customers" first, the people using the software. Your small application with maybe a few thousand active users is a drop in the ocean, you're not a priority for antivirus software makers. But you may be alienating people with your choices.

You have a large variety of users using your software, and not all of them are smart. Some may be so stupid they won't even understand what the error messages say, they'll just see the antivirus say it's a virus and they'll remove the application and stop using it for ever. Once trust is broken, they may never use it again.

In this particular case, using that compressor only has downsides. It's a poor use of technology. (but then again, it's not the only thing you're using just because you can, like those sounds in the license agreement and about screens)

You're compressing your application to 90%, so you're not saving significant disk space... you basically saved about 2 MB.
You're increasing the load time of your application because any antivirus software will have to load those 20 MB in memory, decompress it, scan for viruses and then allow the process to start.

I would also say you're making your own software harder to update but I guess this (how you update your software) is entirely your choice. For example, since you're embedding all those files inside the executable, I would take advantage of this and change the update mechanism to either download the full setup (20 MB or something) or choose to download a "binary patch" that you can simply create using a software like xdelta ( http://xdelta.org/ open source, you can easily incorporate the patch functionality in the app). So instead of downloading 20 megs, the update can download 1-2 MB of diff, create a new .exe from the old one and the information in the patch file and then replace the old executable. Lots of people still download with 50-100 KB/s (as you can see for yourself if you check the download logs) so spending just 10-15 seconds to download a patch instead of 5 minutes would only benefit and would be less annoying to users.

Using upx simply screws this up, because even a single byte change would change the whole executable after compression and prevent you from making a proper binary diff between two executables.

It was major design decision to completely setup the application "environment" during the startup sequence. It means that, once the application has been started, we can be sure that all the required tools are in place and can be used when needed. If anything goes wrong during initialization, the application won't even launch. So you get either a 100% working state or nothing at all. You never get the application in some semi-broken state.

I'd rather have the application self-contained in a folder, where I put it. If I install it in D:\Programs\Lame , I don't expect it to write tens of megs to c:\ [...] \ TEMP folder. I'd rather have a Lame\Tools or Lame\Temp folder created automatically and so on. Or let user choose.
Maybe I run my Windows from a 64 GB SSD and I only have 300-500 MB free on the SSD. I wouldn't like to kill write cycles in those 300-500 MB of free space with 20-30 MB of tools. I know, it's unlikely, but you never know.

Also consider that you may want to make a "portable" version of the application, in which case having the files extracted in a subfolder would make it easy for you to just set some flags inside your application to just check for existence of those files at start instead of trying to unpack them from the executable each time.

lethedoom

30th November 2014, 17:45

Well, even if your cause is just since I use Windows 7 and thus require some anti-virus program, all of which read the test files as suspected virus, I will not be able to acquire and try the betas under present circumstances. Fortunately the LameXP v4.10 Setup (21.0 MB) download and 4.10 final zip download are not blocked today by Avast and hopefully neither will final 4.11 be blocked. Thanks again for your generous provision of this freeware tool. In my view the free anti-virus program providers are internet public health workers and not bad guys. My problem with Avast is it will not let me override their 'suspect' label and are slow to test and certify as safe files that are submitted for reconsideration.

SeeMoreDigital

30th November 2014, 17:59

Well, even if your cause is just since I use Windows 7 and thus require some anti-virus program...Hmmm...

When I had Windows 7 installed, I ran Microsoft's own Security Essentials anti-virus software. Same too with Windows 8, Windows 8.1 and now with Windows 10. I've never seen a virus warning when installing LameXP.

LoRd_MuldeR

30th November 2014, 18:04

So what are you really trying to do, are you on a crusade against antivirus software, or are you simply trying to write good software?

What a specific proprietary so-called "Antivirus" software does (or does not do) is completely irrelevant to my decisions. As long as my software doesn't do anything that, without any doubt, classifies as "malware behavior" - and that certainly is not the case here - any so-called "Antivirus" software is strictly forbidden to interfere with my software in any possible kind of way. If it does so anyway, that's a bug, in the particular so-called "Antivirus" software. Bugs can happen. Bugs do happen. But I can only fix bugs in my own software. It's definitely not my job to fix bugs in proprietary so-called "Antivirus" software, created by some commercial company that I have no relation to. Also, I certainly will not implement any workarounds for buggy so-called "Antivirus" software, since that is completely pointless! There are hundreds of so-called "Antivirus" products out there. And since those products are proprietary software, we can only speculate what has gone wrong "behind the scenes" when our legitimate software gets blocked for no good reason. Even worse, behavior of the proprietary so-called "Antivirus" software can change at any time, e.g. with the next signature update. So should I implement highly speculative workarounds for hundreds of different so-called "Antivirus" programs? Workarounds that, if at all, will help only for a short time? Workarounds that would forbid me to make use 100% legitimate techniques? Certainly no, not in this life! :)

So what can be done? Educate people! If somebody is a paying customer of a so-called "Antivirus" software and that software doesn't work correctly, he or she must contact the support team and file a bug report. That's the one and only way to get the bugs fixed. Also, if the manufacturer doesn't fix bugs (in time), it's up to the paying customer to cancel his contract and get his or her monkey back. You certainly don't have to stick with a product that is a buggy mess...

Hmmm...

When I had Windows 7 installed, I ran Microsoft's own Security Essentials anti-virus software. Same too with Windows 8, Windows 8.1 and now with Windows 10. I've never seen a virus warning when installing LameXP.

Security Essentials seems to be one of the Antivirus programs that tend to be less overcautious ;)

And it's also clear why: Microsoft decided to give away Security Essentials for free, so it doesn't need to continuously scare the user with (alleged) "virus alters", in order to legitimize the subscription fees...

(It's safe to assume that in other Antivirus companies it's the marketing department who tells their programmers how often, e.g. at least once per week, each customer must see a virus alert)

LoRd_MuldeR

30th November 2014, 19:12

I'd rather have the application self-contained in a folder, where I put it. If I install it in D:\Programs\Lame , I don't expect it to write tens of megs to c:\ [...] \ TEMP folder. I'd rather have a Lame\Tools or Lame\Temp folder created automatically and so on. Or let user choose.
Maybe I run my Windows from a 64 GB SSD and I only have 300-500 MB free on the SSD. I wouldn't like to kill write cycles in those 300-500 MB of free space with 20-30 MB of tools. I know, it's unlikely, but you never know.

Also consider that you may want to make a "portable" version of the application, in which case having the files extracted in a subfolder would make it easy for you to just set some flags inside your application to just check for existence of those files at start instead of trying to unpack them from the executable each time.

It is already possible, for quite some time now, to use your own tool binaries.

See here:
http://muldersoft.com/docs/lamexp_faq.html#3d6684e9

LoRd_MuldeR

30th November 2014, 22:07

LameXP Test-Build r1608 :eek:

New build. This should fix a few bugs introduced in the previous build(s). So if you encountered strange crashes, this will fix it, hopefully.

lethedoom

1st December 2014, 07:29

Avast is blocking LameXP Test-Build r1608 too. I thought about accepting the suggestion to change to Security Essentials, but the reviews deem it so weak I will not. For what it is worth I followed my support request to Avast asking them to agree their label is a false positive with a forum posting. I hope it will get some response.

lethedoom

1st December 2014, 16:23

I received an email from Avast acknowledging that their decision had been a false positive. I was able to download the newest Test version, so they have updated their virus definitions to fulfill their stated intention. fyi:
Hello
Thank you for contacting our support center with your concerns.Thank you for your message.It's false positive. The detection will be fixed in the next VPS.We are sorry for the inconvenience.If I can be of any further assistance, please do not hesitate to contact me again.
Best regards,
Lukas Havel
Technical Support Specialist

www.avast.com

Ticket Details
Ticket ID: YXL-216-11481
Department: Virus and FP reports
Type: FalsePositive
Status: On Hold
Priority: Normal
Support Center: https://support.avast.com/index.php?

I converted two groups of .shn files to .mp3 without any problems with this test version.

LoRd_MuldeR

6th December 2014, 01:34

LameXP Test-Build r1624 :eek:

More refactoring has been done. But, most important, I tracked down and fixed (hopefully) a long-standing problem in the worker thread creating code, which caused an unnecessary slow-down of the "worker" process creation and also made the GUI less responsive than it should be. Things appear to run quite a bit more smoothly now, especially when you crank up the number of parallel encoder instances! Limit for the number of parallel instances has been raised to 32 too...

LoRd_MuldeR

13th December 2014, 23:51

LameXP Test-Build r1628 :eek:

LameXP r1582 vs. r1624:
http://i.imgbox.com/3G4Zr9xT.png (https://vimeo.com/114437958)

SeeMoreDigital

14th December 2014, 01:02

Jeez... That looks fast :)

mariush

14th December 2014, 01:20

86 wav files that are a few seconds each... seems kind of a pointless test.

LoRd_MuldeR

14th December 2014, 01:58

86 wav files that are a few seconds each... seems kind of a pointless test.

Not pointless at all, considering that this was chosen specifically to illustrate the specific problem that has been fixed recently. Nowhere I said that this is supposed to be the most common use case :)

Anyway, it should be clear that the longer the individual files are, the more time each encoding task takes to complete - and thus the "freeze" that did happened on the creation of each new task will become less apparent.

Conversely, with an increasing number of CPU cores the problem increases! I have report from one person who ran a test with ~1200 regular audio files on a 20 cores machine that there was a huge speed up.

lethedoom

14th December 2014, 05:14

LoRd_MuldeR

14th December 2014, 14:42

I have downloaded and used the test builds provided on 2014-12-13, 2014-12-08, 2014-12-06, 2014-12-05,2014-11-30 since my antivirus program stopped blocking the zips. Taking your point that more instances are better I use 32 on my i5 dual core Win 7 PC with the test builds and I find the increase in speed quite substantial compared to LameXP v.4.10 final. I download trade friendly artist live concerts (usually flac) with Deluge and convert them to mp3 with LameXP almost daily. Thanks again for your very useful tool which you share as a gift.

Just to clarify: I did not say "that more instances are better" in general. What I said is that the recent fix will probably give the most noticeable improvement when you run a high number of instances in parallel. But that does not mean that you are supposed to crank up the number of parallel instances just because you can. It usually doesn't make much sense to run more instances in parallel than you have (logical) CPU cores available - even though this should work much better now with the "new" version. Furthermore, because of the possible I/O bottleneck, running too many instances in parallel may even considerably slow things down! Though the use of SSD's should eliminate the I/O bottleneck issue to a large extent...