There's a program called mp3gain that analyses your MP3s and then adjusts the volume accordingly (and claims to munge the MP3 data in a non-lossy and reversible way.)
There's also apparently a "Relative Volume Adjustment" (RVA2) field in ID3v2 tags as a way of indicating that an MP3 file should have its volume increased at playback-time. There is a "normalize" plugin for xmms that claims to obey this.
So, questions.
- Have any of you used "mp3gain" or the "normalize" plugin?
- Is it a sensible and non-terrifying thing to apply either/both of these en masse to 18,000 MP3 files? Or does it require manual intervention, listening, and tweaking on a per-song or per-album basis?
- mp3gain looks to be Windows/DOS software. Does it work in emulation under Linux?
- Adding the RVA2 tag seems like a safer thing to do than modifying the MP3 data. Does it work as well?
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.
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.
Use ReplayGain instead. It just adds ReplayGain data to the header, and your replaygain compatible MP3 player will adjust the volume accordingly.
You don't want to go changing the audio data in your mp3s.
OR: If you're using Windows/Mac, you could get a plugin to allow you to use VSTs, and run everything through a compressor/expander. :)
Or just use a compressor like Tomsteady which is a wonamp plugin. But he's linux-only.
mp3gain /is/ replaygain
well, if it checks average volume, but doesn't compress it, particularly high volume points in the song are gonna distort, completely screwing your mp3s.
normalize sounds better, but i'm guessing it does peak rather than average. it's sorta one of those "it's gonna be peak unless explicitly specified otherwise" deals, generally.
mp3gain checks neither the average nor the peak, but the 95th percentile; according to the author this gives the closest map to how loud a track or an album is.
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*
I agree the ipod totally sucks at this. It's the one thing I hate...sooo irritating.
So the individual song>get info>volume adjustment works poorly and also the Preferences>sound check option sucks even more. I was initially excited to see that you could adjust individual song volumns only to be disappointed by the results. grr
Though I'd also say that itunes for mac is better at ripping songs at a consistant level than ezripper (think that's what it's called) on pc.
This is why ReplayGain defines two gain settings. One is per track, the other intended to be caculated album wide. Evidentally, the Apple engineers are from the big pile of music on suffle school of playlist design.
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:
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
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.
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.
Dunno... if you're a purist, why are you using a *lossy* compression anyways? Use flac.
And to be on-topic, I've tried out normalize, seemed to work well. Haven't actually let it run rampant on my collection yet (which is a mix of mp3, ogg, and flac), but I've been considering it a lot lately.
I use flac with all CDs that I don't own and for vinyl. For all of the stuff that I own, I simply use --alt-preset extreme vbr mp3 when I rip. I use ogg only when streaming...I'm not particularly bandwidth empowered in the upload department, and ogg at ~70kbps sounds a hell of a lot better at mp3 at even 96kbps.
Not in this instance. mp3gain operates directly on the MP3 data to losslessly modify the volume. So long as you don't hit the bounds of how loud a track can be made, you can reverse the transformation and get exactly the same stream of MP3 data back - all you need is a record of the boost or attenuation mp3gain applied to the track.
...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.
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.org
alternative installer and various plugins
Wine? For mp3 listening? Isn't that just a whole lot of pain that could have been avoided by buying a cd player at Walgreen's?
Your strange, martian folkways fascinate me.
Whole lot of pain is exactly what i feel regarding current state of native audio players for linux.
Normalize works as advertised.
This means that using the
--id3-compatoption 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-unsynclets 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-compatoption. 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-compatmunged 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.
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.
</lj-raw>
Okay, this is so not the place for this, and Jamie will probably flame me, but....
I assume this is a dig at ID3v2. First, no matter how good the technology may be, until the Vorbis folks have a decent list of standard fields, interoperability is for shit. (The only list of standard fields I can find is sorely lacking. Tell me if I'm just not looking in the right place.) ID3v2 already has a field for most everything you can think of. Not completely everything, I'm sure, but most.
Second, making up arbitrarily named fields is not good. If you and Joe Blow both use the same field name for different purposes, or, more likely, the same purpose with different encodings, that's big lossage. And since the vorbiscomment spec leaves so many gaps in its standard fields, you have to end up rolling your own all the time for even very basic things.
Third, ID3v2 does allow for user-defined fields. The field key in ID3v2 is a four-character string, where "character" is A-Z,0-9. It explicity states that any field key starting with X, Y, or Z is reserved for local definitions, so that gives you only (3 · 363) = 139968 fields to play with.
In short, I'm tired of digs at ID3v2. It's not as if it's perfect, but it's far better than anything else I've seen. In all honesty, if the Vorbis folks would define a good number of standard fields, I'd reverse my position. Then again, MP3s would still need to use ID3v2 or deal with reencoding Vorbis comments in order to deal with backwards compatibility with old players, something that ID3v2 has already done quite well.
Also please note that this is not intended to have any bearing on the merits or drawbacks of either audio encoding system. I'm speaking only of the metadata encapsulation.
It's a dig at both. id3v1 was a "30 characters for the title ought to be good enough for everyone" hack that should have never left the author's harddrive, while id3v2 is a massively overengineered monstrosity that is so hard to implement that even the author of the reference parser gave up.
I have no idea why people think some sort vast, comprehensive list of tags will make interoperability work, and that people making up their own tags will cause chaos and anarchy. Practically anything that you pull off a p2p network right now is sure to have nothing but the bare minimum of tags, with varying amounts of truncation, artist/album swapage and outright lies. And that's just the stuff tagged from CDDB. No technical hack will make this better.
Meanwhile, all the mp3s I carefully tagged with the reference command line tools don't parse when using XMMS. So much for interoperability.
The fact is that replaygain Just Works against vorbis files, and it's done so for over two years, largely because it was trivial to just add the tags necessary to do so. mp3gain still munges the file and saves a revert value in a completely different tag format to id3v2.
No doubt. ID3v1 doesn't require a dig. Saying that it was poorly designed is like saying that Ewoks were probably a marketing-driven creation.
Let me put it this way: If there is a definitive way for replaygain data, for example, to accompany an mp3 file, then it is more likely for people to implement it. This, of course, does not mean that it won't work if there's not an accepted standard, but it'll only work for the small group amongst which the manner of inclusion is well known. Personally, I think that it makes sense for you to be able to choose which audio player you'd like to use and have the notion that any modern one you do choose is likely to include support for replaygain. Today, that's not the case.
With any interoperability standard, it's important to have well-known information. That isn't to say that you can't choose to ignore it when helpful, but the more information you have, the better the interoperability will be.
I'm not going to touch the p2p networks thing, although there are certain technical hacks that could made CDDB/FreeDB better.
And I have no response to your XMMS/ID3v2 woes. It's never happened to me.
That's super, but I'd argue that the reason it does is because a large percentage of the people writing Vorbis players know about replaygain and how to access its data. Because it's a standard -- a de facto standard, perhaps, but a standard nonetheless. However, I bet that if it was included in the ID3v2 standard list of frames that it would get more attention by mp3 player developers and become more widely implemented, which could hardly be considered a bad thing. As it is, the chances of you being able to use replaygain settings on a portable mp3 player are pretty slim.
Are we avoiding the term RMS for any reason?
Yes. Cooperation with RMS is impossible.. See also http://www.livejournal.com/users/jwz/247973.html.
MC RMS bustin' out the phat shiznit yo!
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!
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.
Replaygain doesn't apply peak limiting. It calculates a gain value. If you were a total purist, you could write software that took this gain value and applied it using a robot arm to turn the volume knob.
If the volume knob is constant over the entire track, then I fail to see the benefit other than making the louder peaks almost unlistenable. Performing a raw gain on an already-normalized track is aural suicide.
Unless I'm misreading http://replaygain.hydrogenaudio.org//calculating_rg.html however, it looks to me like the software is evaluating the waveform in 50ms chunks, which says to me peak limiting since it's applying a gain without clipping.
The benefit arises from the reference volume being 83dB, leaving 20dB worth of headroom for the peaks. Plenty, as it turns out, as orchestral music and soundtracks tend to sit around 0dB to +2-3dB, while mid 80's stuff is about +1dB, early 90's is about -3dB and recent hard, heavy and compressed stuff is up to -12dB. The upshot is that it becomes more obvious that older music with little compression sounds punchy and exicting, while newer, more heavily compressed music sounds lifeless by comparison (though not in all cases).
It's also worth noting that the some replaygain implementations also cache a greatest scale factor before clipping, so that the player can opt to place a ceiling on the applied gain, or introduce peak limiting, in order to avoid damaging speakers.
In practice, this tends to only happen if you raise the preamp value up in addition to applying the replaygain. (Honestly — I've tested it while hacking on the plugin side.).
The 50ms block thing is to generate a set of average RMS values, rather than just one RMS value, as taking an RMS value at the 95th percentile of the set gives a more accurate assessment of the apparent loudness of the track.
"It's also worth noting that the some replaygain implementations also cache a greatest scale factor before clipping, so that the player can opt to place a ceiling on the applied gain, or introduce peak limiting, in order to avoid damaging speakers."
The mind boggles - placing that sort of burden on the player. I am reminded of a few "back in my day" conversations that are too long and too boring to retell here. What's next, selective content editing?
Suffice it to say: jwz, have you perhaps tried recompiling your kernel? I heard from my friend's buddy, who is a real computer hacker, that doing so will fix all sorts of problems.
Primitive peak limiting primarily exists as a means of preventing the plugin author from being deluged by angry emails from arseclowns who ramp the premap component up to +12dB and then complain when their tweeters blow. It shouldn't be triggered in normal operation.
If we lived in happyland, where the audio industry uses the same reference volume to calibrate CD mastering so we don't have to keep changing the volume between disks and tracks, there would be no problem. But we don't, and given the amount of Sir Arthur Conan Blowhards at the mixing desk, I have no problem trumping their overall mix level if it means I don't have to keep adjusting the volume between every song or album.
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.
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)
> ReplayGain is a technically better solution. But the one,
> single, implementation sucks arse.
Hmm. The fact that there is only one implementation out there seems like a good thing to me. I want different programs to use the same criteria to normalize songs. However, of course I also want those criteria to be good.
Could you maybe elaborate a bit about whats so sucky about the replaygain implementation?
> Could you maybe elaborate a bit about whats so
> sucky about the replaygain implementation?
There is only nominally one implementation, and codewise I'm not upset about it. Comparing the LAME vs mp3gain implementations, one magic value is different.
I think this is related to the fact that over time the "standard" dB has mutated without changing anything that an external program can check. Howver this magic number doesn't correspond to either value, so I'm not sure how it influences things.
In general terms though, I'm not sure that relying on one implementation of a mathematical modelling process is ever a good idea. Can you persuade me that everyone thats taken this code understood it enough to peer review? Strike that, *anyone* who took the code?
mp3gain doesn't just write tags, it modifies the mp3 frames somewhat destructively, and adds APE tags so it can reverse it. This is rather backward. The code difference between the LAME implementation and the mp3gain implementation means they don't play together properly.
I did start out trying to make mp3gain write tags in the LAME format, which (from memory) isn't the format on the replaygain website, but it was just all so fucked up.
It does seem like the RVA2 tag (supported by about 1 player) could be used as the carrier for a grand unifying replaygain/RVA2 processing program, but I can't reconcile the two different levels involved. Emails to the original author were not responded to (and I was nice :-)
>In general terms though, I'm not sure that relying on one
>implementation of a mathematical modelling process is ever a
>good idea. Can you persuade me that everyone thats taken this
>code understood it enough to peer review? Strike that, *anyone*
>who took the code?
Nope. But well, as long as the code actually does what its supposed to do in that it produces good results, what gives?
I mean of course, it would be better to have theoretic proof that it will in all circumstances do "the right thing".
But if it generally produces results that sound well normalized to me and other people, then thats good enough for me.
> mp3gain doesn't just write tags, it modifies the mp3 frames
> somewhat destructively, and adds APE tags so it can reverse
> it. This is rather backward.
Well, there is no destruction going on. It just saves a gain value in the mp3 frames. Which has the benefit that it works on all mp3 players without special replaygain support and using the info in the APE tags, it can be completely undone.
The APE thing is weird. I would prefer it used ID3v2. I asked the author why he chose APE. His answer was that at the time he heard lots of horror stories about ID3v2 problems.
> The code difference between the
> LAME implementation and the mp3gain implementation means
> they don't play together properly.
There is also the foobar2000 implementation, which is different again (I think?).
Yeah, its pretty messy. Hope it gets somehow more standardized at some point.
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 meant a 1-to-1 relationship between directories and _albums_, of course.
I'm facing the same thing (although on another platform). After all the semi-solutions discussed here, what did you end up doing?
Nothing.