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

[tipsypenguin]

for some reason my antivirus is blocking tool_flac.exe as Suspicious.MH690.A every time I start LameXP

[LoRd_MuldeR]

Originally Posted by tipsypenguin

for some reason my antivirus is blocking tool_flac.exe as Suspicious.MH690.A every time I start LameXP

Please check the file again at http://www.virustotal.com/, just to be sure, and then report the FALSE POSITIVE to the developer of the a/v software.

[lethedoom]

Thank you for this excellent free tool--you are my benefactor.

I see no reason to choose to use the slower 4.0 ( I did install and try the final version today ) when I have had no problems at all using the much faster 3.18--the same resources are used (100% cpu) and no hard drive problems ever occurred on my pc while using 3.18 running 8 simultaneous processes. As I am just a pedestrian computer user--neither expert nor a programmer--your arbitrary limit makes no sense to me in light of my usage experience.

[LoRd_MuldeR]

Originally Posted by lethedoom

I see no reason to choose to use the slower 4.0 ( I did install and try the final version today ) when I have had no problems at all using the much faster 3.18--the same resources are used (100% cpu) and no hard drive problems ever occurred on my pc while using 3.18 running 8 simultaneous processes. As I am just a pedestrian computer user--neither expert nor a programmer--your arbitrary limit makes no sense to me in light of my usage experience.

I do not have a machine with more than 4 cores available for testing. And I doubt there currently are many users that do

While I still doubt that running zillions of instances in parallel is a very good idea, I can add an option to configure the maximum number of instances in one of the future versions...

[manolito]

Latest findings about these funny Wave files created by ValibDec:

[UPDATE] I just downloaded a Demo version of Wave Lab 5 and finally got it to work on my Windows XP VM. And it turns out that Wave Lab opens the Wave file written by ValibDec flawlessly [/UPDATE]

I never said otherwise. See my previous posts:

And now my question which concerns AC3 to WAV conversion:
Whenever I convert a 2-channel AC3 to WAV with LameXP, this WAV file plays OK in MPC, WaveLab also has no problems with it. But when I try to use this file with MuxMan to author a DVD, MuxMan rejects the file.

Another strong indication that ValibDec is to blame is that if you open and resave these problematic files in a wave editor (I tried WaveLab, Nero Wave Editor and Audacity), MuxMan has no problems with the resaved files.

In the meantime I found that two other audio converters I frequently use also reject these Wave files:

BeLight 0.2.2.0 (this is the latest version) by Kurtnoise simply refuses to load the file without any error message.

HeadAC3he 0.24 a13 by Dark Avenger also does not accept these files. But it displays the following error message: "Could not find fmt chunk!"


I also found an old app called StripWav which can strip extra information from a Wave file header and convert the header to the "canonical" format. This app determines: "Extra chunks: JUNK". Needless to say that the stripped file does work with MuxMan, BeLight and HeadAC3he.


My conclusion: Even if these files created by ValibDec may not be technically illegal, they certainly have a very unusual header leading to an incompatibility with a couple of other applications.


Cheers
manolito

[LoRd_MuldeR]

Originally Posted by manolito

HeadAC3he 0.24 a13 by Dark Avenger also does not accept these files. But it displays the following error message: "Could not find fmt chunk!"

I also found an old app called StripWav which can strip extra information from a Wave file header and convert the header to the "canonical" format. This app determines: "Extra chunks: JUNK".

Well, I can confirm that the Wave file written by ValibDec contains a 'JUNK' chunk before the 'fmt' chunk. The file that has been piped through SoX (and is accepted by MuxMan) does not

However this is not "unusual" at all: RIFF files often contain 'JUNK' chunks for padding. And, by definition of the RIFF format, a reading application must ignore/skip all the 'JUNK' chunks that it encounters!

Some applications might not implement a real RIFF parser and instead expect the 'fmt' chunk ("Wave header") to be located at a hard-coded position; may it be for simplicity, laziness or nescience.

But it is obvious that such applications are prone to fail on certain valid RIFF/Wave files. Consequently I think we really can't/shouldn't blame the writing application here...

[Taurus]

Originally Posted by manolito

I also found an old app called StripWav which can strip extra information from a Wave file header and convert the header to the "canonical" format. This app determines: "Extra chunks: JUNK". Needless to say that the stripped file does work with MuxMan, BeLight and HeadAC3he.

Thank you for this suggestion, something for my audio toolbox...

[lethedoom]

Originally Posted by LoRd_MuldeR

I do not have a machine with more than 4 cores available for testing. And I doubt there currently are many users that do

While I still doubt that running zillions of instances in parallel is a very good idea, I can add an option to configure the maximum number of instances in one of the future versions...

I will be grateful when you do that. When any version of LameXP is running and using up the available cpu capacity on my pc the cpu core temperatures rise. The slower 4.0 iteration of LameXP exposes the cpu cores and mainboard to the elevated temperature for a longer time which I surmise is undesirable in regard to maximizing their useful lifetimes. My pc is only dual core, but it also creates two virtual cores and each of the four cores runs two processes totalling eight concurrently using 3.18. That is what I would want 4.0 to do as well.

[mariush]

lethedoom you don't have to worry about that... both the motherboard and the cpu are designed to work at elevated temperatures for a long time, it really won't make a difference to their lives whether the cpu warms up the components or not. In fact it's better to keep the cpu at a higher yet steady temperature rather than just oscillate between cold and warmer cycles.

But it's all statistical anyway, the "life" of a cpu will drop due to temperature cycles from a few million hours to a few million hours - a few thousand - the difference is so small your cpu would be antique before it dies.

ps. The majority of components sensitive to heat on a motheboard (capacitors) are rated 85-105 C - so in order for a motherboard to fail, the temperature inside your computer case would have to be around 60-70C for days (capacitors get "older" faster as temperature is closer to their highest rating) in order to weaken these components. At the normal 30-40C temperature inside the case, these last for at least 5-10 years. By that time, you'll probably change several computers.

[LoRd_MuldeR]

Originally Posted by lethedoom

I will be grateful when you do that. When any version of LameXP is running and using up the available cpu capacity on my pc the cpu core temperatures rise. The slower 4.0 iteration of LameXP exposes the cpu cores and mainboard to the elevated temperature for a longer time which I surmise is undesirable in regard to maximizing their useful lifetimes.

Now that is nonsense, really

I've got my Intel Q6600 for more than four years now. And this machine is running like 8-12 hours every single day. I also use this machine for video encoding, so often the CPU's is running with 100% load on all four cores for several hours! That all is with the crappy "boxed" cooler. And, as you can see, I'm still online. So the machine has not exploded yet.

Moreover, running more instances in parallel in order to increase the CPU load would produce even more heat. So with your argumentation this would be the exact opposite of what you want...

Originally Posted by lethedoom

My pc is only dual core, but it also creates two virtual cores and each of the four cores runs two processes totalling eight concurrently using 3.18. That is what I would want 4.0 to do as well.

That makes even less sense. If you really have a Dual Core processor (two physical cores), then even with Hyperthering enabled you have at most four (logical) cores available.

On such a machine running four instances in parallel is sufficient to fully utilize the CPU. Running even more instances than (logical) cores in parallel is pointless if not counterproductive.

[lethedoom]

Originally Posted by LoRd_MuldeR

Now that is nonsense, really

I've got my Intel Q6600 for more than four years now. And this machine is running like 8-12 hours every single day. I also use this machine for video encoding, so often the CPU's is running with 100% load on all four cores for several hours! That all is with the crappy "boxed" cooler. And, as you can see, I'm still online. So the machine has not exploded yet.

Moreover, running more instances in parallel in order to increase the CPU load would produce even more heat. So with your argumentation this would be the exact opposite of what you want...



That makes even less sense. If you really have a Dual Core processor (two physical cores), then even with Hyperthering enabled you have at most four (logical) cores available.

On such a machine running four instances in parallel is sufficient to fully utilize the CPU. Running even more instances than (logical) cores in parallel is pointless if not counterproductive.

You are the expert, but nonetheless 3.18 accomplishes the job faster than 4.0 and does not drive core temperatures higher.

[LoRd_MuldeR]

Originally Posted by lethedoom

You are the expert, but nonetheless 3.18 accomplishes the job faster than 4.0 and does not drive core temperatures higher.

Did you actually stop the time? Or did you just look at the "CPU Utilization" in Task-manager?

Also: Are you 100% sure that you were using the same settings (rate-control mode + LAME algorithm quality) and the same input files for both versions?

Finally I don't think that the overall encoding process takes long enough to have a significant impact on the CPU temperature, unless you really process a huge number of files.

And even if the temperature did increase, you wouldn't have to worry, as the CPU is designed to run under full load for a long time.

If the CPU temperature ever reaches a "critical" level under load, then you should check whether the cooler in stalled correctly! Also cleaning the dust can work wonders

(For clarification: Can you please post a screenshot of CPU-Z running on your computer?)

[manolito]

Re problematic Wave files created by ValDec:

After some more research I believe I understand the problem now. The whole thing is about the RF64 Wave format extension which was introduced by the EBU around 2006.

This RF64 format is required if a Wave file gets bigger than 2GB. If an application writes a RF24 compatible Wave file, it inserts a JUNK chunk into the header. As long as the file size stays below 2 GB this JUNK chunk is just a placeholder and has no meaning, applications should ignore it. But if the size grows beyond the 2 GB limit, the RIFF header has to be replaced by a RF64 header which is bigger. This is why the JUNK chunk is needed.

But of course older software (pre 2006) has no knowledge of this JUNK chunk and often throws an error.

I just made some tests with WaveLab 6 which has an option to support the RF64 format (disabled by default). The results are pretty clear. With the RF64 option enabled it creates files which are not compatible with MuxMan, with the option disabled it produces compatible files.

Obviously ValDec always creates RF64 enabled Wave files, I have not found an option to turn this RF64 support off.


Maybe LameXP should have a checkbox "RF64 support" under the Wave output tab. If this checkbox is not checked then the output should always be piped through SoX.


Cheers
manolito

[LoRd_MuldeR]

Originally Posted by manolito

Re problematic Wave files created by ValDec:

After some more research I believe I understand the problem now. The whole thing is about the RF64 Wave format extension which was introduced by the EBU around 2006.

This RF64 format is required if a Wave file gets bigger than 2GB. If an application writes a RF24 compatible Wave file, it inserts a JUNK chunk into the header. As long as the file size stays below 2 GB this JUNK chunk is just a placeholder and has no meaning, applications should ignore it. But if the size grows beyond the 2 GB limit, the RIFF header has to be replaced by a RF64 header which is bigger. This is why the JUNK chunk is needed.

But of course older software (pre 2006) has no knowledge of this JUNK chunk and often throws an error.

I just made some tests with WaveLab 6 which has an option to support the RF64 format (disabled by default). The results are pretty clear. With the RF64 option enabled it creates files which are not compatible with MuxMan, with the option disabled it produces compatible files.

Obviously ValDec always creates RF64 enabled Wave files, I have not found an option to turn this RF64 support off.

Maybe LameXP should have a checkbox "RF64 support" under the Wave output tab. If this checkbox is not checked then the output should always be piped through SoX.

Cheers
manolito

Well, this explains why the 'JUNK' chunk is inserted

Still this "RF64" extension obviously was designed with backward-compatibility in mind. Therefore the additional information is stored inside a 'JUNK' chunk, which according to the RIFF specifications will be ignored/skipped by all "legacy" application, instead of modifying existing structures. So as long as the file size doesn't exceed a size of 4GB, legacy applications that don't support RF64 should still handle such files perfectly fine. And obviously most application do! Those that stumble upon the additional 'JUNK' chunk were broken from the beginning. Of course I could easily add an option to pipe the output Wave file through SoX. But somehow I dislike the idea of adding workarounds for specific third-party applications into LamXP, especially when the problem should actually be fixed on their side...

[CORRECTION] Actually ValibDec does NOT create RF64 Wave files, unless the file actually exceeds a size of 4 GB! It just inserts an empty 'JUNK' chunk at the beginning of the file as a placeholder. All compliant reading applications will later ignore that chunk. The placeholder is required, because if the file does exceed a size of 4 GB, then the 'ds64' chunk must be written to that location later on. [/CORRECTION]

[LoRd_MuldeR]

Originally Posted by lethedoom

I spend a lot of time downloading Grateful Dead concerts from bittorrent sites...

Err...

http://forum.doom9.org/forum-rules.htm

[manolito]

Originally Posted by LoRd_MuldeR

Actually ValibDec does NOT create RF64 Wave files, unless the file actually exceeds a size of 4 GB! It just inserts an empty 'JUNK' chunk at the beginning of the file as a placeholder.

This is exactly what I was saying:

Obviously ValDec always creates RF64 enabled Wave files

RF64 enabled means that as long as the file size is small enough it will have a RIFF header with an additional JUNK chunk so the header could be replaced later by a RF64 header.


Maybe there is another point I can make to push you in my direction...

LameXP is a front end for many different encoders and decoders to shield users from the various peculiarities of all these different tools. Shouldn't LameXP produce consistent output files regardless of the tools it uses in the background?

If I create a Wave file from an MP3 source, it will NOT be RF64 enabled, it does not have a JUNK chunk in its header. (I did not test other source formats, but I assume they also will not have this JUNK chunk). For any source format, if I enable the resampler (SoX), then the output Wave file will not have the JUNK chunk. Only if I happen to make a straight AC3 to WAV conversion using ValDec I get these files with a JUNK chunk in the header.

Anyways, it's your baby...

Cheers
manolito

[lethedoom]

Originally Posted by LoRd_MuldeR

Err...

http://forum.doom9.org/forum-rules.htm

I'm not sure what you mean. per your request there is a better CPU Z image posted at

http://profile.imageshack.us/user/lethedoom

[mariush]

http://code.google.com/p/ac3filter/s...cpp?repo=valib

line 35. Add some parameter to switch between old style or new style wave file on creation and if old style is selected, then don't write the junk header in the first place? You already modified it to support unicode so why not add a command line switch like -format=auto,old,force-64bit etc...

Isn't the app aware or can't it compute the final length before it outputs the wav file to disk?

[mariush]

lethedom : what he means is that it's against the rules to discuss or help people that ask for help in regard to pirated content. It's OK if you bought the DVD and wish to make backups but if you say something about downloading content without having rights to distribute it or process it, you may be banned as it's against the rules.

So getting back to your gpu-z picture. Your CPU is a i5 650 - that's dual core, but you can enable hyperthreading and have 4 cores (2 physical and 2 virtual). The two virtual cores will never be quite as fast as the real cores, as the cpu creates these two virtual cores by looking at how much each of the two real cores are loaded and then giving what the operating system assigned to a virtual core to the less used real core. Basically when a thread assigned to a real core doesn't have much to do for a few nanoseconds, the thread that was set by the operating system to run on a virtual core runs on this real core.

If you'd configure a program like x264.exe (which is very optimized for multithreading) to run with 2 threads encoding something at very high quality, you'll probably see that the 2 virtual cores won't be used much, because the real cores will have very little idle time and the cpu won't find the opportunity to run threads assigned to the virtual cores on the real cores.

This processor you have is designed to run each of those cores at minimum 3.2 Ghz and a maximum of 3.46 Ghz, depending on how much loaded they are. This processor is very powerful, so I would guess encoding an MP3 from a wav file would probably use about 15-20% of the cpu, maybe even less. This means that without even enabling those virtual cores, your processor could easily encode about 5 mp3 tracks at the same time, if the hard drive can keep up with reading 5 wav files from the disk at the same time.
When you enable hyperthreading, you add two virtual cores to the processor, which are not as powerful as the normal physical cores as I explained above, so I would guess these two virtual cores could add up about 30% of power, allowing you to encode an additional 2 mp3 files at the same time.

So in total, your processor and system could very well encode using eight threads (or eight individual files) or more and depending on the quality settings you use, maybe not even be 100% loaded, but your case is very particular - it's a very recent powerful cpu. Most people using dual core processors would have older processors that are not as powerful as yours and allowing 8 threads or more for dual core processors on those older systems would make the encoding very slow, because probably the hard disks on those systems wouldn't keep up.

I'm not sure if I've explained it right but I hope it helps.

[mariush]

Oh wow... hey, thanks i guess but no need to tell me, I'm not a mod or admin here. I just told you because I know the mods here are somewhat paranoid and start to ban people or close threads just for saying "torrent" or "downloaded" (even though he may have PURCHASED and downloaded and wants to re-encode for his own backup).