Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Adding RG info with Lame: what is the point if it isn't supported? (Read 10026 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Adding RG info with Lame: what is the point if it isn't supported?

Quote from: halo001 on
I often use the --replaygain-accurate parameter on lame commandline encoder. I always enable this setting for decoding purpose.

What decoder are you using that makes use of replaygain information stored in the Lame header?

Adding RG info with Lame: what is the point if it isn't supported?

Reply #1 –
I don't have any issues regarding compatibility and dynamics. The main reason I use --replaygain-accurate is to enable decoding on the fly on my portable devices.

Adding RG info with Lame: what is the point if it isn't supported?

Reply #2 –
I doubt completely that any of your players are reading RG metadata from the Lame header. I skimmed the Lame changelog and didn't see anything about it being placed in an ID3v2 tag.  Can anyone confirm that this variant of Lame does?

Adding RG info with Lame: what is the point if it isn't supported?

Reply #3 –
Quote from: halo001 on
I don't have any issues regarding compatibility and dynamics. The main reason I use --replaygain-accurate is to enable decoding on the fly on my portable devices.


Now that I am updating the documentation, i see that this could be a misinterpretation of what it actually meant.

It says:
Quote
--replaygain-accurate Slightly more accurate ReplayGain analysis and finding the peak sample

Enable decoding on the fly. Compute "Radio" ReplayGain on the decoded data stream. Find the peak sample of the decoded data stream and store it in the file.


What it really means is:

Quote
--replaygain-accurate Slightly more accurate ReplayGain analysis and finding the peak sample

Compute "Radio" ReplayGain on the decoded data stream. Find the peak sample by decoding on the fly the encoded data stream and store it in the file.

Adding RG info with Lame: what is the point if it isn't supported?

Reply #4 –
Frankly, unless LAME implements ReplayGain 2.0 and/or we find some players/decoders that actually use the analysis, I think it's a moot point.

Adding RG info with Lame: what is the point if it isn't supported?

Reply #5 –
Quote from: BFG on
Frankly, unless LAME implements ReplayGain 2.0 and/or we find some players/decoders that actually use the analysis, I think it's a moot point.

Though it'd be quite handy, there's not that much of a difference between 1.0 and 2.0, at much a few DBs in my experience...

Adding RG info with Lame: what is the point if it isn't supported?

Reply #6 –
I fail to see it being handy at all if there is no player that reads the metadata from the location where Lame writes it.

Unless someone is going to say that this forked version of Lame writes RG to an ID3V2 tag, I don't see the point in continuing this line of discussion.

Hopefully halo001 is satisfied with the replies received relevant to this topic.  All I wanted to point out was that

there is likely no need to be concerned with --replaygain-accurate or even bother using it since it likely isn't going to do anything but consume CPU resources unnecessarily.

EDIT: I split the discussion, so what was stricken above is no longer relevant.

Adding RG info with Lame: what is the point if it isn't supported?

Reply #7 –
Quote from: greynol on
I fail to see it being handy at all if there is no player that reads the metadata from the location where Lame writes it.

Good point, didn't know that... sorry.

Adding RG info with Lame: what is the point if it isn't supported?

Reply #8 –
Madplay seems to be some player, which used the replaygain info stored in the header:

http://www.hydrogenaudio.org/forums/index....st&p=305970

Myself, I don't use the replaygain features in LAME. What I do is, let wavegain calc album gains once and for all for my CD backup, then have LAME apply a proper scale value when encoding the wave files to mp3.

Adding RG info with Lame: what is the point if it isn't supported?

Reply #9 –
...and the ancient plugin for Winamp.

I do essentially the same thing:
CD -> FLAC -> Add RG with foobar2000 -> Lame using --scale switch.

Adding RG info with Lame: what is the point if it isn't supported?

Reply #10 –
Quote from: TomasPin on
there's not that much of a difference between 1.0 and 2.0, at much a few DBs in my experience...

My experience is the same, for most music. However, the newer standard gives me about 5 dB of additional reduction on bass-heavy tracks. For me, that's definitely noticeable. It also is exactly what those tracks needed in order to be more in line with the others. (And when I say bass-heavy, I mean tracks that are mostly bass.)

Adding RG info with Lame: what is the point if it isn't supported?

Reply #11 –
Quote
Adding RG info with Lame: what is the point if it isn't supported?


That's a damned good question. Why don't the LAME developers give an option to write this data to ID3v2 TXXX/REPLAYGAIN_TRACK_GAIN and TXXX/REPLAYGAIN_TRACK_PEAK frames instead of (or in addition) to the LAME tag where few applications will read it?

I may be one of the few people who _does_ use --replaygain-accurate when encoding with LAME and actually makes use of the data. I have a script that does transcoding from FLAC and after running LAME with --replaygain-accurate, it uses LameTag to read the values and then metamp3 to write them to TXXX/REPLAYGAIN frames.

Adding RG info with Lame: what is the point if it isn't supported?

Reply #12 –
I've fooled around with LameTag to do that once or twice, but didn't incorporate it into my process because I use album gain.

http://www.hydrogenaudio.org/forums/index....st&p=755464

Adding RG info with Lame: what is the point if it isn't supported?

Reply #13 –
Yeah, I'm still looking for an easy way to add ReplayGain tags, including album gain, from the command line. You might notice that I ask about it every month or so.

But in truth, I'm not sure how much I'd use album gain on my portable players, which is where I use Mp3. The more closely matched track gain might still be more desirable to me when pounding out the miles on the treadmill or bike. The subtleties of relative volume levels of tracks on an album may be completely lost on me in that use case.

Adding RG info with Lame: what is the point if it isn't supported?

Reply #14 –
Quote from: JJZolx on
Yeah, I'm still looking for an easy way to add ReplayGain tags, including album gain, from the command line.


On Linux: caudec -g *.mp3

Adding RG info with Lame: what is the point if it isn't supported?

Reply #15 –
Quote from: JJZolx on
Why don't the LAME developers give an option to write this data to ID3v2 TXXX/REPLAYGAIN_TRACK_GAIN and TXXX/REPLAYGAIN_TRACK_PEAK frames instead of (or in addition) to the LAME tag where few applications will read it?

Good point.  I suspect that if that modification were made, and ReplayGain V2.0 support was added, a LOT of people would start using the function again.  Any idea if a formal request has been made of the developers?  (I can't access sourceforge ATM.)
 

Adding RG info with Lame: what is the point if it isn't supported?

Reply #17 –
So far things cleared out on how lame writes replaygain. Hope future lame versions support writing RG tags on ID3v2. As for now, I'll use foobar's replaygain scanner instead. I'll try to manually modify the default RG values. So can anyone recommend me values which atleast is optimized for any tracks? Thanks for all feedbacks.

Adding RG info with Lame: what is the point if it isn't supported?

Reply #18 –
Quote from: halo001 on
[...]  I'll try to manually modify the default RG values. So can anyone recommend me values which atleast is optimized for any tracks? [...]


Probably you mean "target loudness" where you said "default RG value". There isn't such a thing as a "default RG value", neither there can be a RG value (nor target loudness), optimized for everything.




Quick guide to Replaygain:

Let's take a recording of a piano, recorded to digital using two microphones, one placed next to the piano, and another placed at five meters from the piano.
As it should be obvious, the microphone nearer to the piano will record the sound at a higher amplitude than the one placed far from it, but both would have captured the same sound.


On playback, we would like both to sound at the same loudness (which does not mean the same amplitude, although in this case, because it is exactly the same sound, it probably will also be the same amplitude).

To do so, we would need to either decrease the sound recorded from the first microphone, or amplify the sound recorded from the second microphone. (More on what is the better option later)
So we reduce the volume of the sound from the first microphone, and take note of how much we needed to change the volume so that it played like the second microphone.

Said all this, Replaygain is a technology that is able to determine by how much the volume of  the microphone A will need to be reduced (or generally speaking, altered), in order to be played at the same loudness than another recording B (Reference) which we have determined to be the desirable loudness.
Then, this amount is usually stored in a tag so that players can apply the volume change. (MP3Gain is different in that it actually modifies the content of the file, but in a way that also represents changing the volume)


So we need to know two things:
* Reference loudness: The specification says how this is calculated, but it is enough to say that it's the loudness of a determined signal, played at a specified volume.  The target Replaygain Value to achieve this loudness was originally 83dBL, but soon after standardization it was changed to 89dBL which is what has been since. (The R128 standard uses a different way to measure it, but we could say that, approximately, its target loudness is 84dBL)
* Way to calculate the loudness: This also is described in the specification, but it's important to note that the amplitude is only slightly relevant respect to the loudness. A lower amplitude signal can perfectly be several dBL louder than a higher amplitude one.
* A way to store the loudness , so that it can be played back at the same loudness than the reference signal. As I said above, this is stored in a tag.


One cannot get a random target loudness, neither can a target loudness by itself be any more good than another target loudness (except, of course, if one of the values is extremely far from usual values).




The only reason why a different target loudness is desirable is when the device does a poor job (not loud enough, or noisy) playing at the default target loudness, or also in the case where one would mix tracks that have Replaygain info with tracks/streams that do not have them.
That's why some software, like foobar2000, Winamp and others, have one or two pregain sliders in the Replaygain settings, in order to accommodate for this.

With this, I am saying that one rarely would want to modify the calculated Replaygain values of a track, but if possible, the pregain that is applied by the player.

Adding RG info with Lame: what is the point if it isn't supported?

Reply #19 –
Quote from: greynol on
I do essentially the same thing:
CD -> FLAC -> Add RG with foobar2000 -> Lame using --scale switch.



I am interested in the --scale switch you mentioned Greynol.

I tried to search it but the best I could come up with is that it is not reliable for VBR.  Are you using CBR or ABR with your Foobar conversions?  What number do you put after the --scale switch?

Btw, I use Lame3100m (--bCVBR 266 - %d --replaygain-accurate --scale).  I used to just scan the files after the conversion and then "Apply ReplayGain Data to MP3 Data" but this might remove a couple of steps.

Adding RG info with Lame: what is the point if it isn't supported?

Reply #20 –
http://www.hydrogenaudio.org/forums/index....st&p=601287

That --scale doesn't work reliably with VBR is news to me.  I use VBR, so if I've been doing something "wrong" then I haven't noticed.

Is it possible that you either have bad information or didn't quite understand what it was that you read?

Adding RG info with Lame: what is the point if it isn't supported?

Reply #21 –
Quote from: onanboy on
...Btw, I use Lame3100m (--bCVBR 266 - %d --replaygain-accurate --scale).  ...

'--scale' needs an argument (the scale factor). You get a warning if you use  your setting from the cmd line.
Just keep foobar doing the replaygain work. That's what I do, too. Not a big task IMO.
BTW using '--scale' the way robert and Greynol do is not exactly the same thing. Their procedure has the additional property that they provide kind of a standard input loudness for the encoding process. I'm pretty sure they do it because of this.
lame3995o -Q1.7 --lowpass 17

Adding RG info with Lame: what is the point if it isn't supported?

Reply #22 –
@onanboy: scale parameter

I also would like to know where you got it that this works worse for VBR, or any other mode.

By the very same nature of what the switch does, the effect on any mode is the same. What you might have read and incorrectly misunderstood is that CBR used to have a gain of 0.97 (i.e. reduce the volume slightly ) and VBR had it at 1.0 (i.e. no change).


As a side note, in the LAME 3.100 there has been added a complementary switch: -gain . This one accepts units in dB upcoming gain switch




Addendum about why it is beneficial to use the scale/gain switch versus letting ReplayGain analyze and apply the change:

Due to the Loudness war in the last decade, the loudness of music has consistently been increased. This increased loudness means higher amplitude in the different frequency bands, and usually an increase of the Noise Level (reducing the global SNR)

Lossy encoders (of which LAME MP3 is an example) use several tools too analyze the audio, and determine what data to maintain that allows them reconstruct the original audio in a way that audibly resembles the original.
Due to the increased loudness of current music, more data is (incorrectly) determined important to be maintained. Especially unneeded, if the intention is to apply Replaygain later on.
And more data to be maintained obviously means higher bitrate required.

It is because of this that applying the gain before the lossy encoding is able to reduce the required bitrate, while maintaining the same audible quality.

Adding RG info with Lame: what is the point if it isn't supported?

Reply #23 –
Quote from: [JAZ] on

@onanboy: scale parameter

I also would like to know where you got it that this works worse for VBR, or any other mode.



I am sorry but I cannot find the post where (I thought) I read that someone said that there was something wrong with using Scale with VBR encoding.  You are both probably correct that I misinterpreted the posting.

Thanks for correcting me and anybody that happens along to this thread.  I appreciate the advice on the usage of the --scale parameter.

Onanboy

Adding RG info with Lame: what is the point if it isn't supported?

Reply #24 –
Quote from: [JAZ] on
It is because of this that applying the gain before the lossy encoding is able to reduce the required bitrate, while maintaining the same audible quality.

Is this in theory or is it supported by listening tests?