Replay Gain: A how to informational

Hi everybody, I registered because my own Clip+ is behaving the same way with replaygain_*_gain tags that have the “+9.99” format.  I hope this is helpful and that the people at Sandisk might see it.  Anyway, I can confirm:

  1. that replaygain_*_gain tags in the “+9.99” format cause the player to read incorrect values (eg, “+9.99” yields “-40.01” )

  2. that deleting the leading “+” (eg, “9.99” ) causes the player to read a very large value > 2000,

  3. that replacing the leading “+” with a " " (eg, " 9.99" ) causes the player to read the correct value,

AND 3) that adding a leading zero (eg, “+09.99” or “09.99” ) will also cause the player to read the correct value.

Almost forgot.  This all applies only to ID3 tags.  OGG is okay.  Haven’t tried FLAC.

Message Edited by DCMC on 12-20-2009 07:51 PM

Message Edited by DCMC on 12-20-2009 07:57 PM

Just thought I’d chime in with an update. I’ve been in contact with Sandisk customer service over this Replaygain problem, and after trying some of their suggestions to update firmware, reset & format, we’ve come to the conclusion that there is something wrong with my Clip+. Instead of sending it back to Sandisk, I decided to return the player back to the store I bought it from since it was still inside the 30-day return policy.

After charging the new unit, and adding some songs, once again Replaygain simply does not work properly. In either song or album mode, a few songs will play fine, and then the player will just freeze when a new track is to begin. You cannot skip to the next or previous track either. If i reboot, a few songs will play fine and then it freezes again. This happens on songs that are on both the internal memory and my SD micro card. My files are a mix of MP3’s and WMA’s, and i would guess that wouldn’t be the problem since the Clip+ accepts both type of files. When Replaygain is in off mode, everything works fine.

Sandisk says that there is no problem in their opinion with Replaygain on the Clip+, but in my experience I would beg to differ. Could it be that the problem is with Media Monkey? Hopefully there will be a fix soon.

Message Edited by bloozjr on 12-23-2009 12:55 PM

I am not persuaded that the Clip+ is at fault for the ReplayGain issues I have seen posted. The only issue I have experienced (and have read a few other posts with similar problems) is with specific programs (Foobar2000) and the format that is used to write the ReplayGain values, and once understood, this issue is trivial to correct.

@bloozjr: The fact that your second Clip+ has the same problems suggests to me there is a problem with your tags, or at least the way the Clip+ reads them. Is there a particular file that causes the freeze, or file type? I would try to isolate the problem, if possible, and would create a test folder, with a few mp3’s, and see if they play through properly, another folder for wma files and see if they play, then another folder to mix them. Perhaps use MP3Tag to check the tags and make sure they do not have any unusual entries.

Thanks andied I’ll try what you recommended. However, after reading the problems that the Fuze had with Replaygain, I suspect the Clip+ has the same problem. At least the ones I buy do:)

Thanks andied I’ll try what you recommended. However, after reading the problems that the Fuze had with Replaygain, I suspect the Clip+ does as well. At least the ones I buy do:)

Yet further reason why I like MP3Gain–works every time!

@miikerman wrote:
Yet further reason why I like MP3Gain–works every time!

How do you get MP3Gain to work. I tried it and first of all it writes Ape tags which the Clip+ doesn’t read properly (if at all), and secondly it does the same as Foobar2000 on positive values, and writes a “+” at the beginning of the ReplayGain value, and the Clip+ subtracts 50 from this value, so a RG value of +2.0 becomes -48.  What am I missing?

Sorry, I’m not following you–are you talking about MP3Gain?  Or ReplayGain?  I was referring to MP3Gain …

I am referring to using MP3Gain to set the replaygain values. MP3Gain uses Apev2 tags and I do not see how to change it. MP3Gain also writes a plus (+) sign at the beginning of the replaygain value ,if it is a positive value, and the Clip+ doesn’t know how to handle it.

Merry Christmas :stuck_out_tongue:

The problem with MP3Gain is, it does not work via tags but modifies the file directly. The tags are only a backup information to be able to restore the original file. And it only works on MP3 files, as the name suggests.

I have a slightly different problem with my clip+ and replay gain. The replaygain values are listed correctly in both foobar2k and clip+, but there is no change in volume when switching between the off/song/album modes and the files with replay gain tags are clearly louder than files that had the replaygain applied to the data (lossy). 

Before someone says it’s foobar’s fault, the replaygain values were done with the official encoder (1.2.1b) via the --replay-gain switch.

If the clip+ has problems reading those tags it simply means replay gain is not implemented correctly.

And what’s more interesting, i went and installed mediamonkey and scanned the same track with foobar, official and mediamonkey. My results:

The only difference between foobar replay gain tags and official tags is one additional tag namely REPLAYGAIN_REFERENCE_LOUDNESS, which is set to 89.0dB per default (and the fact i scanned in track mode while the official encoder scans in album mode). Everything else is the same.

All 3 files’ replay gain tracks are recognized by the clip+ correctly

All 3 files sound louder than my mp3 version of the same song (which has the track gain applied) in off/song/album mode

With all 3 files, there is no volume difference between off/song/album mode

My clip+ firmware is V01.01.05F (don’t know if it’s the newest, the updater doesn’t like me (click me) (win7 x64))

foobar:

foobar tags

official tags:

  official tags

Now, let’s see how MM tags look like:

  media monkey tags

After comparing the tags, you can clearly see which program behaves incorrectly - MediaMonkey, not foobar.

Now let’s assume MediaMonkey’s replay gain tags do work and i’m an exception.

This means that to be able to use the whole potential of my player, i am forced to use a specific program. That was initially one of the reasons i decided against buying an apple product, but now i am being told there is no other way (at least atm) around it again - not good.

andied wrote:
I am referring to using MP3Gain to set the replaygain values. MP3Gain uses Apev2 tags and I do not see how to change it. MP3Gain also writes a plus (+) sign at the beginning of the replaygain value ,if it is a positive value, and the Clip+ doesn’t know how to handle it.

MP3Gain works directly on the files run through it and alters the gain in them (which can be reversed or otherwise modified, simply by running MP3Gain on the songs/files again), and so does not rely on software on individual players themselves (including the Clip and Clip+).  That’s the nice universality of it. 

After further testing and getting to know the idiosyncrasies of MP3Gain, I can get it to work with the Clip+.

Loading files and clicking “track Analysis” will immediately (actually 3x slower than Foobar2000) analyze and write volume gains to the file(s). If left at this point, and the volume value is positive, the tag begins with a “+” (+0.17), which the Clip+ reads as “-48.83” - much too low to be useable. However if “Track Gain” is selected, MP3Gain writes info to the file and the Clip+ will play the song with proper volume, although the Clip+ cannot read the replaygain info - I assume because it is Apev2.

It is good to have choices - I will stick with Foobar2000

edit: should be:  “although the Clip+ cannot display the replaygain info”

Message Edited by andied on 12-25-2009 12:47 PM

@Soukyuu

I have found that changing the ReplayGain setting in the Clip+ (song/album/off) does take effect until I return to the music list and re-start the song - obviously difficult to hear a difference when the replaygain value maybe less than +/- 1 db. I manually altered the RG value by 10db and could definitely hear the difference between RG on or off.

I guess my mistake was to assume i could change between modes on-the-fly.

All 4 test files  seem to sound the same now…

So i guess the only question now is, how the official encoder handles the positive gain vs. foobar vs. MM… i’m going to do some tests later.

For your consideration.

a) Replaygain (probably!) is exclusively known, used and understood by foobar2000 folks. Honestly, I don’t think it is widely used outside the fb2k/hydrogenaudio.org world.
b) It shouldn’t be rocket science for the Clip+ to interpret " " or “+” the same way.

Thanks in advance

andied wrote:

After further testing and getting to know the idiosyncrasies of MP3Gain, I can get it to work with the Clip+.

 

Loading files and clicking “track Analysis” will immediately (actually 3x slower than Foobar2000) analyze and write volume gains to the file(s). If left at this point, and the volume value is positive, the tag begins with a “+” (+0.17), which the Clip+ reads as “-48.83” - much too low to be useable. However if “Track Gain” is selected, MP3Gain writes info to the file and the Clip+ will play the song with proper volume, although the Clip+ cannot read the replaygain info - I assume because it is Apev2.

 

It is good to have choices - I will stick with Foobar2000

 

edit: should be:  “although the Clip+ cannot display the replaygain info”

Message Edited by andied on 12-25-2009 12:47 PM

If you use MP3Gain on your files, then you should disable the ReplayGain on the Sansa, as it will no longer be needed. That’s the whole point of why Miikerman brought it up, I believe.

If you use MP3Gain on your files, then you should disable the ReplayGain on the Sansa, as it will no longer be needed. That’s the whole point of why Miikerman brought it up, I believe.

Actually you should probably still use the Replaygain values on the Sansa. mp3gain is only capable of making changes in 1.5dB increments. It will adjust the gain losslessly by modifying the mp3 headers. Unfortunately it stores modification information in APE tags. To get the most benefit out of the RG “experience” you would want to rescan the mp3gain-modified files with foobar2000 or Media Monkey to get the difference mp3gain could not account for.

Clear as mud? :smiley:

One other thing. foobar2000 is capable of modifying the mp3 headers just as mp3gain does. However, there is no undo after you apply the gain changes. foobar2000 then modifies the RG tags to reflect the difference.

As someone mentioned earlier mp3gain is agonizingly slow. foobar2000 appears to be able to take advantage of multi-core CPUs during its scan process. I’ve incorporated some Powershell scripts I created to apply the RG values created by foobar2000 to the tags that mp3gain uses. The scripts then call mp3gain to apply the changes and subsequently updates the foobar2000 RG tags. Whew!

FYI: The latest available version of mp3gain (1.5.1) has an option to use id3 tags instead of APE. It doesn’t use TXXX frames though. It uses RVA2 (Relative Volume Adjustment) frames. In truth this is probably the truly “correct” way of implementing volume adjustment.

I’ll shut up for now.

I’m so glad I have a player that takes care of it for me, rather than go through all this hassle with ReplayGain, MP3Gain, etc…:smileyvery-happy:

With all the back and forth RE ReplayGain, it probably does seem a bit obtuse, but really it is quite simple (once the problem was isolated). Foobar2000 does a really good job of writing replaygain tags (and very fast); the only issue is that the Clip+ doesn’t read a positive “+” value correctly, but the “fix” is trivial and hopefully Sansa will include this “fix” in a firmware update.