some clarifications on mp3gain?

Topic: some clarifications on mp3gain? (Read 5681 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

some clarifications on mp3gain?

2006-09-17 20:10:54

I've been reading some threads on mp3gain and am using it for the first time. There's a few things I'm still not 100% clear on so I thought I would start a new thread to try and get a really clear answer and so if others are having the same questions they don't need to wade through the other, potentially ambiguous, threads.

First thing I've noticed is that many of my mp3s, despite never having gain modifications previously applied, are shown as having "clipping" by mp3gain's analysis. I understand that if you increase the gain you can cause clipping, but what exactly does mp3gain mean when it tells you that an unmodified mp3 encoding of a wav file already has clipping.

Bearing in mind my rather naive understand of how exactly mp3 works, I can think of 3 possibilities:

a) The original wav has clipping. In this case lowering the gain should not help as while this will lower the amplitude of the clipped peak, it will still be clipped.

b) The original wav doesn't necessarily have clipping, but due to the way mp3s are encoded, the mp3 file's internal representation of the wavform contains clipping. In this case lowering the gain should not help for the same reason as in (a).

c) The original wav doesn't necessarily have clipping, and the mp3 file's internal representation of the wavform doesn't contain clipping either, but due to the way mp3's are encoded it has a larger dynamic range than the original wav. As a consequence, when this internal representation is decoded to a 16bit wavform, the decoded wavform will contain clipping, even though the internal representation does not. In this case, lowering the gain with mp3gain will prevent clipping during decoding, as this will bring the unclipped peaks of the internal representation below the threshold of what can be represented in the 16bit decoded wavform. (Effectively this reduces the dynamic range of the decoded mp3 to fit within the 16bit limit.)

From what I understand (particularly from this thread: http://www.hydrogenaudio.org/forums/index....8058&st=25) what mp3gain means when it says a previously unmodified mp3 is clipping is c), above. Is this correct?

I also gather that while it's easy to be taken aback by how many of your mp3s are seemingly clipping, that in reality this may not have any audible effect. For one, I've never noticed any obvious distortions when listening to mp3s that mp3gain tells me are clipping. I've experienced trying to record analog sources onto my computer with the record level set too high and the resulting clipping on the wavs were obviously discerned when listened to. So, clearly the effect on these mp3s is either much subtler or inaudible. Also, lame's preset encoding settings have been tuned over years and it seems to me that if lame is producing seemingly clipped mp3s that the clipping can't be audible, or the tuned settings would have naturally evolved to produce mp3s that don't clip. In the thread linked to above, it's suggested that the clipping occurs for very narrow peaks and this may be why it's not audible. This leads me to believe that a setting of "Y" on clipping in mp3gain isn't necessarily an indicator that the mp3 is crap. It also makes me think that it's more important to avoid clipping when raising the gain in mp3gain than to reduce the gain if the unmodified mp3 is identified as having clipping. This is because when you raise the gain, there is a possibility that you will raise it to a point where the original peaks from the uncompressed wav will be clipped, as opposed to only clipping larger peaks introduced by the mp3 encoding process. The former is more likely to be audible than the latter. Does this sound reasonable?

Finally, there's the issue of tagging. From what I gather mp3gain after analysis stores several tags in APEv2 format. These probably include tags for: track volume, max noclip volume and album volume as well as at least one tag for original track volume (required for undo). From what I gather mp3gain also stores replaygain values under the lame header. From what I understand, replaygain tags may contain values for both track and album volumes at the same time so that the decoder can decide whether to normalize by track or by album.

Now I've seen in several threads people suggest using foobar2000 (I've never used it) to get replaygain values after applying mp3gain modifications to the original mp3s. It seems to me, that if mp3gain adds replaygain tags to the mp3s it analyzes, that it should be smart enough to automatically modify these values when it performs a gain adjustment. If this is the case, I don't understand why you would need to reanalyze the files using replaygain under foobar2000 since the correct values should already be present in the lame header after running mp3gain. Does mp3gain fail to modify the replaygain tags after it performs a gain adjustment?

Also, does mp3gain store the replaygain values more accurately than the -1.5db adjustments it can make, or does it just store the -1.5db adjustments in a replaygain compatible format?

Thanks!

some clarifications on mp3gain?

Reply #1 – 2006-09-17 23:00:24

You hit the bull's eye with c).

Regarding Lame's tuning: No its psy model does not account for any possible clippings since the information is preserved. It's up to you to source LAME with appropriate signals or to use tools like replaygain, mp3gain if you're semi-paranoid about this issue ... mp3 encoding is a lossy process so there's always the risk of clipping -- especially when your source is very loud.

As for audibility: I'm sure I've a couple MP3s that clip during decoding. I've never noticed any artefacts due to that -- even before I started to use a preamp of -3 dB for non-RG'ed files. (Foobar user)

I'm not sure about the meta data thing. I'm not a mp3gain user but AFAIK it can adjust directly the gain on the audio data in steps of 1.5dB compatible with every player and add some metadata for the fine adjustments (only supported by RG-enabled players). mp3gain users can probably elaborate.

some clarifications on mp3gain?

Reply #2 – 2006-09-18 00:16:53

Sebastian, I think that the metadata mp3gain stores is there more to make a "rollback" to the previous state possible than to make refinements possible.

tinaa, the rationale behind mp3gaining (album mode) and than replaygaining is to make it possible to apply track gain at playback time in a "compilation" or "radio" scenario, where you want all the tracks to be played at about the same volume. Edit 2: this is quite wrong. mp3gain already adds replaygain (track too) metadata in APEv2 tags, so assuming you you're using the correct player like foobar2000 0.9.x (see note) and maybe others you can directly use "track gain" while playing, if you wish. Note: I say foobar2000 0.9.x because in my experience foobar2000 0.8.3 (which for different and personal reasons is still the one I use) has the nasty tendency to screw up the undo information if you switch from APEv2 to ID3v2 tags (you can't handle both with it). As far as I understand this problem doesn't exist with 0.9.x, but I can't confirm, because as I said I still use 0.8.3

I totally concur with you that the clipping generated by a positive mp3gain is much more insidious than the native, physiological (and to me inaudible) clipping that an mp3 encoding can present.

BTW, tinaa, the link to the "other" thread is to a post midawy in the thread, and IMHO not to a most brilliant part of it...

Cheers!

Sergio

Edit 1: I don't think mp3gain modify in any way the LAME header. It just stores its metadata in APEv2 tags (and I wish it could do it in ID3v2 instead, but this is just my personal opinion...)

some clarifications on mp3gain?

Reply #3 – 2006-09-18 00:48:40

Quote from: SebastianG on 2006-09-17 23:00:24

I'm not sure about the meta data thing. I'm not a mp3gain user but AFAIK it can adjust directly the gain on the audio data in steps of 1.5dB compatible with every player and add some metadata for the fine adjustments (only supported by RG-enabled players). mp3gain users can probably elaborate.

I've used mp3gain to apply Album Gain to my collection (EAC secure, AccurateRip verified)

Here's an example Properties tab from Foobar2000 showing the Replaygain info taken from the APEv2 tag of one file.

Metadata:

Code: [Select]

ARTIST = Lenny Kravitz
TITLE = Flowers For Zoë
ALBUM = Mama Said
DATE = 1991
TRACKNUMBER = 09
GENRE = Rock
COMMENT = lame --alt-preset standard

Technical info:

Code: [Select]

enc_delay = 576
enc_padding = 1920
mp3_accurate_length = yes
bitrate = 192
codec = MP3
channels = 2
samplerate = 44100
extrainfo = VBR
mp3_stereo_mode = joint stereo
mp3gain_minmax = 080,207
mp3gain_album_minmax = 075,207
mp3gain_undo = +003,+003,N
replaygain_track_gain = +8.265000 dB
replaygain_track_peak = 0.440781
replaygain_album_gain = +0.115000 dB
replaygain_album_peak = 0.655103
 ---------- 
7215936 samples @ 44100Hz
File size: 3 919 654 bytes

You can see that the remainder of the Album Gain correction (+0.115 dB) is included in the APEv2 tag, so players like foobar2000 will adjust further. Also, of course, Track Gain for this quiet track on the album is considerably greater than the Album Gain and if you chose to use Track Gain instead, you'd need that info in your compatible player. Compared to foobar2000's ReplayGain scan (in all versions after about v0.6), it stores to slightly less accuracy, but a difference of no more than +/- 0.0005 dB is utterly negligible to the human ear, and the peak values are stored to 6 decimal places, so more than ample for perfect clipping prevention on 16-bit audio. (difference a little greater than 0.0005 dB might occur if foobar and mp3gain implement the ReplayGain calculation using different gapless playback settings or block lengths, but I'm almost certain the differences would be negligible to the human ear).

You can also see the data that's specific to mp3gain. The mp3gain_undo indicates that the MP3 file's gain fields have each been reduced by 3 units (of 1.5 dB each) so require 3 units of increase to undo the mp3gain process and restore the original file. And indeed, a check of mp3gain's applied changes logfile, indicates a -4.5 dB change for each track on this album was applied during Album Gain.

So rest assured that players with the fullest ReplayGain compatibility will make use of the best information to make further adjustments according to your preferences (which, for foobar2000 could include prevention of clipping if it would still occur at the RG target volume). Meanwhile, your dumbest personal pod, DVD-player or in-car MP3 player will still play all files at an adjusted volume to enable painless random/shuffle playback of multi-album collections.

So, Sergio, although the main intention was to allow "rollback" to the previous state, it is in fact exactly what foobar2000 needs and indeed actually uses to refine the adjustment in the floating point decoded waveform prior to rendering it to the output bit-depth.

some clarifications on mp3gain?

Reply #4 – 2006-09-18 02:09:51

Dynamic, thank you for your detailed analysis.

Actually I never intended to say that refinement was inpossible using the stored metadata, but that the crucial point for storing metadata was to make an "undo" possible because IMHO an a maximum error of 0.75 dB between the "perfect" replaygain value and the "applied" mp3gain correction is negligible (at least for my 50 years ears ).

Cheers!

Sergio

Edit: removed erroneous elucubrations due to a botched experiment!

some clarifications on mp3gain?

Reply #5 – 2006-09-18 02:25:52

I quite agree that 0.75 dB (or 1.5 dB) steps are inaudible to me. This is pretty much proved by doing a very slow fade in (e.g. 48 dB in 20 seconds of more) in an app like mp3DirectCut, which I've done a few times and never noticed any obvious staircasing in the loudness reduction despite the fact it jumps in -1.5 dB steps every 0.625 seconds or so.

Anyway, I think we're all pretty happy that mp3gain does a fine job of making albums sound like they're near-enough the same loudness, and also that clipping of one or two samples' duration (especially during a transient in the music) is essentially inaudible (and mp3gain usually leads to quieter output, thereby reducing the likelihood of clipping anyhow).

some clarifications on mp3gain?

Reply #6 – 2006-09-18 10:18:31

I edited my post #3 above, and because I gave incorrect information in it, I guess those who are reading and subscribed to this thread would like to be informed of this edit. Hence this almost worthless post!

Sergio

some clarifications on mp3gain?

Reply #7 – 2006-09-18 22:00:36

Quote

Regarding Lame's tuning: No its psy model does not account for any possible clippings since the information is preserved. It's up to you to source LAME with appropriate signals or to use tools like replaygain, mp3gain if you're semi-paranoid about this issue ... mp3 encoding is a lossy process so there's always the risk of clipping -- especially when your source is very loud.

My thinking here was that the tuning of the lame presets probably involved iterative feedback from experienced users. It's clear that high quality lame presets will produce files that will clip on decoding for a significant number of source files (probably a particular problem for modern pop/rock songs with lots of dynamic compression). So if this type of clipping resulted in audible artifacts on decode, users would complain about these artifacts. As a result the developers would search for settings that eliminated them. If the artifacts were caused by clipping, then the search would necessarily lead to settings that reduced or eliminated the clipping (such as pre-scaling adjustments). Ergo, the fact that the tuned lame settings still frequently produced clipping suggests that this clipping does not generally produce audible artifacts.

There are, of course, a number of ways these assumption could be wrong and as I don't really know what the tuning process entailed I wouldn't presume to claim my analysis is correct. Just thought I'd explain my reasoning... Even if I'm correct, it only speaks to the effects of clipping from a newly lame encoded mp3 file, not to effects of introducing clipping by raising the gain after the fact.

Quote

BTW, tinaa, the link to the "other" thread is to a post midawy in the thread, and IMHO not to a most brilliant part of it...

Yeah, I'm not really sure the correct way to link to other threads. I just copied the address bar from the browser window, which at the time actually was showing the first page of the thread. I suspect some of the fancy HTML code on the forum may render what's shown in the address bar outdated compared to what's in the window. Although, the graph was the point in that thread where I finally started to think I understood what was going on. Unfortunately, the originator of that thread never quite seemed to get it. Let's chalk that up to less than fluent mastery of English... In any case, my hope was that this thread would clear some of that up and be considerably shorter to wade through...

As for the headers, I think Dynamic's post really explains what's going on but I thought I'd add, reiterate some of it for clarity.

My reference to the Lame tag was probably from a misunderstanding of something I'd read. It turns out the Lame header does contain some relevant tags although they're probably not used by any other application. Here's what LameTag has to say about it:

Code: [Select]

>lametag.exe -help

LameTag - Reads the LAME tag from an mp3 file
Copyright (c) 2005 phwip
Release 0.4.1, compiled 2005-09-09

Usage: LameTag [--recursive] <filename|folder>
       Wildcards are supported in the filename

<SNIP>

- The ReplayGain fields are only written by LAME version 3.94 and
  higher.
- The MP3Gain field in the LAME tag is not written by any current
  implementations of MP3Gain.

From a freshly encoded file with no other tags I found these tags using lametag.exe:

Code: [Select]

RG track peak:      <not stored>
RG track gain:      -10.1dB (determined automatically)
RG album gain:      <not stored>
MP3Gain change:     <none>

So there's some replaygain data put there by lame, although it's incomplete. I've verified that MP3Gain doesn't modify the lame tags in any way.

After running MP3Gains analysis, an APEv2 header is added. I used dbPoweramp to read the tags. Here's what's displayed in the MP3Gain window after undo any changes, followed by the APEv2 tags:

Code: [Select]

Volume: 99.1
clipping: Y
Track Gain: -10.5
clip(Track): N
Max Noclip Gain: -1.5
Album Volume: 97.7
Album Gain: -9.0
clip(Album): N

MP3GAIN_MINMAX: 147,255
MP3GAIN_ALBUM_MINMAX: 139,255
MP3GAIN_UNDO: +000,+000,N
REPLAYGAIN_TRACK_GAIN: -10.07000 dB
REPLAYGAIN_TRACK_PEAK: 1.153396
REPLAYGAIN_ALBUM_GAIN: -8.730000 dB
REPLAYGAIN_ALBUM_PEAK: 1.201895

Then after performing a track gain in MP3Gain:

Code: [Select]

Volume: 88.5
clipping: N
Track Gain: 0.0
clip(Track): N
Max Noclip Gain: 9.0
Album Volume: 87.2
Album Gain: 1.5
clip(Album): N

MP3GAIN_MINMAX: 140,248
MP3GAIN_ALBUM_MINMAX: 132,248
MP3GAIN_UNDO: +007,+007,N
REPLAYGAIN_TRACK_GAIN: +0.465000 dB
REPLAYGAIN_TRACK_PEAK: 0.342907
REPLAYGAIN_ALBUM_GAIN: +1.805000 dB
REPLAYGAIN_ALBUM_PEAK: 0.357326

and after performing an album gain:

Code: [Select]

Volume: 90.0
clipping: N
Track Gain: -1.5
clip(Track): N
Max Noclip Gain: 7.5
Album Volume: 88.7
Album Gain: 0.0
clip(Album): N

MP3GAIN_MINMAX: 141,249
MP3GAIN_ALBUM_MINMAX: 133,249
MP3GAIN_UNDO: +006,+006,N
REPLAYGAIN_TRACK_GAIN: -1.040000 dB
REPLAYGAIN_TRACK_PEAK: 0.407787
REPLAYGAIN_ALBUM_GAIN: +0.300000 dB
REPLAYGAIN_ALBUM_PEAK: 0.424935

So this shows, as Dynamic said, that the normalization data is stored to a higher accuracy in the replaygain tags by MP3Gain. It also shows that both track and album replaygain data as well as peak data is stored by MP3Gain. Furthermore, it shows that when MP3Gain makes any direct gain modifications to the MP3 file it updates both the MP3Gain tags and the Replaygain tags appropriately to reflect the modified file.

From some comments I've read in other threads, one might get the impression that it's necessary to redo the replaygain analysis in foobar2000 after having used MP3Gain on the same files. However, based on what's been presented in this thread, I would say that redoing the replaygain analysis in foobar2000 is completely redundant as all the same information is already accurately placed in the APEv2 tags by MP3gain. This could save a lot of time considering how long the analysis can take on a large library...

Of course, this wouldn't be true if foobar2000 can't properly read the APEv2 tags created by MP3Gain or if foobar2000 adds some extra useful information. However, so far I haven't read anything to suggest this is the case.

Thanks to everyone for participating!

Notice