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

[lethedoom]

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]

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 (http://www.cpuid.com/softwares/cpu-z.html) 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]

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...

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.

[LoRd_MuldeR]

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

Err...

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

:rolleyes:

[manolito]

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...:D

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]

Err...

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

:rolleyes:

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/source/browse/valib/sink/sink_wav.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).

[lethedoom]

thank you for the technical explanation.

[Przemek_Sperling]

Thank you very much. Everything works great!

BTW, can anyone explain me why newer Ogg encoders produce significially larger files than the older ones? I compared files produced by LameXP 3.18, LameXP 4.00, and jetAudio 8.0.11. I encode music at Q8 (e.g. Mana - "Arde el Cielo - Vivo"). The sizes of the compressed CD are: LameXP 3.18 - 130 megabytes, LameXP 4.00 - 158 megabytes, and jetAudio 8.0.11.1600 - 159 megabytes.

[tipsypenguin]

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.

I reported the false positive to Symantec and they are going to remove the detection from within their products . an update will be distributed in the next set of virus definitions.

Thanks for the new LameXP

[LoRd_MuldeR]

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).

If he had purchased the stuff, he wouldn't download it "from bittorrent sites". Nor does this sound like he tries to make a backup ;)

Also this has nothing do with "paranoia". This forum has clear rules that all users accept when signing up. And the job of the moderators is to uphold these rules.

The sensitivity for "warez" is high, yes. And that's for good reason. We don't want that the people who are running this board get into serious trouble!

But if a user thinks his post/thread was removed/closed for no good reason, then he can always send a PM to the moderator in order to clarify the situation...


http://code.google.com/p/ac3filter/source/browse/valib/sink/sink_wav.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?

The decision between "old style" and "new style" (RF64) Wave files is done when the file is closed, because prior to that point the Wave writer can't know if the final size will be above 4 GB or not.

In any case the 'JUNK' chunk has to be written at the beginning of the file, because we must be prepared for writing the "ds64" chunk later, if necessarily.

And to make this clear again: When the final size is below 4 GB, then ValibDec writes a perfectly valid RIFF/Wave file. The 'JUNK' chuck doesn't matter, as all reading application must ignore that chunk.

It is evident that that applications which fail to read the Wave file just because of the additional 'JUNK' chunk are broken!

Consequently the one and only question here is: Do we care enough about these broken applications to implement a workaround? Or should we encourage the authors to fix their RIFF/Wave parsers?

(If we modified the Wave writer to not write the 'JUNK' chunk, we couldn't turn the file into a RF64 file later anymore, which means we would kill support for output files larger than 4 GB)


I reported the false positive to Symantec and they are going to remove the detection from within their products . an update will be distributed in the next set of virus definitions.

Thanks for the new LameXP

Well done :thanks:


BTW, can anyone explain me why newer Ogg encoders produce significially larger files than the older ones? I compared files produced by LameXP 3.18, LameXP 4.00, and jetAudio 8.0.11. I encode music at Q8 (e.g. Mana - "Arde el Cielo - Vivo"). The sizes of the compressed CD are: LameXP 3.18 - 130 megabytes, LameXP 4.00 - 158 megabytes, and jetAudio 8.0.11.1600 - 159 megabytes.

Well, I assume you are using the "quality-based" (VBR) rate-control mode, as with the "bitrate-based" (ABR) mode the resulting file size would be defined solely by the chosen target bitrate.

The differing output sizes with VBR mode can be explained by different versions of OggEnc (libvorbis) being used. However comparing only the file sizes between the different versions doesn't tell you anything!

Instead you would have to adjust the VBR values, until both files have the same file size again. Then (and only then) you can compare the sound quality and decide which version is better...

(Alternatively you could adjust the VBR values until both files have the same sound quality and then compare the files sizes. But that's probably hard to do ^^)

[mariush]

What I'm saying is that since you're modifying that tool to add Unicode support, you could in theory add a switch in the command line options (or some way to pass this to the tool, not sure how your app interacts with it), so that the tool will "TRUST" you that the output wav file will NOT exceed 4 GB or whatever the limit is. If the flag/switch in the command line is missing, just work like it works now. You should be able to determine based on number of seconds and channels the mp3/ac3/etc how much data you will have so you could pass this switch safely for files you know they won't reach that limit.

So if you pass that flag, let's say "-force-old-wav", the wav output class/whatever stores it, does not write the junk bytes at all and when closing the file, if the actual data is larger that what's allowed, enter the maximum allowed.

If total length and data is smaller than the limit for the format, it will play on all software, no junk, no ds64 chunk
if total lenght and data is larger, it will still play on all software, no junk or ds64 chunk but the data in the header will record the maximum number of samples allowed (basically truncating everything over max samples). So the rest of the data in the wav file would be ignored by players (not sure, maybe you'd need to seek to the end of the maximum samples and write there the ending for the chunk).

[LoRd_MuldeR]

What I'm saying is that since you're modifying that tool to add Unicode support, you could in theory add a switch in the command line options (or some way to pass this to the tool, not sure how your app interacts with it), so that the tool will "TRUST" you that the output wav file will NOT exceed 4 GB or whatever the limit is. If the flag/switch in the command line is missing, just work like it works now. You should be able to determine based on number of seconds and channels the mp3/ac3/etc how much data you will have so you could pass this switch safely for files you know they won't reach that limit.

So if you pass that flag, let's say "-force-old-wav", the wav output class/whatever stores it, does not write the junk bytes at all and when closing the file, if the actual data is larger that what's allowed, enter the maximum allowed.

If total length and data is smaller than the limit for the format, it will play on all software, no junk, no ds64 chunk
if total lenght and data is larger, it will still play on all software, no junk or ds64 chunk but the data in the header will record the maximum number of samples allowed (basically truncating everything over max samples). So the rest of the data in the wav file would be ignored by players (not sure, maybe you'd need to seek to the end of the maximum samples and write there the ending for the chunk).

Yes, it should be possible to add such an option.

Still that option would only be helpful as a workaround for broken reading applications, which do not handle the 'JUNK' chunk as they are supposed to :devil:

Fortunately most applications are not broken in this regard. So I currently think this wouldn't be worth the effort.

Especially when considering that, in case you really encounter one of the broken applications, the solution is very easy: Re-save the file with SoX once and that's it.

Probably I will add a short note about this issue to the F.A.Q. document and then let the matter rest... Done!

[mpucoder]

Now that I am aware of the reason for the junk chunk prior to the fmt chunk I'll begin modifying versions of MuxMan starting with the Pro version, then back-stitched to the free version.

[manolito]

@mpucoder,

thank you very much, looking forward to the new version...

Cheers
manolito

[ckmox]

thanks a lot for the final release :)

[IgorC]

Any particular reason for including unstable alpha to supposedly stable and final GUI?

LAME 3.99a is on heavy alpha development and far from any beta release right now. It's untested.
No warning or any message for user? No choice between stable 3.98.4/unstable 3.99?


A huge thanks for the final release.

[LoRd_MuldeR]

Any particular reason for including unstable alpha to supposedly stable and final GUI?

LAME 3.99a is on heavy alpha development and far from any beta release right now. It's untested.
No warning or any message for user? No choice between stable 3.98.4/unstable 3.99?

A huge thanks for the final release.

I need to use LAME v3.99, because that versions handles Unicode file names and Unicode tags on the Windows platform. The older 3.98 version did not...

[olnima]

But - are there any reasons against a manual update to 3.99a13?

Two steps nearer to first beta...

Thanks for LameXP,
Olnima

[LoRd_MuldeR]

But - are there any reasons against a manual update to 3.99a13?

Two steps nearer to first beta...

Thanks for LameXP,
Olnima

The last time I checked (before the LameXP v4.00 release), the latest tag in LAME's CVS repository was "lame3_99alpha11". Consequently that was the version I built. I just checked again and there is a "lame3_99alpha12" tag now (and HEAD is developed as 3.99a13 currently). But since my time machine is currently out of order, I will update to the latest LAME tag in the next LameXP release version.

[IgorC]

about LAME 3.99 alpha
http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=79682&view=findpost&p=744961

since alpha_12 newer --vbr--new is set by default.
Last alpha 13 is here http://www.rarewares.org

btw, Mulder, if you are interested there is a new version of Aotuv Vorbis with a lot of tunings.

[LoRd_MuldeR]

btw, Mulder, if you are interested there is a new version of Aotuv Vorbis with a lot of tunes.

Already included:
http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=commit;h=442ff4095d69340a61b78f85ee3c5d3e5b563617

[IgorC]

Wow, that was fast.

There was important bugfix 6.01.

[LoRd_MuldeR]

New snapshot available:
http://sourceforge.net/projects/lamexp/files/Snapshots (BETA)/2011-02-25/

[IgorC]

Great, thank you for fast updates.

[olnima]

The last time I checked (before the LameXP v4.00 release), the latest tag in LAME's CVS repository was "lame3_99alpha11". Consequently that was the version I built. I just checked again and there is a "lame3_99alpha12" tag now (and HEAD is developed as 3.99a13 currently). But since my time machine is currently out of order, I will update to the latest LAME tag in the next LameXP release version.


I meant, if the updating of lame.exe could be done by the users or if You have any reasons not to recommend this.
You do not need a time machine for that.

[LoRd_MuldeR]

I meant, if the updating of lame.exe could be done by the users or if You have any reasons not to recommend this.
You do not need a time machine for that.

Generally it wouldn't be a very good idea to encourage "Newbie" users to replace the built-in LAME encoder with an arbitrary build that hasn't been tested to cooperate with GUI properly. There are all kinds of problems that might occur. At the same time "Advanced" users who can't wait for the next update and who know what they are doing can make their own builds at any time (the advantage of OSS).

[codres]

Is there a setting in the new version to change the temp folder. Is default in C:\. In the older one i could change it quickly. But in this I must be blind or maybe is not implemented? Thanks for your efforts in the development.

[LoRd_MuldeR]

Is there a setting in the new version to change the temp folder. Is default in C:\. In the older one i could change it quickly. But in this I must be blind or maybe is not implemented? Thanks for your efforts in the development.

There is no such option currently.

[codres]

That's too bad, I must downgrade then. I have under 1GB space on C. Also multithreading could be disabled?

[LoRd_MuldeR]

That's too bad, I must downgrade then. I have under 1GB space on C.

Then it's probably time to clean-up your system drive/partition ;)

You will run into all kinds of problems with low disk space on your system drive/partition (not only with LameXP!), that's for sure.

Anyway, I can add an option to manually choose the directory for TEMP files...


Also multithreading could be disabled?

Not sure what you mean. But I recently added an option to manually overwrite the number of parallel instances (available in the latest snapshot build).

Settings this option to "1" effectively disables multi-threading, at least on the "batch processing" level. Although this usually isn't recommended...

[codres]

Well, usually my comp also encodes x264 most of the times. So I don't want to stress too much with mp3 encodings. So, yes, I want to use only 1 core. Thanks for the tips. Right now I have 1.3 Gb free on C which usually is enough but for a movie of 2h30 min gave me an error.

[codres]

Thanks for the new implementions! They work great mr. mulder :)

[LoRd_MuldeR]

Yet another aoTuV Beta-6 update ;)

aoTuV Beta6.02 [beta6.01 >> beta6.02] (2011/02/27)
# In the specific pattern (different from beta6.01), the bug that caused overflow was fixed.

[John_J]

Hello LoRd_MuldeR!

After a fresh reinstall of Windows XP, I also wanted to use LameXP again for my audio encodings and saw your update to v4.0.
First, I want to say that this new version became excellent...same simple workflow as before, but a brilliant new UI and nice updates.

I've played around in different ways and wondered myself where all extracted tool files have gone, because I couldn't find them in default temporary folder. After a look at Avast (Realtime-Scan is very useful in more than one way ;) ), I found them in "\Documents and Settings\USER\Local Settings\App Data\Temp".
You've stated (http://forum.doom9.org/showthread.php?p=1473735#post1473735) that temporary files go to the %TEMP% folder, but this folder is usually found at "\Documents and Settings\USER\Local Settings\Temp", isn't it? Or is this due to newer OS like Windows 7?

Regards,
JohnJ

EDIT: Forget above...looked at changelog of new beta build 350:

Changes between v4.00 and v4.01:

* Added an option to select a user-defined TEMP directory

Thanks!! :)

EDIT2:

Spoke too soon! It only affects folder of temporary audio files, so please have a look at it.

[Gabrielgoc]

LoRd_MuldeR, I was reading post #100 (http://forum.doom9.org/showthread.php?p=1473735 and I very interested about replaygain.

Replaygain main objective is not to adjust the volume without recompressing, but normalize the loudness based on the response of the human ear, so leave all the tracks on an even level. (http://en.wikipedia.org/wiki/Loudness). While replaygain is the most widely used algorithm, the EBU (European Broadcasting Union) has developed a new algorithm based on ITU-R BS.1770 as a loudness measurement method. This was standardized as EBU R-128. (http://tech.ebu.ch/loudness). If you are interested the following libraries can help you determine how to adjust the volume with SOX: http://www.hydrogenaudio.org/forums/index.php?showtopic=85978 and http://www.hydrogenaudio.org/forums/index.php?showtopic=86116.

I hope this info will be interesting to you. I apologize for my English. Greetings.

Gabriel

[LoRd_MuldeR]

I've played around in different ways and wondered myself where all extracted tool files have gone, because I couldn't find them in default temporary folder. After a look at Avast (Realtime-Scan is very useful in more than one way ;) ), I found them in "\Documents and Settings\USER\Local Settings\App Data\Temp".

You can also use ProcessMonitor (http://technet.microsoft.com/en-us/sysinternals/bb896645). Or look at the source code directly ;)

You've stated (http://forum.doom9.org/showthread.php?p=1473735#post1473735) that temporary files go to the %TEMP% folder, but this folder is usually found at "\Documents and Settings\USER\Local Settings\Temp", isn't it? Or is this due to newer OS like Windows 7?

The Windows operating system doesn't provide any API to detect the system's TEMP folder! Neither SHGetKnownFolderPath() nor SHGetFolderPath() knows about the TEMP folder. There is a function GetTempPath(), however this function does NOT return the path to the system's TEMP folder, but the current value of the %TMP% (or if that one isn't set %TEMP%) environment variable. Now %TMP% and %TEMP% will usually be set and they will usually point to the system's TEMP path, but they also may point to an arbitrary non-writable path or they may even contain complete garbage*! After all the environment variables are user-defined and may be screwed up. So it's something we better do not rely on! Question is: How do we detect the system's TEMP folder, if the Win32 API doesn't reveal it? Solution that works in practice: Obtain the path of the 'LocalAppData' folder (usually located at: "%USERPROFILE%\AppData\Local"), which is known to the Win32 API functions, and then simply append "\Temp" to that path. The result exactly matches the system's standard TEMP folder on Win7 (and probably Vista too), which is "C:\Users\John Doe\AppData\Local\Temp". It slightly differs from WindowsXP's default TEMP folder, but I see no problem there...

*from MSDN documentation: "Note that the function does not verify that the path exists, nor does it test to see if the current process has any kind of access rights to the path."

Spoke too soon! It only affects folder of temporary audio files, so please have a look at it.

That is exactly how it is intended. The "primary" Temp folder needs to be accessed even before user-settings have been loaded, so it cannot be user-controlled. However that shouldn't be an issue at all, as the amount of data extracted to that folder is really small. The user-controlled ("secondary") Temp folder will be used for all intermediate/temporary audio files during the encoding process. So that's the place where the "big" files will go to. Consequently users with a small system partition may want to change the location of the "secondary" Temp folder, while the location of the "primary" one shouldn't matter for anybody.

(If you don't have the ~10 MB of free space, that LameXP will occupy on start-up, available on your system partition, you will run into all kinds of problems with other applications too)

[LoRd_MuldeR]

Replaygain main objective is not to adjust the volume without recompressing, but normalize the loudness based on the response of the human ear, so leave all the tracks on an even level. (http://en.wikipedia.org/wiki/Loudness). While replaygain is the most widely used algorithm, the EBU (European Broadcasting Union) has developed a new algorithm based on ITU-R BS.1770 as a loudness measurement method. This was standardized as EBU R-128. (http://tech.ebu.ch/loudness). If you are interested the following libraries can help you determine how to adjust the volume with SOX: http://www.hydrogenaudio.org/forums/index.php?showtopic=85978 and http://www.hydrogenaudio.org/forums/index.php?showtopic=86116.

The "volume normalization" filter in LameXP already is implemented using the "gain" filter of SoX.

SoX also has a "--replay-gain" parameter, but apparently this can only be used to re-gain files that have already been tagged with ReplayGain information before.

From the SoX manual:
One important use of audio file comments is to convey ‘Replay Gain’ information. SoX supports applying Replay Gain information, but not generating it.

[John_J]

Hello LoRd_MuldeR,

thanks for your fast response!

You can also use ProcessMonitor (http://technet.microsoft.com/en-us/sysinternals/bb896645). Or look at the source code directly ;)

Yes, you're right :) ;) ...but Process Monitor isn't installed, yet (fresh installation).

BTW: Is this the right function which specifies temporary tool path?


Global.cpp

/*
* Get LameXP temp folder
*/
const QString &lamexp_temp_folder(void)
{
static const char *TEMP_STR = "Temp";

if(g_lamexp_temp_folder.isEmpty())
{
...
}
...
}



The Windows operating system doesn't provide any API to detect the system's TEMP folder! Neither SHGetKnownFolderPath() nor SHGetFolderPath() knows about the TEMP folder. There is a function GetTempPath(), however this function does NOT return the path to the system's TEMP folder, but the current value of the %TMP% (or if that one isn't set %TEMP%) environment variable. Now %TMP% and %TEMP% will usually be set and they will usually point to the system's TEMP path, but they also may point to an arbitrary non-writable path or they may even contain complete garbage*!

Yeah, I browsed MSDN too and didn't find any function which returns system's temporary folder. However...maybe you're thinking just a little bit too far ahead. It's the purpose of temporary environment variable to change the according folder in an easy way by the user and provide this information system-wide. I'v never seen any corrupted environment variables. Any software uses the correct path, even LameXP 3.18 ;)

Question is: How do we detect the system's TEMP folder, if the Win32 API doesn't reveal it? Solution that works in practice: Obtain the path of the 'LocalAppData' folder (usually located at: "%USERPROFILE%\AppData\Local"), which is known to the Win32 API functions, and then simply append "\Temp" to that path. The result exactly matches the system's standard TEMP folder on Win7 (and probably Vista too), which is "C:\Users\John Doe\AppData\Local\Temp".

Correct, but...

It slightly differs from WindowsXP's default TEMP folder, but I see no problem there...

That's the reason why I did that post here. Exiting LameXP v4.0 running WinXP leaves behind an empty folder in the wrong path and no other applications are using it. I know, that sounds very pedantic ;)


That is exactly how it is intended. The "primary" Temp folder needs to be accessed even before user-settings have been loaded, so it cannot be user-controlled. However that shouldn't be an issue at all, as the amount of data extracted to that folder is really small.

It's not the required disk space, but the folder left behind :p

Perhaps you could implement a function to delete it in an XP environment or create it in "%USERPROFILE%\Local Settings\Application Data\LoRd_MuldeR", if you really need this folder at this location and don't want to trust temporary variable.

--JohnJ

[LoRd_MuldeR]

BTW: Is this the right function which specifies temporary tool path?

Yup.

Yeah, I browsed MSDN too and didn't find any function which returns system's temporary folder.

Indeed.

However...maybe you're thinking just a little bit too far ahead. It's the purpose of temporary environment variable to change the according folder in an easy way by the user and provide this information system-wide. I'v never seen any corrupted environment variables. Any software uses the correct path, even LameXP 3.18 ;)

Well, users do kind of all strange things, such as messing with environment variables, and then forget about it. Of course when something goes wrong they'll complain to the software author.

Moreover it can even happen that other programs/installers modify environment variables. Consequently we should avoid 'uncertainties' (like depending on environment variables) as much as possible.

BTW: LameXP v3.18 used GetTempPath(), because back at that time I hadn't realized that this function is just a wrapper for getenv("TMP") :p

That's the reason why I did that post here. Exiting LameXP v4.0 running WinXP leaves behind an empty folder in the wrong path and no other applications are using it. I know, that sounds very pedantic ;)

Yes, I think this is more a pedantry than a real problem.

After all, given that all applications clean up properly, you should always find the TEMP folder empty, after exiting all running applications ;)

Perhaps you could implement a function to delete it in an XP environment or create it in "%USERPROFILE%\Local Settings\Application Data\LoRd_MuldeR", if you really need this folder at this location and don't want to trust temporary variable.

Yes, of course I could do that. But I want to avoid OS-specific code paths as much as possible. This easily creates bugs, which are hard to identify/reproduce...

[mariush]

In Windows, the correct way to do it is to actually use GetTempPath() ... It's designed to return the go through these one after another:

1. TMP
2. TEMP
3. User profile env. variable
4. The Windows folder

You're right, though, they're not guaranteed to be valid, even the example for this API function mentions it: http://msdn.microsoft.com/en-us/library/aa363875%28v=vs.85%29.aspx
However, it's your job to test if the folder actually exists and you can write in it, and only then if it fails, go on and use your own location.

The reason is because there are quite a few particularities and reasons why the TMP and TEMP variables are used - one I can mention from the top of my head is for example this one, where depending on how someone configures Remote Desktop, you get a different temporary folder *on purpose* : http://blogs.msdn.com/b/oldnewthing/archive/2011/01/25/10119675.aspx

If everything fails, I guess you can always fall back to Application Data and you to be careful which one to pick, because there's two of them: http://blogs.msdn.com/b/oldnewthing/archive/2005/07/01/434647.aspx . You can use SHGetFolderLocation with the right CLSID to determine the paths: http://msdn.microsoft.com/en-us/library/bb762180%28v=vs.85%29.aspx


and btw, the correct wording is actually directory, because "folders" are a virtual thing (but encapsulate regular directories): http://blogs.msdn.com/b/oldnewthing/archive/2011/02/16/10129908.aspx

[LoRd_MuldeR]

However, it's your job to test if the folder actually exists and you can write in it, and only then if it fails, go on and use your own location.

That sounds like feasible solution, although it adds some more complexity.

The reason is because there are quite a few particularities and reasons why the TMP and TEMP variables are used - one I can mention from the top of my head is for example this one, where depending on how someone configures Remote Desktop, you get a different temporary folder *on purpose* : http://blogs.msdn.com/b/oldnewthing/archive/2011/01/25/10119675.aspx

Well, writing my stuff to a sub-directory inside the 'application data' directory should always be admissible.

(Google's installers even install the complete application there :p)

If everything fails, I guess you can always fall back to Application Data and you to be careful which one to pick, because there's two of them: http://blogs.msdn.com/b/oldnewthing/archive/2005/07/01/434647.aspx . You can use SHGetFolderLocation with the right CLSID to determine the paths: http://msdn.microsoft.com/en-us/library/bb762180%28v=vs.85%29.aspx

Actually I use SHGetKnownFolderPath(), if available, as SHGetFolderPath() and SHGetFolderLocation() have been deprecated since Vista.

and btw, the correct wording is actually directory, because "folders" are a virtual thing (but encapsulate regular directories): http://blogs.msdn.com/b/oldnewthing/archive/2011/02/16/10129908.aspx

:eek:

[John_J]

and btw, the correct wording is actually directory, because "folders" are a virtual thing (but encapsulate regular directories): http://blogs.msdn.com/b/oldnewthing/archive/2011/02/16/10129908.aspx

:D Now, it goes really the pedantic way... ;)

I'll write a VB script for my personal use to start LameXP and clean up directories afterwards.

Anyways, keep on the excellent work and I hope to see your website back online, soon!

Regards,
JohnJ

[LoRd_MuldeR]

:D Now, it goes really the pedantic way... ;)

I'll write a VB script for my personal use to start LameXP and clean up directories afterwards.

Anyways, keep on the excellent work and I hope to see your website back online, soon!

Regards,
JohnJ

I just changed the function like mariush suggested:
LameXP will now try the directory pointed to by %TMP% first and it will only fall back to "%LOCALAPPDATA%\Temp" if the former doesn't exist or isn't writable.

See for details:
http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=commit;h=f2ab4c046777839d910505d2cae6330adf4b4600

Hopefully this will make everybody happy, finally :p

[John_J]

LameXP will now try the directory pointed to by %TMP% first and it will only fall back to "%LOCALAPPDATA%\Temp" if the former doesn't exist or isn't writable
...
Hopefully this will make everybody happy, finally :p

Yes, indeed it does! Thank you very much! :)

[Romario]

Thank you for newest snapshot,but, where is changelog ???

[LoRd_MuldeR]

New snapshot here:
http://sourceforge.net/projects/lamexp/files/Snapshots%20(BETA)/2011-03-09/

Thank you for newest snapshot,but, where is changelog ???

Changelog.html (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/Changelog.html;hb=078dc62c79f4edd1e3ba23c5deed65b5ac8fcf70) :confused:

And if you need even more details, you may look at the GIT repository's commit log:
http://gitorious.org/lamexp/lamexp/commits/master