ReplayGain in Play

[Maurits]

I've spun this off from this topic.

I've just posted r722 which changes a few things:

I've added preliminary replay gain support. It is preliminary because while the gains are read from files and implemented in the player, they are not settable. At some point in the future they will be but I just wanted to add the fields to the database now.

Great! Are you using ID3's RVA2 tag or Lame's built-in RG data? I believe the common way is to first try to read RVA2 tags and revert to Lame's as a fallback when the RVA2 tag is not available.
I'm not sure what you mean by 'setting' though? Users are not supposed to set the values themselves. They are (by the standard) all relative to the same dB level. The values in the files should be detected by an algorithm (like this one for instance) and if final playback is too loud or to soft then the amount of applied pre-amp (which is a player wide setting and not an individual file setting) has to be changed.

A lot of users actually don't understand the workings of RG and would like to edit the files by hand themselves if they think they are too soft or too loud. But, messing with the RG values in the files usually messes playback up big-time. Think distortion and clipping. Furthermore, playing these same files in other players with different decoders and pre-amp settings will screw it up again.

Winamp has done this very nice. The RG values are non-editable metadata in the UI's 'info' field. They have a built-in scan mechanism to scan files for the right value and they have a slider to set the amount of pre-amp. This way users only have influence on things they should have and can't mess up.

As an extra, you may want to consider using possible present iTunes normalisation ("Sound Check") data. Especially on OS X a lot of users might already have this info in their files. It's just there for the taking. There is some info here on how to turn existing ITUNNORM data into RVA2 data which you can then write in the RVA2 field.

[sbooth]

For MP3 files I'm grabbing the RG data from the LAME header. Right now the RVA2 frame isn't checked, but it would be trivial to add code that does this.

I agree that the Track (radio) gain should not be user adjustable. However, from my (limited) reading on the subject it seems that the Album (audiphile) gain should be tweakable by the user.

In any case, in the future I envision being able to select multiple tracks, and in the context menu having a Replay Gain menu item, which would then scan them for individual track gains, or as a group for album gain.

Right now the way the gain in implemented internally isn't optimal, but once I switch over to a slightly different architecture (which will allow for effects and other things) there will be a settable pre-amp setting.

Good idea on the SoundCheck, I will grab that too.

[Maurits]

Good. Just as for Sound Check, it won't hurt using RVA2 as well. Often the data is there already.

A number of popular Linux and Windows applications use the RVA2 field to store this data. Especially switchers might have libraries full of files with these values scanned and stored already. That's why RVA2 is often checked first with Lame just as fallback. I think a lot of devs are reluctant to overwrite the Lame header and prefer an ID3 tag as it has less potential to wreck a file.

[Maurits]

I've been playing around with all different ways of storing RG values. Can you confirm that MP3's made by Max do not store these Lame-RG values? I can see them in Play in files made from a Lame command-line, not in MP3's made with Max.

Do you see this as well? Should Max be forced to add these Lame values? Or write RVA2 by default? Or both?

[Maurits]

OK, I did some further digging into ReplayGain tagging standards and it's quite a mess actually.

RVA2 in ID3v.4 is superior over RVAD in ID3v2.3. Because some apps like the power of RVA2 but still use ID3v2.3 they revert to using RVA2-style data in RVAD tags. Not pretty, but it works. You might consider checking RVAD tags and use that after a sanity check to see whether they contain RVA2-style data.

Nicer is the way Foobar, Winamp and Rockbox (among others) handle it. They write:

TXXX replaygain_album_gain -x.x dB
TXXX replaygain_album_peak x.xxxxxx
TXXX replaygain_track_gain -x.xx dB
TXXX replaygain_track_peak x.xxxxxx

in the ID3 tag. That way you can store all four relevant values without having to choose between track or album gain. If one of the values is unknown (often Album) you can omit that one. For users coming from Windows this might be the most used method out there.

For users coming from Linux I've got the impression RVA2 is prevalent.

When you decide to start writing these values to the tags, I'd suggest writing both RVA2 and the TXXX's.

[Maurits]

I've been playing with ReplayGain in r812 a bit and it looks good! A few comments:

* Scanning is rather slow. It seems to be a lot slower than iTunes for instance. Any ideas what could be the cause?

* Have you thought about having an option for a low-priority background/idle-time RG scan? As long as you just store the values in the DB (and not rewrite metadata without the users consent) it would be nice to have.

* It may be wise to consider the reading/writing of TXXX frames for ReplayGain metadata as well. Apps for power users on Windows like Foobar and Winamp use this rather neat solution. Power users on Windows are very likely to use Foobar or Winamp and have large collections of files with these frames already populated. Considering power users that switch to OS X from Windows or that share one music collection for playback from both OS X and Windows are very likely to end up using Play (as opposed to iTunes) it seems to me a handy feature.

[Milkmaster]

* It may be wise to consider the reading/writing of TXXX frames for ReplayGain metadata as well. Apps for power users on Windows like Foobar and Winamp use this rather neat solution. Power users on Windows are very likely to use Foobar or Winamp and have large collections of files with these frames already populated. Considering power users that switch to OS X from Windows or that share one music collection for playback from both OS X and Windows are very likely to end up using Play (as opposed to iTunes) it seems to me a handy feature.

Second that. Exactly what I'd have said.

[sbooth]

I've just added reading and writing of TXXX frames for ReplayGain- I'll post a new unstable later tonight or tomorrow.

I agree the RG scanner is a bit slow- I will do some code profiling and see if I can speed it up.

[Milkmaster]

Thanks!

Would it be possible to have the "progress bar" really display a progress? It's quite useless if it's just an animation that looks like a progress bar.

[Maurits]

Thanks!

Would it be possible to have the "progress bar" really display a progress? It's quite useless if it's just an animation that looks like a progress bar.

On a single file basis I can imagine this being near-impossible or slowing down the process even further.

On a multi-file job it might be useful, though. The progress indicator would be split into n 'parts' where n is the number of files in the job. That way the progress indicator will only have to be updated after each subsequent analysis. Less intensive and still really practical for where the progress info is really useful, those longer jobs.

[Milkmaster]

I've just added reading and writing of TXXX frames for ReplayGain- I'll post a new unstable later tonight or tomorrow.

I agree the RG scanner is a bit slow- I will do some code profiling and see if I can speed it up.

Was r820 supposed to be the build including this, because it's not showing the values for my files with TXXX rg info? If not, disregard this post.

[sbooth]

I've just added reading and writing of TXXX frames for ReplayGain- I'll post a new unstable later tonight or tomorrow.

Was r820 supposed to be the build including this, because it's not showing the values for my files with TXXX rg info? If not, disregard this post.

Yes, it was! Can you send me an MP3 with the frames for testing?

[sbooth]

Was r820 supposed to be the build including this, because it's not showing the values for my files with TXXX rg info? If not, disregard this post.

The problem was that foobar saved the TXXX frames as "replaygain_track_peak", i.e. all lower case. Play was looking for upper case. I've changed the code to look for both, but mixed case tags will not be recognized.

[Maurits]

Was r820 supposed to be the build including this, because it's not showing the values for my files with TXXX rg info? If not, disregard this post.

The problem was that foobar saved the TXXX frames as "replaygain_track_peak", i.e. all lower case. Play was looking for upper case. I've changed the code to look for both, but mixed case tags will not be recognized.

Considering both Winamp and Foobar (and possibly others) write these tags in lowercase, I think it would be wise to read both cases but write only lowercase (Play 0.1.2 writes uppercase).

Just for the sake of interoperability, who knows how picky others apps can be?

I'll give 0.1.2's RG features some attention in the next few days. Been out of the country so didn't have the time last week to test the builds.

[Maurits]

Oops! It appears that among these case sensitive apps is Winamp, not the least player out there. It writes lowercase RG tags and will not read uppercase ones.

Furthermore, topics like this one suggest it's not only MP3 or Winamp that suffer from it.

The safest way seems to be to indeed read both cases but write lowercase.