I was playing my first MPC file, and I noticed that the plugin for winamp comes with ReplayGain support built in. I have never used ReplayGain (i use mp3trim to prevent clipping), and I was wondering something...

Would it be possible to have the plugins that understand ReplayGain also calculate the values? For example, if I play the file all the way thru, the plugin could keep the peak it sees, etc, and then write it back to the file. That way, even if you don't have the ReplayGain program installed, you could benefit from its functions.

Of course, if the user seeks around the file or just does not play the whole thing, the data wouldnt be accurate. If only one file is played, the Radio gain could be set, and if a playlist is used (and all the Album entries in the tag are the same) then the Ablum gain could be set.

Anyway, just a thought. I was thinking the same thing about MP3s and other formats... the first time you play it there might be some clipping or other nasties, but after that, all the data can be written back and the second and future times the file would play perfectly.

One problem is that many plugin systems simply won't allow this. The plugin gets called to play a single file, and has no access to playlists or the like.

This is possible in Winamp3. I think it already works for Vorbis files and once tagging can be completed for MPC component I will add support in it.

LoKi128,

I reported this plugin back in the old forum. I did a search for it but I couldn't find it, I don't think the old forum has being transported here. Yes there is a plugin that have everything that you described, plus more. Best thing is that it support all formats, even evil formats like WMA .

http://www.xs4all.nl/~walterln/replaygain/

kyx: thanks for the link! I tried the plugin but for some reason it "detects" that i stopped playing every file while it's still playing, so it keeps discarding the data... dunno... kinda buggy.

anyway it is good that there are other people thinking about this, and that some of the plugins might have this already. I haven't moved to WA3 yet, but I imagine that someday I will.

thanks again to all!

Name is kxy

No, I dont think it is buggy, I being playing around with it since v0.2. Make sure you turn your crossfade off(if you use PP's DS, fade is on by default), or other plugin or presets that fade or alter the audio signal. It stops because it didn't scan the whole "song".

If you must have your crossfader and whatever on, you can always go to prefereces and check enable caluclation of replay gain and peak amplitude and check don't discard calculations. This way it will never discard any data. But keep in mind it will not be super accurate, becuase it will store the highest peak value even when your "song" is half way through when you decided to change to another "song".

Wouldn't it be more sensible to add the replaygain calculation and application to the ripping/encoding process? With EAC I can now rip, encode, tag and apply (album) replaygain for my CD's with a single click of a button. This requires a bit of tinkering with EAC's options and a bat-file but it is still possible. I managed to get this thing working with .ogg files and vorbisgain.exe and I really don't see why it wouldn't work with other formats as well.

I think it should be implemented in the encoder, of course. But that only works if you are encoding your music. I already have TONS of MP3s, and while I could just let the computer calculate all the gains overnight or something, I think this is more elegant, and would transparently do it for all the files you listen to.

That said, I am still not using ReplayGain for my mp3s. My car player (JVC SH-99) does not care about the ReplayGain stats, which is why I use mp3trim. I am interested in ReplayGain more for the future... when I have a "media" computer in my living room etc.

*Every* MP3 player handles replaygained MP3s, because MP3Gain directly modifies the "global gain" value of the files. No special support/plug-in is needed for replaygained MP3s (unlike with MPC and Ogg Vorbis).

And how to calculate the album gain then?! The encoder only sees one file - the file you currently encode
I thinks it's better to include the analysis in EAC and such

CiTay: ahh! I had only played around with RG in OGGs (was making OGMs a while back) and I thought it worked the same with MP3s... hmmm I'll have to switch now! hehe

Slo: It would happen over a period of time. If you select a playlist instead of a file to play, it will just store each file's gain, and when it detects that the whole album has been analyzed, it will save the album gain, if you so desire.

The system is not perfect, I'm just saying that if it were included in Winamp, Media Jukebox, etc... everyone would slowly start analyzing their music files, which at the end benefits us all. Including it in the encoders starts the process, and including it in all the players closes the loop.

kxy: You're right. XFade was messing it up. And sorry I messed your name up
/me double-checks twice so I dont do it again now.

@hhippo:



Yay! (w00t) Even if this may be a little off topic, could you post how you did that (i.e., contents of the batch file and such)?

Sure thing. The only problem with this approach is that the EAC pops up the encoding and replaygain windows (even with the "Do not open external compressor window" option enabled). Which of course is a bit of a nuisance but I can certainly live with it... Although I won't mind if someone finds a way to fix it.

Here are my configurations.

EAC:
====
EAC -> EAC Options -> Filename:
---
Naming scheme: %A\%C\%N - %T

EAC -> EAC Options -> Directories:
---
Use this directory (for extraction): C:\ogg\

EAC -> Compression options -> External Compression:
---
(x) Use external program for compression
Parameter passing scheme: user defined
Use file extension: .ogg
Program used for compression: C:\WINNT\system32\CMD.EXE
Additional cmd line options: /e:on /q /c C:\Progra~1\OggVor~1\encode.bat %h6%h %l3%l "%y" %n "%t" "%g" "%a" "%m" %d %s
(x) Delete WAV after compression
(x) High quality

A few notes... Use cmd.exe on NT/W2K/XP and command.com on W9X/ME. All path and file names should be in short format because extra quotes mess things up. The %h6%h and %l3%l define the vorbis quality levels for EAC's high and low quality options.

encode.bat:
=========
@echo off
C:\Progra~1\OggVor~1\oggenc.exe -q %1 -d %2 -N %3 -t %4 -l %5 -a %6 -G %7 --o %8 %9
cd c:\ogg
cd %6
cd %5
del %9
if exist *.wav goto end
C:\Progra~1\OggVor~1\vorbisgain.exe -a *.ogg
:end
echo x > %9
===
When EAC calls the encode.bat this is what happens:
First the CD gets ripped to the C:\ogg\artist\album directory. After the first track is extracted the bat file encodes the first file (for example "song1.wav"), deletes it and checks if there are any other WAVs left in the directory. If another WAV is found (there should be as EAC has continued the ripping), a mock "song1.wav" file is created to be deleted by EAC. If there aren't any left (all have been encoded) vorbisgain.exe is executed.

These ripping/encoding tools should really have an "run your favourite replaygain software with appropriate parameters after the encoding is finished" -option...

Well, yes... but a better solution would be to have the encoding programs calculate the replaygain themselves. LAME could have a --replaygain switch... ogg and mpc the same. It shouldnt be too hard... after all the replaygain software is open source, and who better to calculate the peaks etc than the software that is already doing the encoding?

For album gain the calculation _has_ to be done after all the files have been analysed. So even if the replaygain is implemented in the encoder itself, it still has to be run after all the files are encoded. A proper replaygain calculation in the encoder would propably require a new kind of processing for the WAV files. (i.e. a batch encoder that would have a list of the files and wait until all of them have been created and encoded). (Please excuse my english... I hope that I am making any sense? )

Possibility of ReplayGain in the MPC encoder, comment by Frank Klemm:

hhippo: yeah... album gain would be a bitch... maybe that part can be handled by the decoder/player, for example on first play, scan the files in the directory and if they all have the same album tag do it or something

CiTay: don't know what Mr. Klemm means by having the ReplayGain calcualtor accessing the phsycoparameters or whatever. I just think it would be nice if the normal, plain-jane version of replaygain was tacked onto the encoder. After each frame is encoded, it is then analyzed by the RG (just like if it were reading the file of the hdd) and the value stored. Then at the end of encoding, the RG tags get written out.

I mean, the deal with making RG pervasive (in all encoders and in all players, both for playback and calculating the parameters) is so that it is invisible to the user. That means that all new encodes will already have RG tags in them, and all old encodes will get them whenever they are played next. Making the user do a 2 step process (encode, then "analyze") is wasteful.

Of course, another solution would be just to include the RG calculators into programs like CDex...

Couldn't EAC or CDex add an option along the lines of "Run this command after extraction is complete:"? As long as the CDs are ripped into unique directories wouldn't have to worry about other files interfering with Album Gain. Seems like one of the more simple ways.

Side note: Lame 3.94 is computing replay gain value (radio gain) while encoding and storing it into the Lame tag.

It could also help if the replaygain calculation was adjusted so that it's linear. Then it would be easy enough to calculate the albumgain for a bunch of files from the track gain...

Could the replaygain model be adjusted like this without losing the intended behaviour (equal loudness)?

ErikS: you can convert dB to linear easily, but that still won't do the same as album gain.

In album gain, you rank all the "frames" from the whole album from quietest to loudest and take the loudness of the 95th percentile (e.g. if the album contained 100,000 frames, after sorting them by increasing loudness, you'd take the loudness of the 95,000th frame). That's not the same thing as averaging the track gains (which are each the 95th percentile of all the instantaneous frame loudness values of the track they correspond to)