| Comments: |
wait, if these are plugins for XMMS, they shouldn't be processing all your mp3s at once, they should be dealing with each song as it's chosen, right? and not actually modifying the mp3 on disk, just adjusting the level it gets played back at.
itunes has a trick that does that.
...however, it's not that useful. what you really need is to compress the softer mp3s before you normalize them, or at least to check the average level rather that the maximum level, which seems to be unusual in these things for some reason.
![[User Picture]](http://p-userpic.livejournal.com/5887295/515656) | From: ![[info]](http://p-stat.livejournal.com/img/userinfo.gif) jwz
Wed, 4-Aug-2004 5:31 PM (UTC)
| (Link)
|
mp3gain modifies the actual MP3 data.
Normalize is two steps: first it analyses a set of MP3 files and decides what volume change to make, and writes that number down in each file; then part two is the plugin that actually acts on that information.
mp3gain checks the average rather than the peak; I'm not sure whether normalize does the same thing.
I've used the itunes/ipod feature which tags each track with a volume offset, which can be optionally used at playback time.
I decided it sucks. It might be useful if there was some way to set the degree to which it tries to move all tracks to the same average volume, but there isn't any such option, so I ended listening to tracks that should be quiet and ones which should be loud (e.g. from the same album) one after another, and the correction was totally disconcerting. So, for now, I just live with the volume levels as they were on CD, sometimes changing the volume by hand at playback time. :(
*grumble grumble about the way recent recordings are compressed to hell*
![[User Picture]](http://p-userpic.livejournal.com/40848497/1070091) | From: aerosolkid
Wed, 4-Aug-2004 5:42 PM (UTC)
some mp3gain info | (Link)
|
There's source on the download page (mp3gain-1_4_3-src.zip). I compiled it on RH8 no problems. mp3gain is used within gtkpod to normalize the tunes on my iPod, so I'm not at all familiar with running it free-standing on the command line, sorry. But I do know that since it implements replaygain, it actually is a stand-alone type thing: i.e., the "replaygain" factor of the track is not dependant on other tracks, just on how the average level of this track compares to the "platonic ideal average level", or some such.
have you thought about writing a script that....
I've used mp3gain, and while it does actually modify the mp3 data, it does so so quickly that I can't imagine it's actually re-encoding them. As far as I can tell, it's just modifying the sample volumes for each sample. It's fast, there's no lossiness (I'm pretty sure if you increase and decrease the volume and avoid clipping, you'll end up with the original file again.) Plus, it works on all players.
mp3gain needs intervention, either on an album, or on a directory of files en masse, depending on whether you want to boost volume to all files in an album by the same amount.
No idea if it'll run under wine.
http://www.replaygain.org/ states that RG is metadata as well, and mp3gain is a program that scribbles RG info in mp3 files. I would suspect that mp3gain thus doesn’t meddle with the actual contents of said files. Also on mp3gain’s site: No. MP3Gain does not decode and re-encode the mp3 to change its volume. You can change the volume as many times as you want, and the mp3 will sound just as good (or just as bad!) as it did before you started.Be vigilant.
![[User Picture]](http://p-userpic.livejournal.com/44932674/887477) | From: weev
Wed, 4-Aug-2004 6:31 PM (UTC)
| (Link)
|
I initially normalize -m'd my whole collection and have a session crontabbed weekly that brings the new arrivals in line. No problems.
<3 2 normalize
![[User Picture]](http://p-userpic.livejournal.com/71550492/2291789) | From: cacepi
Wed, 4-Aug-2004 6:34 PM (UTC)
RVA2 does indeed work... | (Link)
|
And work very well. I'd recommend that if you're worried about tweaking the mp3 stream. It seems to run a little faster if you have the MAD library on your system.
![[User Picture]](http://p-userpic.livejournal.com/43561514/540280) | From: chrs
Wed, 4-Aug-2004 6:41 PM (UTC)
| (Link)
|
Re-encoding your entire collection just doesn't take up a lot of time - it also degrades (not very much, but to purists it's a big deal) audio quality. any re-encoding does. if you take a VBR mp3 that has an average bitrate of about 165kbps and a peak volume of -8dB, when you normalize it you're also normalizing the quiter artifacts made by the nifty little codec which aren't as audible at lower volumes. I'd scrap the idea of completely redoing everything and just stick with a new standard for when you rip cds or vinyl. Just normalize before you encode.
Another quick anecdote: make sure you're simply normalizing: taking the highest point in the track and making it 0.0dB while bringing everything up else with it at an equal volume and NOT compressing the dynamic range of the track (also known as loudness). At louder volumes it simply sounds like pure crap.
![[User Picture]](http://p-userpic.livejournal.com/8823056/650620) | From: arn
Wed, 4-Aug-2004 7:19 PM (UTC)
Well... | (Link)
|
...I dunno what half of these guys are saying, but I do know that mp3gain has worked it's magic just fine on my 5500+ mp3's. It doesn't work perfectly, some songs are still noticibly louder/softer than others, but it's good enough. I'd say it was pretty sensible really, and it is very easy. Just play with a selection of about 20 songs until you get the settings just right for you, and you're away laughing. Can't help with the linux question, sorry.
But when all is said and done, at least I can go from Pink Floyd to Metallica without my ear drums getting popped.
rob.
![[User Picture]](http://p-userpic.livejournal.com/11824824/716276) | From: biburat
Wed, 4-Aug-2004 8:57 PM (UTC)
use foobar2000 | (Link)
|
foobar2000 audio player has, i believe, the best replaygain support to date. For example, you may scan your playlist as multiple albums so loud and quiet tracks from the same album get tweaked by the same degree. Settings are stored in metadata so they can easily be removed later effectively leaving you with what you had in the first place. The only problem is that it is for windows, but i managed to run it in wine almost off the shelf (you may have to change the default UI because it has a strange bug with repainting playlist). foobar2000.orgalternative installer and various plugins
Normalize works as advertised. This means that using the --id3-compat option will make it do what you want with xmms with unpredctable results (no normalization or failure) on other players. Not using that option, but using --id3-unsync lets your files work just right with pretty much every player ever made. The trick is to use the mad input plug-in for xmms and ignore the living fuck out of the normalize plug-in. The other problem with "works as advertised" is that you may realize that you really don't want Sky Cries Mary playing at the same volume as Nitzer Ebb. The --mix option does what you want for your office, but might really lower your listening pleasure at home. Unfortunately, there seems to be no "unnormalize" command, which is another good reason to avoid the --id3-compat option. You can unfuck badly normalized files with the MPEG::ID3v2Tag module from your favorite cpan mirror. I don't think that there's a similarly easy unfucking process for --id3-compat munged files.
Other posters seem to think that mp3gain implements replaygain- if so, I'd go for it. I use vorbisgain, which adds replaygain tags to oggs. It works beautifully- xmms supports replaygain in oggs with no effort. And all it takes to do the tagging is vorbisgain -r /media/music. Then you just wait (for a large collection, it WILL take a while, as it has to analyze each song) but it's entirely hands-free (and, more importantly, it doesn't damage the music any further than encoding it did). And now that I know about mp3gain, maybe I can fix up the few remaining mp3s in my collection. :)
mp3gain works, but the problems are:
1) It's bad at coping when it fucks up
2) Every so often it can't bring a track up to the volume it wants to because of clipping.
3) Your MP3s will be much quieter than everyone else's on the office jukebox :-)
Oh, and you have to fuck about a bit to get it to compile under Unix, but it's not too bad.
![[User Picture]](http://p-userpic.livejournal.com/53833999/1232513) | From: jwm
Thu, 5-Aug-2004 2:01 AM (UTC)
| (Link)
|
lj-raw>
Rightyright. Normalization, as we know, blows, so what mp3gain and vorbisgain do is calculate the apparent loudness of a given track, or album, and work out a gain value, in decibels, that the track's volume should be adjusted by, relative to a reference volume. Sordid details following. (So to the plonker who said "just use ReplayGain", read the link and pay attention.)
vorbisgain is great. It stores the track and album gain information, as well as the highest volume change before clipping sets in, into the vorbiscomment tags of your oggs, largely because the vorbiscomment spec wasn't written by kids and so allows you to just make up tags. The xmms plugin uses them, and allows you to switch between album and track gain at runtime. FLAC even has the analyzer built into the encoder and works in both ogg and native outputs. This is no use to you, unfortunately, as I doubt you'd re-encode even if you had software that only required a trained monkey to feed it CDs. So...
mp3gain converts the decibel change to the nearest integer factor and changes the mp3 itself, due to you being able to tweak some value in each packet of mp3 to change the volume (I understand that the standard preamp and equalizer does this). This is relatively non-destructive, in that the most recent versions bother to save a setting that can reverse the volume level in an APEv2 tag attached to the file. (APEv2 is used by Monkeys Audio; I have no idea how well supported by players it is.)
I've managed to build it in the past for Linux, but this did require writing a Makefile and hitting the source code with a stick for a few hours. The command line options are fairly hideous, but you can get it to process everything in a directory with a bit of source kicking and some scripting. It's a bit slow — processing 2 gigs in something like an hour — but I only have a Duron 850, so that's probably not a problem for everyone else. On a per album basis, vorbisgain is fairly quick, and about 2 minutes each, and both programs use the same analyzer code, so that's probably a fair point of reference.
I don't know much about the RVA2 tag; when I was last closely looking at the mp3 situation, it was much talked about, but there where few implementations available both in the plugin side and at the analyzer side.
![[User Picture]](http://p-userpic.livejournal.com/73855688/1300180) | From: gths
Thu, 5-Aug-2004 5:37 AM (UTC)
| (Link)
|
Are we avoiding the term RMS for any reason?
Is it a sensible and non-terrifying thing to apply either/both of these en masse to 18,000 MP3 files?You know the routine, soldier!
- Backup the originals!
- Apply mass file changing routine
- Check results.
- Recover originals from backup if necessary, and tell yourself not to do it again!
If it saves you time for the desired result, do it.
Why do people (represented in the comments above), when faced with overly-compressed songs that sound like shit, feel the need to make the rest of their library sound just as bad?
Peak limiting your entire library isn't the solution (this is what ReplayGain is essentially doing)-- do you really want all of your pre-1995 songs to sound like absolute shit due to some software trying to second-guess an audio engineer?
Instead, find the most egregious offenders (the loudest tracks) and normalize those fuckers down to 80% or so. I guarantee you will have a lot less hassle, and then when you turn your volume up to eleven, "Dig It" won't sound like some pulsing house piece of garbage.
I just use the normalize utility.
i havent used any of the tools you mention- i just handle that in the audio realm on the output with a compressor plugin
I've used mp3gain on my MP3 collection. While I like its approach, I wouldn't recommend it for a collection as large as yours.
mp3gain, as you note, modifies the mp3s directly. It does so losslessly, but it's still a pain to get the original volume back. On top of that, the normalization process is, in my experience, filled with questions about clipping. Either you let it modify the volume anyway and deal with any clipping during playback or you leave certain tracks alone and end up with varying volume. mp3gain is, however, available for Linux (and maybe it'll compile for other Unices, too).
Using the RVA2 tag seems the better approach to me. I'd be interested to hear other people's experiences with it. I haven't found many good tools to deal with it, and keep meaning to roll my own scripts to use mp3gain for the analysis and drop the adjustment into the RVA2 tag. (Then I'd have to modify or wrap a command-line mp3 player to play them.) Ugh.
From: bwooce
Fri, 6-Aug-2004 3:40 AM (UTC)
Its all fucked. | (Link)
|
I went through this recently. Bluntly, Normalize was written by someone who didn't have an audio background. The code is fine, but to quote him: "Please note that I'm not a recording engineer or an electrical engineer, so my signal processing theory may be off. I'd be glad to hear from any signal processing wizards if I've made faulty assumptions regarding signal power, perceived volume, or any of that fun signal theory stuff." ReplayGain was designed by someone with a big heavy audio background, and uses an algorithm to measure "perceived loudness" rather than RMS. RMS would, at first look, be fine. I mean we're all computers here aren't we? We respond linearly to increasing stimuli? Alas our ears aren't built that way. Probably a good thing too. So the RVA2 tag was a nice idea, but the only known implementation (for setting the tag) produces audibly odd results. ReplayGain is a technically better solution. But the one, single, implementation sucks arse. And when I say there is only one implementation I'm right -- every fucking person/project that has "ReplayGain" support ripped it off and reused it...only some of the #DEFINE's are subtly different and some people changed the c++ comments to c comments. Grrrrrrr. The ReplayGain "standard" changed since the webpage was written, and the fecking ID3 tag format sucks ass (which the designer admits). He also changed the dB base to suit the LAME crew I think (see the MAD authors rant at http://www.mars.org/mailman/public/mad-dev/2004-February/000993.html ) I can understand why noones reimplemented the deep magic -- noone understands it. Googling for help on the math behind it wasn't a lot of help. I have no idea how the filter values were generated... Anway, whats not clear to me is if the RVA2 value could be used with ReplayGain. Both ReplayGain and RVA2 are applied as a constant value across the complete track, but I'm not sure the units are the same as the RVA2 tag. It would be ideal to combine the two. (mp3gain is available for linux - mp3gain.sf.net)
I have used mp3gain on linux and it compiled no problem with the included Makefile (on Fedora Core 2).
I wrote a tiny script for traversing through a directory tree and computing album gain (that is a consistant gain value for a whole album, so that volume changes within an album stay intact)
for all mp3 files found in all subfolders. This assumes a 1-to-1 relationship between directories and folder. Gain on a per track basis is computed at the same time as well.
If anyone is interested, I can post it or put it online someplace.
I'm facing the same thing (although on another platform). After all the semi-solutions discussed here, what did you end up doing? | |
