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. |
6th March 2012, 00:47 | #601 | Link | |
Registered User
Join Date: Feb 2012
Posts: 6
|
Quote:
Is there eventually some kind of meta-data field where applications can store the computed normalization level in Decibel? |
|
6th March 2012, 00:51 | #602 | Link | ||
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
Quote:
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!
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 6th March 2012 at 01:13. |
||
6th March 2012, 01:23 | #604 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
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
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 6th March 2012 at 02:00. |
|
6th March 2012, 09:42 | #605 | Link | |
Registered User
Join Date: Feb 2012
Posts: 6
|
Quote:
"--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. |
|
6th March 2012, 13:56 | #606 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
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)
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 6th March 2012 at 13:59. |
6th March 2012, 14:05 | #607 | Link | |
Registered User
Join Date: Feb 2012
Posts: 6
|
Quote:
Some applications using the "replaygain" tag and if set playing with a modified volume and this is not the wished behavior. |
|
6th March 2012, 14:18 | #608 | Link | ||
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
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:
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!)
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 6th March 2012 at 17:56. |
||
6th March 2012, 21:27 | #609 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
LameXP v4.04 Beta-5:
Quote:
http://lamexp.git.sourceforge.net/gi...=HEAD#71a113b0
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 10th March 2012 at 15:51. |
|
9th March 2012, 17:03 | #610 | Link |
Registered User
Join Date: Mar 2002
Location: Krautland
Posts: 903
|
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) |
9th March 2012, 17:18 | #611 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
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...
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 9th March 2012 at 17:40. |
|
10th March 2012, 15:55 | #613 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
LameXP v4.04 Beta-6:
Quote:
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 22nd March 2012 at 02:15. |
|
11th March 2012, 15:00 | #615 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Doesn't look like there was any change since RC-3 that would effect us. But I will make a new build anyway...
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ |
19th March 2012, 01:25 | #616 | Link |
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. |
19th March 2012, 01:36 | #617 | Link |
Registered User
Join Date: Dec 2008
Posts: 589
|
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? |
19th March 2012, 01:40 | #618 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
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)
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 19th March 2012 at 01:55. |
|
19th March 2012, 04:50 | #619 | Link |
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. |
19th March 2012, 05:08 | #620 | Link |
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 |
Tags |
aac, aotuv, flac, lame, lamexp, mp3, mp4, ogg, oggenc, opus, vorbis |
Thread Tools | Search this Thread |
Display Modes | |
|
|