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

devarni

6th March 2012, 00:47

LameXP does support volume normalization, but it's completely optional.

Also normalization does not happen by writing any kind of "normalizing data" (whatever that is supposed to be) to the file.

Instead, if (and only if) normalization is enabled, the source is decompressed first and then the audio is normalized via SoX before it is sent to the encoder.

Again, this is optional and it is disabled by default (see the "Advanced Options" tab). Also I have no idea what kind of info "MediaMonkey" displays.

But something has changed with the latest versions. I tried a different frontend "Lame Front-End 1.7" and this works perfectly.
Is there eventually some kind of meta-data field where applications can store the computed normalization level in Decibel?

LoRd_MuldeR

6th March 2012, 00:51

But something has changed with the latest versions. I tried a different frontend "Lame Front-End 1.7" and this works perfectly.

Between which two builds exactly you think there is a difference?

Is there eventually some kind of meta-data field where applications can store the computed normalization level in Decibel?

If such thing exists, LameXP doesn't use it. AFAIK the LAME encoder will add "replay gain" tags by default though. LameXP does not induce this ;)

Also note that "replay gain" is just a hint, which can be used by the player to attenuate or amplify the signal, but it does not modify the audio stream at all.

If you are using a player with "replay gain" support and don't want the loudness to be equalized, you have to disable this "feature" in the individual player!

devarni

6th March 2012, 01:07

Between which two builds exactly you think there is a difference?
If such thing exists, LameXP doesn't use it.

I don't update all versions... the latest version must be early in 2011 where it works. If have some time I will install and test some older versions.

LoRd_MuldeR

6th March 2012, 01:23

I don't update all versions... the latest version must be early in 2011 where it works. If have some time I will install and test some older versions.

Well, there have been about ~600 revisions since then! However I am pretty sure that what you call "leveling data" is simply the "replay gain" tag that LAME will add automatically ;)

As explained before, ReplayGain-based loudness equalization is a "feature" of your individual player and thus has to be turned off in the player, if you don't like it.

See also:
http://en.wikipedia.org/wiki/Replay_Gain

devarni

6th March 2012, 09:42

Well, there have been about ~600 revisions since then! However I am pretty sure that what you call "leveling data" is simply the "replay gain" tag that LAME will add automatically ;)

As explained before, ReplayGain-based loudness equalization is a "feature" of your individual player and thus has to be turned off in the player, if you don't like it.

See also:
http://en.wikipedia.org/wiki/Replay_Gain

I think we get a bit closer... Lame seems to store replay gain informations per default (since newer version I guess).

"--noreplaygain
Disable ReplayGain analysis.
By default ReplayGain analysis is enabled. This switch disables it."

Is LameXP using "--noreplaygain" per default if the option is disabled in the LameXP settings?

[Edit]
I added the custom option --noreplaygain and now it's working... Eventually you should hardcode this switch so all is working as expected?

LoRd_MuldeR

6th March 2012, 13:56

LAME creates the "replay gain" tag automatically. LameXP does not tell LAME to create such tag, nor does it tell LAME to not create the tag.

I can't hardcode the "--noreplaygain" switch, because the users who want to use ReplayGain in their players rely on that tag. These users would not be able to use ReplayGain anymore!

At the same time, the presence of a "replay gain" tag does no harm for users who don't use ReplayGain. It's just a hint and it can safely be ignored...

(Again: If you don't like ReplayGain, simply disable that "feature" in your player. By not creating a ReplayGain tag, you intentionally "break" that feature rather than disabling it)

devarni

6th March 2012, 14:05

LAME creates the "replay gain" tag automatically. LameXP does not tell LAME to create such tag, nor does it tell LAME to not create the tag.

I can't hardcode the "--noreplaygain" switch, because the users who want to use ReplayGain in their players rely on that tag. These users would not be able to use ReplayGain anymore!

At the same time, the presence of a "replay gain" tag does no harm for users who don't use ReplayGain. It's just a hint and it can safely be ignored...

Hardcode means, you should add the option "--noreplaygain" in the "background" if the user has the option disabled (default setting) in the LameXP options. If the option is enabled than of course not.

Some applications using the "replaygain" tag and if set playing with a modified volume and this is not the wished behavior.

LoRd_MuldeR

6th March 2012, 14:18

Hardcode means, you should add the option "--noreplaygain" in the "background" if the user has the option disabled (default setting) in the LameXP options. If the option is enabled than of course not.

I won't add a GUI option to disable the generation of "replay gain" tags, because I don't want to encourage people to use such "exotic" (and potentially problematic) settings.

While having a "replay gain" tag certainly does no harm (it's just a hint, it does NOT effect the audio data at all), not having the tag breaks some functionality - functionality that is desired by many users!

Consequently the great majority of all users is better off with a "replay gain" tag. Actually I can't think of a reason to not store these tags, if LAME can add them "for free".

The few "power users" who really understand how ReplayGain works and who have a good reason to disable the generation of ReplayGain tags, can still add "--noreplaygain" to the custom LAME parameters.

The custom parameters box is intended exactly for this kind of exotic (rarely used) parameters.

Some applications using the "replaygain" tag and if set playing with a modified volume and this is not the wished behavior.

If the ReplayGain feature of the individual playback software is enabled, then equalizing the volume (or more precisely: the loudness) of different tracks is exactly the "wished" behavior.

If your "wished" behavior is to not apply ReplayGain (which is perfectly comprehensible), then don't use it. Disable that "feature" of your player. It's as simple as that :)

(Note: ReplayGain is a feature of your player. It's NOT a feature of the encoder. The encoder can only add the required tags, which enable the player to apply ReplayGain - optionally!)

LoRd_MuldeR

6th March 2012, 21:27

LameXP v4.04 Beta-5:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.5 Final (2012-02-28), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.139))
* Updated MediaInfo to v0.7.53 (2012-01-24), compiled with ICL 12.1.6 and MSVC 10.0
* Updated SoX to to v14.4.0 RC-3 (2012-02-20), compiled with ICL 12.1.7 and MSVC 10.0
* Updated Monkey's Audio binary to v4.11 (2011-04-20)
* Updated Musepack decoder to revision 475 (2011-08-10), compiled with ICL 12.1.6 and MSVC 10.0
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art
* Fixed a very rare "live-lock" situation in early initialization code

The QAAC Encoder Add-in for LameXP has been updated as well:
http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0

Taurus

9th March 2012, 17:03

LoRd_MuldeR

9th March 2012, 17:18

Just discovered the yellow message in the console output:
"Potential deadlock in initalization thread!"
This is on an old AMD Athlon XP mainly used for audio encoding.
Antivirus guard disabled.
Everything is working as expected, just a little curious.
And yes, I searched the thread and your FAQs (a little):p

This warning message was added recently, when I fixed a possible deadlock situation that could occur during the initialization of LameXP and probably existed since v4.00 ;)

Because the "main" thread is waiting for the "init" thread to finish its work, it is very important that the "init" thread eventually sends its finished message.

In very rare cases, however, it could happen that this finished message got lost, even before the "main" thread started waiting. It then would have waited for the message indefinitely!

As I have implemented a workaround now, this can not happen anymore. Additionally there will be a warning message now, if the "init" thread does not finish in due time.

Of course on a "slow" computer it can take "longer than usual" to finish and thus you may see the warning. You can safely ignore that, as long as LameXP does start up eventually...

Taurus

9th March 2012, 17:44

Thank you for your support.:thanks:

LoRd_MuldeR

10th March 2012, 15:55

LameXP v4.04 Beta-6:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.5 Final (2012-02-28), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.139))
* Updated MediaInfo to v0.7.53 (2012-01-24), compiled with ICL 12.1.6 and MSVC 10.0
* Updated SoX to to v14.4.0 RC-3 (2012-02-20), compiled with ICL 12.1.7 and MSVC 10.0
* Updated mpg123 decoder to v1.13.5 (2011-03-07), compiled with GCC 4.6.1
* Updated Monkey's Audio binary to v4.11 (2011-04-20)
* Updated Musepack decoder to revision 475 (2011-08-10), compiled with ICL 12.1.6 and MSVC 10.0
* Updated GnuPG to v1.4.12, compiled with GCC 4.6.1
* Updated language files (big thank-you to all contributors !!!)
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art
* Fixed a very rare "live-lock" situation in early initialization code

manolito

11th March 2012, 03:59

More work for you: sox-14.4.0 has gone final

Cheers
manolito

LoRd_MuldeR

11th March 2012, 15:00

More work for you: sox-14.4.0 has gone final

Cheers
manolito

Doesn't look like there was any change since RC-3 that would effect us. But I will make a new build anyway...

KamikazeCJ

19th March 2012, 01:25

mariush

19th March 2012, 01:36

Don't do that.

Your CBR 320 audio file already went through a process where some details the encoder thinks you won't notice were cut out to get the bitrate to 320kbps.
When you compress it again to VBR, the encoder will use a different set of rules to determine what could be cut out without you noticing much, so you're always going to get a worse result.

It's like taking a picture, saving it to JPG at 90% quality, then saving it again at 75% quality - the result will look worse than taking the original and saving it directly to 75% quality.

Is it really worth losing quality, just to save about 300-500 KB out of 3-4 MB?

LoRd_MuldeR

19th March 2012, 01:40

Can someone please clear something up for me? I just started using this LAMEXP latest version. I have mp3 music files encoded @320CBR. I decided to re-encode the CBR to VBR in the interest of maintaining quality and shrinking file size. I'm using Highest quality bitrate settings (0) and the lame settings are the best quality. Everything else in advanced I'm leaving default (no bitrate management). Now I know a Lossy format to a Lossy format isn't the best encode but...
No matter if I go 320CBR to 320CBR or 320CBR to Highest quality VBR, my original file sounds louder than my ouput. Even clearer (and I don't think it's just because its louder). The volume norm. or tone adj. is not used in the encode.
Why this kinda dramatic change in sound? Don't get it.

First of all you should be aware that re-encoding from a lossy format to a lossy format, such as re-encoding from MP3 to MP3, will cause some "generation loss" for sure!

Secondly, with VBR mode "0" you will probably get a file that uses 320 kbps most of the time. So in order to get a "reasonable" file size reduction that justifies the re-encoding and still retain acceptable quality, I would try mode "2".

Last but not least: Something that has been discussed recently in this thread is that up-to-date LAME will automatically add "ReplayGain" tags to the encoded file (and some older version apparently did not).

So if your playback software supports ReplayGain and you have that feature enabled and to original 320 kbps CBR file happens to not have a "ReplayGain" tag, only the re-encoded file will be subject to ReplayGain at playback-time!

ReplayGain adjusts the volume (or more precisely the "loudness") of the file, in order to keep the same loudness across different files. This can be the reason that the new file is played back at a "lower volume" than the old one ;)

(And, as a well known fact, the human ear has a tendency to prefer the "louder" file in a quality comparison)

KamikazeCJ

19th March 2012, 04:50

Thanks for your responses. I get the generation loss thing.

Mariush, my thinking is this: The source files are recorded at 320CBR and when I went to VBR with 126 (roughly) music files, it took nearly 200mb (roughly) off the files. That's an extra 30-35 music files' worth of space. I was thinking there's a lot of "dead" space in 320cbr which would give me a little bit of allowance for the lossy to lossy encode. Just my thinking...

The replay gain tag, mulder, would seem like a culprit, I didn't know of it. Essentially, what your saying is that the source files may not of had that tag on them (cuz they were louder), and the re encode now has them and needs them to be read to make the file sound equivallent to the original. And they sound low because my player (media monkey) doesn't have replay gain enabled. Or am I still confused?
Original files were encoded with LAME3.98r and others were 3.98.4. How do I know if they were recorded with replay gain, Medainfo app doesn't seem to say. In addition is there a way to turn it offduring encode or is it better? I'll try to find more info about it.

KamikazeCJ

19th March 2012, 05:08

So, thinking about this and looking up replay gain, this tag justs helps "normalize" the volume of the tracks in relation to each other and lameencoder does that for you and passes the info on in the tag??? (assuming) More importantly just because the volume is different doesn't mean the quality of the file is worse than the original, just a lower volume. Right? (Of course other than the CBR to VBR re encode).
However I don't have volume normalization checked in LAME. Or did the original file have the tag on it with a loud bias and the re encode reverted it back to the original volume?

mariush

19th March 2012, 12:34

You can disable it if you use the command line encoder or if you encode the files to mp3 from a software that allows you to edit the parameters.

examples...

lame.exe -noreplaygain --preset insane file.wav file.mp3

will create file.mp3 out of file.wav , a 320kbps cbr file with minimal loss and no replay gain

lame.exe -noreplaygain --preset standard file.wav file.mp3

will create file.mp3 out of file.wav, a vbr file that will hover around 192kbps

If you want I can create a small script for you to batch convert the files, if you can't add the -noreplaygain parameter in lamexp

-

about the generation loss ... i guess it depends on the source of the files. If the files were generated straight from CD or from flac files... those 320kbps could very well be actual content, which your ears would notice if you have quality speakers. FLAC files (lossless audio are in general about 550-800 kbps, so there is information in audio files that gets cut down even at 320kbps - there's no reason an encoder would just fill up those 320kbps with junk.
When you get it down to 192kbps, something will be lost. If you can live with it, that's fine.

LoRd_MuldeR

19th March 2012, 12:55

So, thinking about this and looking up replay gain, this tag justs helps "normalize" the volume of the tracks in relation to each other and lameencoder does that for you and passes the info on in the tag??? (assuming)

The ReplayGain tag is just some "extra info" that is added to the MP3 file. It does not alter the audio data at all.

More importantly just because the volume is different doesn't mean the quality of the file is worse than the original, just a lower volume. Right? (Of course other than the CBR to VBR re encode).

As said before, the human ear has a tendency the rate a "louder" file with better quality, even when the files would sound identical at the same volume.

Thus a quality comparison needs to be done at the same "loudness" for all files. Otherwise the results are pretty much meaningless...

However I don't have volume normalization checked in LAME. Or did the original file have the tag on it with a loud bias and the re encode reverted it back to the original volume?

Adding the ReplayGain tag to the MP3 files does not apply any kind of volume normalization.

It just adds an additional info, which later can be used to apply "loudness adjustment" via ReplainGain. Though applying ReplainGain still is 100% optional!

Moreover, ReplainGain is a function of your playback software and you can disable it there, if you don't like it.

The ReplayGain tag is just a prerequisite for using ReplayGain at playback-time. It does not imply that ReplayGain will actually be used ;)

Or in other words: Don't have a ReplayGain tag -> can't use ReplayGain. Have a ReplayGain tag -> may use ReplayGain (if desired) or may ignore the tag.

Now if you have ReplayGain enabled in your playback software and one file has the required tag while the other files does not, then only the first one file will be "adjusted".

Of course, as soon as you disable the ReplayGain function of your playback software, no file will ever get "adjusted" by ReplayGain...

manolito

19th March 2012, 12:57

If you want I can create a small script for you to batch convert the files, if you can't add the -noreplaygain parameter in lamexp

Yes you can add the -noreplaygain in LameXP.

The few "power users" who really understand how ReplayGain works and who have a good reason to disable the generation of ReplayGain tags, can still add "--noreplaygain" to the custom LAME parameters.

The custom parameters box is intended exactly for this kind of exotic (rarely used) parameters.

Cheers
manolito

LoRd_MuldeR

19th March 2012, 13:06

Yes you can add the -noreplaygain in LameXP.

You can do that. But that's just a workaround to intentionally "break" the ReplayGain function of your playback software.

Instead, simply disable ReplayGain in your playback software, if you don't like it...

KamikazeCJ

19th March 2012, 19:53

Thanks for clearing all that up Mulder and Mariush.
Does this Replay tag try to "preserve" the original sound by adding voulme and EQ info to playback because the encode has some loss or is it essentially a "loudness" button which I would presume the playback software would only need?

BTW my original loudness difference in pre encode and encoded songs was because "level playback volume" was checked in media monkey's settings. Oherwise files sound same from 320CBR to 265 VBR (plus the generation loss). That filesize went from 9.5m to 7.88 (about 1/5th). I think that's a good compromise for me.
Now I hope my car's music box accepts VBR files!....

oh one more thing... any thoughts when Lamexp will import cds. Blink 182 cd just had data files, etc. on it. And I just noticed cda doesn't work and you recommend exact audio copy. Is Itunes inferior at this. It seems so because if I remember, I couldn't get the proper import setting I wanted last try.

LoRd_MuldeR

19th March 2012, 19:57

Thanks for clearing all that up Mulder and Mariush.
Does this Replay tag try to "preserve" the original sound by adding voulme and EQ info to playback because the encode has some loss or is it essentially a "loudness" button which I would presume the playback software would only need?

The ReplayGain tag does not "do" anything. It's just an additional meta info ("Peak signal amplitude") that may be used for future processing. It's no different from an "id3" tag. The audio data itself is not altered at all.

If ReplayGain processing is enabled in your playback software and if the required ReplayGain tag is present in the audio file, then the loudness will be "adjusted" to 89 dB SPL (Sound Pressure Level).

LoRd_MuldeR

19th March 2012, 20:13

oh one more thing... any thoughts when Lamexp will import cds. Blink 182 cd just had data files, etc. on it. And I just noticed cda doesn't work and you recommend exact audio copy. Is Itunes inferior at this. It seems so because if I remember, I couldn't get the proper import setting I wanted last try.

Audio CD's do not contain any files at all. They contain audio tracks, but no data track. So there is no file system and thus no files.

The ".cda" files you may find on an Audio CD in Windows Explorer are "dummy" files generated/emulated by Windows.

In order to "extract" the audio tracks from an Audio CD to Wave files, you will need to use some Ripping software. LameXP can' do that!

Accurately ripping Audio Tracks is not trivial to do and I don't want to re-invent the wheel. With EAC we have a very good and free solution.

If EAC could be controlled from the command-line, I could integrate it into LameXP. But, as far as I know, that's not supported by EAC :o

About iTunes: The only thing I can say is that personally I wouldn't infect my computer with a mess like iTunes or QuickTime...

KamikazeCJ

19th March 2012, 20:26

I wasn't implying that replay was doing anything other than adding an info tag. Just wanted to know what it added for the playback to read. Apologies for not being clear. Either way your answer on loudness adjustment cleared it up.
Oh and I agree wholeheartedly with your itunes statement. Unfortunately, its all some people know (or have been brainwashed to know (i.e. wife, kids). I would like to get that "controlling" software off my computer but then they would be lost without the Ipad/Ipod syncing thing.

LoRd_MuldeR

19th March 2012, 21:31

I wasn't implying that replay was doing anything other than adding an info tag. Just wanted to know what it added for the playback to read.

The "ReplainGain tag" actually is one field of the LAME header. You can find the exact specification here:
http://gabriel.mp3-tech.org/mp3infotag.html#replaygain

KamikazeCJ

21st March 2012, 17:47

LoRd_MuldeR

21st March 2012, 18:59

Now that I've tried EAC (Looks like a really good app), I have I would think would be a simple question but my searches are coming up with nothing. When I use the freedb to get the file properties, I can't figure out how to transfer it to my files (album, year, etc). Only the track name and artist are written. EAC's forum is a bit slow to respond so I was hoping one of you could give me an easy answer hear. Sorry if this post is off thread.

If you let EAC rip the Audio CD as a Cue Sheet (see also second part of my post), then all meta info will be included in the Cue Sheet file.

And LameXP can import that info from the Cue Sheet later...

Oh And can EAC use your front end to the LAME encoder, Mulder? I used a wildcard (*) to get it to read LAMEXP.exe ove LAME.EXE. But it doesn't seen to work. Do I need to separately install LAME by itself?

EAC cannot use LameXP.

You can extract the audio to individual Wave files with EAC and then convert these files with LameXP later.

Or you can extract the audio tracks as a single "big" Wave file + Cue Sheet and then import that Cue Sheet in LameXP - that's the preferred solution.

And of course you can make EAC use the LAME encoder to output MP3's directly. Then LameXP is not used/needed at all.

KamikazeCJ

21st March 2012, 19:30

I just worked it all out then I read your message. But you confirmed things and cleared up the cue sheet. When I synced Lame.exe up to EAC there were more options regarding compression, etc and it transfered the info to the mp3s.
It shows integrity to hear the developer say LAMEXP may not be needed in this case.:) Its all working for me now thanks to your help. Of course I love your app and will be using it for all existing ripped files that need converting.:thanks::thanks:

LoRd_MuldeR

22nd March 2012, 00:20

LameXP v4.04 Beta-7:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.5 Final (2012-02-28), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.139))
* Updated MediaInfo to v0.7.54 (2012-03-13), compiled with ICL 12.1.7 and MSVC 10.0
* Updated SoX to to v14.4.0 (2012-03-04), compiled with ICL 12.1.7 and MSVC 10.0
* Updated mpg123 decoder to v1.13.6 (2011-03-11), compiled with GCC 4.6.1
* Updated Monkey's Audio binary to v4.11 (2011-04-20)
* Updated Musepack decoder to revision 475 (2011-08-10), compiled with ICL 12.1.6 and MSVC 10.0
* Updated GnuPG to v1.4.12, compiled with GCC 4.6.1
* Updated language files (big thank-you to all contributors !!!)
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art
* Fixed a very rare "live-lock" situation in early initialization code

LoRd_MuldeR

24th March 2012, 22:39

LameXP v4.04 Beta-8:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.5 Final (2012-02-28), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.139))
* Updated MediaInfo to v0.7.54 (2012-03-13), compiled with ICL 12.1.7 and MSVC 10.0
* Updated SoX to to v14.4.0 (2012-03-04), compiled with ICL 12.1.7 and MSVC 10.0
* Updated mpg123 decoder to v1.13.6 (2011-03-11), compiled with GCC 4.6.1
* Updated Monkey's Audio binary to v4.11 (2011-04-20)
* Updated Musepack decoder to revision 475 (2011-08-10), compiled with ICL 12.1.6 and MSVC 10.0
* Updated GnuPG to v1.4.12, compiled with GCC 4.6.1
* Updated language files (big thank-you to all contributors !!!)
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art
* Fixed a very rare "live-lock" situation in early initialization code

LoRd_MuldeR

24th March 2012, 23:06

Just discovered the yellow message in the console output:
"Potential deadlock in initalization thread!"
This is on an old AMD Athlon XP mainly used for audio encoding.
Antivirus guard disabled.
Everything is working as expected, just a little curious.
And yes, I searched the thread and your FAQs (a little):p

Okay, today I found another issue that may mistakenly trigger this warning (plus an additional waiting period!) under certain rare(?) circumstances.

Strangely enough, this never occurred on my native machine or in any of my VMware-based VM's. I noticed it in my VirtualPC-based VM ("Windows XP mode") though ;)

Beta-8 contains a workaround for this specific problem. So in case this happened on your system, the warning should be gone and startup should be faster now.

(There still is a chance that the warning occurred legitimately on your system, in which case you will see no difference ^^)

Taurus

25th March 2012, 09:25

Thank you, My Lord :p:D !
This does it.
No more yellow marks and LameXP is starting much faster.
Really appreciated :thanks:

LoRd_MuldeR

25th March 2012, 13:31

Good to know :)

Actually this is a nice example of race conditions:

:: Main thread ::

M01 connect(thread, SIGNAL(finished()), loop, SLOT(quit()), Qt::QueuedConnection);
M02 connect(timer, SIGNAL(timeout()), loop, SLOT(quit()));
M03
M04 while(thread->isRunning())
M05 {
M06 loop->exec();
M07 if(thread->isRunning())
M08 {
M09 qWarning("Potential deadlock in initialization thread!");
M10 }
M11 }

:: Worker thread ::

T01 DoActualWork();
T02
T03 [...]
T04
T05 emit thr->finished();
T06
T07 [...]
T08
T09 d->running = false;
T10 d->finished = true;

While the 'main' thread is waiting for the 'worker' thread to finish its job, it will be hanging in the Event Loop at M06.
Now it can happen that T05 gets executed in the 'worker' thread and then control switches to the 'main' thread immediately, i.e. T09 and T10 have not executed yet!
Consequently we will exit from M06, as the 'finished' signal just has been emitted - and that signal is connected to the 'quit' slot of the event loop.
However in M07 and M04 the "thread->isRunning()" expression will still evaluate to TRUE. That is because T09 and T10 have not "updated" the corresponding status flags yet :rolleyes:
As the result, we will enter the wait loop once more! And, as the thread is not running anymore, only the "timeout" will eventually help us the exit from the event loop...

(Note that the "Worker thread" code listed above is from the Qt Framework, so I cannot change that portion!)

SirKiwi

26th March 2012, 01:33

I know it's been mentioned a few times in this thread, but I would love to see an "overwrite original file" option.

Also, I would love to see a way to input an output directory in plain text (i.e. typing out the directory or copy/pasting a directory path) instead of using the tree pane with the mouse.

Other than that, I love how the software runs instances in parallel for multiples encodes. Great job!

LoRd_MuldeR

26th March 2012, 15:07

I know it's been mentioned a few times in this thread, but I would love to see an "overwrite original file" option.

I still don't like the idea :scared:

Also, I would love to see a way to input an output directory in plain text (i.e. typing out the directory or copy/pasting a directory path) instead of using the tree pane with the mouse.

There is no "input" directory, as the input/source files may be located in various directories. Also I cannot change the "File Open" dialog, as it's a system dialog.

It may be possible to add an editbox for the "output" directory though. Will have to figure out a way to integrate this into the GUI...

LoRd_MuldeR

27th March 2012, 23:09

LameXP v4.04 Beta-10:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Added a button to modify the current output folder path in an edit box
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.5 Final (2012-02-28), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.139))
* Updated MediaInfo to v0.7.54 (2012-03-13), compiled with ICL 12.1.7 and MSVC 10.0
* Updated SoX to to v14.4.0 (2012-03-04), compiled with ICL 12.1.7 and MSVC 10.0
* Updated mpg123 decoder to v1.13.6 (2011-03-11), compiled with GCC 4.6.1
* Updated Monkey's Audio binary to v4.11 (2011-04-20)
* Updated Musepack decoder to revision 475 (2011-08-10), compiled with ICL 12.1.6 and MSVC 10.0
* Updated GnuPG to v1.4.12, compiled with GCC 4.6.1
* Updated language files (big thank-you to all contributors !!!)
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art
* Fixed a very rare "live-lock" situation in early initialization code

mike20021969

28th March 2012, 10:15

Are we getting close to the next stable?
Thanks.

LoRd_MuldeR

29th March 2012, 00:10

Are we getting close to the next stable?
Thanks.

It's done when it's done :devil:

LoRd_MuldeR

30th March 2012, 23:26

LameXP v4.04 Beta-11:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Added a button to modify the current output folder path in an edit box
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.5 Final (2012-02-28), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.139))
* Updated MediaInfo to v0.7.54 (2012-03-13), compiled with ICL 12.1.7 and MSVC 10.0
* Updated SoX to to v14.4.0 (2012-03-04), compiled with ICL 12.1.7 and MSVC 10.0
* Updated mpg123 decoder to v1.13.6 (2011-03-11), compiled with GCC 4.6.1
* Updated Monkey's Audio binary to v4.11 (2011-04-20)
* Updated Musepack decoder to revision 475 (2011-08-10), compiled with ICL 12.1.6 and MSVC 10.0
* Updated GnuPG to v1.4.12, compiled with GCC 4.6.1
* Updated language files (big thank-you to all contributors !!!)
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Tweaked directory outline on "output folder" tab for improved performance (hopefully)
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art
* Fixed a very rare "live-lock" situation in early initialization code

In one of my tests, the latest tweaks could reduce the number of file system operations that were needed to initialize the directory outline from more than 20,000 to about 3,500 (as measured by ProcessMonitor). The actual speed-up may not be as high as these numbers may indicate, because Windows itself seems to do some caching to speed-up these file system operations. Still there should be a decent speed-up. Feedback is welcome...

mike20021969

31st March 2012, 23:49

LameXP v4.05 has been released :)
The installer has certainly shrunk - 1.5MB compared with 15.8MB.
And the program launches ultra quick.

Didn't we used to be able to encode to mp4 using AAC?
I can only seem to do mp3 for some reason.

EDIT - I just noticed the changes. Oh well, back to the previous version for me.

Sorry, but 4.05 is a gigantic step backwards if ever there was.

Taurus

1st April 2012, 04:09

LameXP v4.05 has been released :)
Har,har,har, :goodpost::p;):D

lethedoom

1st April 2012, 04:32

LameXP v4.05 has been released :)
I nearly always need to encode flac files to mp3 and I value the import metadata feature added during 4,04 beta development. Since 4.04 beta license is time limited and no 4.04 final seems to have been offered ( 4.03 final-->4.04 betas -->4.05 final ) is my only option to revert to 4,03 final and use other applications to amend tags ?

Again, thank you for your generosity in providing this very useful free application for many years and valued tutelage.

best wishes for your efforts.

lethedoom

I just remembered today is already April 1 in your time zone--Is the de facto termination of the v 4.04 development process a joke ?