Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Programming and Hacking > Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 6th March 2012, 00:47   #601  |  Link
devarni
Registered User
 
Join Date: Feb 2012
Posts: 6
Quote:
Originally Posted by LoRd_MuldeR View Post
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?
devarni is offline   Reply With Quote
Old 6th March 2012, 00:51   #602  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,048
Quote:
Originally Posted by devarni View Post
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?

Quote:
Originally Posted by devarni View Post
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!
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 6th March 2012 at 01:13.
LoRd_MuldeR is offline   Reply With Quote
Old 6th March 2012, 01:07   #603  |  Link
devarni
Registered User
 
Join Date: Feb 2012
Posts: 6
Quote:
Originally Posted by LoRd_MuldeR View Post
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.
devarni is offline   Reply With Quote
Old 6th March 2012, 01:23   #604  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,048
Quote:
Originally Posted by devarni View Post
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
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 6th March 2012 at 02:00.
LoRd_MuldeR is offline   Reply With Quote
Old 6th March 2012, 09:42   #605  |  Link
devarni
Registered User
 
Join Date: Feb 2012
Posts: 6
Quote:
Originally Posted by LoRd_MuldeR View Post
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?

Last edited by devarni; 6th March 2012 at 09:51.
devarni is offline   Reply With Quote
Old 6th March 2012, 13:56   #606  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,048
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)
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 6th March 2012 at 13:59.
LoRd_MuldeR is offline   Reply With Quote
Old 6th March 2012, 14:05   #607  |  Link
devarni
Registered User
 
Join Date: Feb 2012
Posts: 6
Quote:
Originally Posted by LoRd_MuldeR View Post
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.
devarni is offline   Reply With Quote
Old 6th March 2012, 14:18   #608  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,048
Quote:
Originally Posted by devarni View Post
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.

Quote:
Originally Posted by devarni View Post
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!)
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 6th March 2012 at 17:56.
LoRd_MuldeR is offline   Reply With Quote
Old 6th March 2012, 21:27   #609  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,048
LameXP v4.04 Beta-5:

Quote:
Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc 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)
* 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)
* Run more than four instances in parallel on systems with more than four CPU cores (details)
* 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/gi...=HEAD#71a113b0
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 10th March 2012 at 15:51.
LoRd_MuldeR is offline   Reply With Quote
Old 9th March 2012, 17:03   #610  |  Link
Taurus
Registered User
 
Taurus's Avatar
 
Join Date: Mar 2002
Location: Krautland
Posts: 865
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)
Taurus is offline   Reply With Quote
Old 9th March 2012, 17:18   #611  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,048
Quote:
Originally Posted by Taurus View Post
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)
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...
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 9th March 2012 at 17:40.
LoRd_MuldeR is offline   Reply With Quote
Old 9th March 2012, 17:44   #612  |  Link
Taurus
Registered User
 
Taurus's Avatar
 
Join Date: Mar 2002
Location: Krautland
Posts: 865
Thank you for your support.
Taurus is offline   Reply With Quote
Old 10th March 2012, 15:55   #613  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,048
LameXP v4.04 Beta-6:

Quote:
Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc 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)
* 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)
* Run more than four instances in parallel on systems with more than four CPU cores (details)
* 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
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 22nd March 2012 at 02:15.
LoRd_MuldeR is offline   Reply With Quote
Old 11th March 2012, 03:59   #614  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 2,634
More work for you: sox-14.4.0 has gone final

Cheers
manolito
manolito is offline   Reply With Quote
Old 11th March 2012, 15:00   #615  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,048
Quote:
Originally Posted by manolito View Post
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...
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 19th March 2012, 01:25   #616  |  Link
KamikazeCJ
Registered User
 
Join Date: May 2004
Posts: 51
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.
KamikazeCJ is offline   Reply With Quote
Old 19th March 2012, 01:36   #617  |  Link
mariush
Registered User
 
Join Date: Dec 2008
Posts: 590
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?
mariush is offline   Reply With Quote
Old 19th March 2012, 01:40   #618  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,048
Quote:
Originally Posted by KamikazeCJ View Post
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)
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 19th March 2012 at 01:55.
LoRd_MuldeR is offline   Reply With Quote
Old 19th March 2012, 04:50   #619  |  Link
KamikazeCJ
Registered User
 
Join Date: May 2004
Posts: 51
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 is offline   Reply With Quote
Old 19th March 2012, 05:08   #620  |  Link
KamikazeCJ
Registered User
 
Join Date: May 2004
Posts: 51
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?

Last edited by KamikazeCJ; 19th March 2012 at 05:10. Reason: clarification
KamikazeCJ is offline   Reply With Quote
Reply

Tags
aac, aotuv, flac, lame, lamexp, mp3, mp4, ogg, oggenc, opus, vorbis

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 11:27.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.