ReplayGain not being applied consistently

[audioffile]

I noticed that some tracks on my player (Sansa e280) were distorting despite the fact that I have ReplayGain enabled and every track in my collection is scanned (at least for TrackGain (compilations), usually with AlbumGain too). So I did a little experimentation.

I set the Pre-amp in ReplayGain to something quite noticeable (-12dB) and scanned through my music collection. This made it easy to tell which tracks were getting ReplayGain and which were not. I found that maybe 30% of my tracks are not getting ReplayGain. Sometimes the issue is with an entire album, sometimes with just one or two tracks in an album.

I forced all my tags to id3v2 in foobar2k and then resynched. That did not help. I upgraded Rockbox to the latest release. Also didn't help.

[saratoga]

Do the correct values show up in rockbox under the properties menu? 

[bluebrother]

Do the correct values show up in rockbox under the properties menu? 

I don't think the properties show the replaygain values at all. The "Show Track Info" dialog from the wps context menu does.

[yapper]

The Spartan Black E200 theme displays the Replay Gain values (if you have Album Art you will need to turn Hold on to see the RG values). If it shows No Tag, then check your tagging. I use foobar200 for adding/updating Replay Gain.

[audioffile]

Do the correct values show up in rockbox under the properties menu? 

I don't think the properties show the replaygain values at all. The "Show Track Info" dialog from the wps context menu does.

When I try to open the "Show Track Info" dialog playback stops and the device freezes. The only thing I can do at that point is shut it down. I think I need a better way to check my memory than chkdsk, because chkdsk is not finding anything.

[evilnick]

That makes me wonder whether there are very large comment tags (or embedded album art) on those files, which might make the tag parser choke??

Just a possible suggestion.

[audioffile]

Update on chkdsk:

When run from the windows explorer GUI the check forces me to reboot and then I can scan. It finished phase 1, but fails on phase 2 with the following message:

Code: [Select]

---------------------------
Checking Disk Sansa e280 (S:)
---------------------------
Windows was unable to complete the disk check.
---------------------------
OK   
---------------------------

Does anyone know of a better way to check the memory (and repair it)?

That makes me wonder whether there are very large comment tags (or embedded album art) on those files, which might make the tag parser choke??

Just a possible suggestion.

Thanks evilnick. I have files that fail to play that have neither of the above.

[saratoga]

Format the disk and then recopy your files over to it.

[soap]

I have had trouble with foobar being told to write all tags to ID3v2.x, but not actually doing so.
It (foobar) would write new or edited tags to my chosen format,  but would not rewrite old ones which were unmodified.

I suspect you still have APE RG tags in the problematic files, and need to use another program to convert them over.

[yapper]

I haven't tried this personally, but on the version of foobar200 I have (v0.9.5.3) there is an option "Force preferred tag writing scheme on all files regardless of existing tags" which sounds as if it might do what you need.

[soap]

I haven't tried this personally, but on the version of foobar200 I have (v0.9.5.3) there is an option "Force preferred tag writing scheme on all files regardless of existing tags" which sounds as if it might do what you need.

Which is exactly the function (at least at 0.9.5.6) which does not do what its name implies.  You and I both made the same inference.  It only rewrites tags which get modified.

I banged my head over this for weeks, and eventually submitted a bug report against QTScrobbler, accusing it of failing to parse my UTF tags properly (for I knew damn well foobar had been instructed to unify all my tags to a unified UTF scheme) only to be embarrassed when it was demonstrated to me that every preexisting tag was exactly as it was before.

I talked to the foobar people in freenode, and was told that the behavior as I describe was intentional, it was not a bug.

That function means, even if you have X tags, foobar will write in your selected format when it writes changes.  With that option off it writes new/modified tags of the needed type to match the existing.

[audioffile]

Thanks soap, that's very interesting. I was using foobar exactly as you describe, with the option to force all tag writes to ID3v2. I have not reformatted yet (as suggested above), but I intend to do that anyway due to another issue.

I'll rewrite the tags first just to make sure I'm working on one issue at a time. What are you now using to rewrite your tags?

[soap]

I don't recall what program I used to fix that problem.
IIRC I used EasyTag on Linux.
I currently use foobar to write all my new tags, the issue was unifying all my old rips on ID3v2.4 UTF-8, sorry I don't recall 100%.

[saratoga]

With current versions of foobar you can high light files, right click, and choose "tagging -> tag types" and uncheck APEv2 while checking ID3v2.

[audio-i]

I'll rewrite the tags first just to make sure I'm working on one issue at a time. What are you now using to rewrite your tags?

For what's worth, with Mp3tag you can "export" the apev2 tags (or any other type really) and then "import" them back to ID3v2 etc.