ReplayGain value changes when tag is updated. Options

[x9b]

Hi. I have noticed that when I change tag in FLAC files the album gain changes.

First it looks like this:
http://img259.imageshack.us/img259/7473/fb2k1.png

And when tags are changes, it looks like this:
http://img443.imageshack.us/img443/8413/fb2k2.png

Album gain (db) 1.797479
vs
Album gain (db) 1.800000

Is it suppose to be like that or is it a bug?

[mjb2006]

What are you changing, and how?

[x9b]

With foobar2000.
If I change genre etc.

[Porcus]

Does this reverse if you revert your change and rescan? If not: have you looked at what happens if you do not alter anything, just rescan the album? You might have used a slightly different RG scanner previously?

[x9b]

If I rescan, it goes back to 1.797479, like it was first. Doesn't matter if I revert the changes, it always goes back to 1.797479 with rescan.
I have only used the ReplayGain scanner in foobar2000.

And if I change tag in 1 track, and want to manually edit ReplayGain information, it says <mutiple values>
http://img688.imageshack.us/img688/952/fb2k3.png

I think it happens only with FLAC files.

[Porcus]

So what you are saying is,
(1) it initially was 1.79something
(2) scan after changed tags, yields 1.80
(3) any subsequent scan – whatever is done in the meantime – and it goes back to 1.79something?

- Can you replicate this on this or any other album?

- Sure there wasn't any 10th track joining in when you did the 1.80 scan?

[lvqcl]

(1) perform RG scan and write it to tags.

(2) context menu -> ReplayGain -> Edit RG info: fb2k shows the gain as "-6.713373"

however, the real RG tag in the flac file is "replaygain_track_gain=-6.71 dB"

[trout]

(2) scan after changed tags

No, you don't have to scan again after editing tags for it to change.


I can confirm what lvqcl reported; the data in the file differs from the value shown in the editor.

btw, I'm seeing this behavior back in v1.1.11

[x9b]

So, it's maybe the "context menu -> ReplayGain -> Edit RG info" that are showing the wrong value?

Sorry, my english ain't the best and I'm not so good at these technical things.

[BenB]

It looks like a tag writing bug to me. You have the actual replaygain value and the rounded replaygain value (for display purposes). When you altered your file, foobar rewrote the rounded value to the tag instead of writing the actual value.

This post has been edited by BenB: Jul 11 2012, 17:06

[2Bdecided]

To the nearest 0.01dB is way more than good enough. I wonder if fb2k intentionally enforces this, or it's just a quirk?

Cheers,
David.

[db1989]

FWIW, I checked an official source: metaflac is stated as using the same tag-writing scheme as vorbisgain, which writes values accurate to two decimal places.

So, this might not be a bug, but there’s still the question of why it shows the more precise value (which in this case is hardly necessary, as David said) initially; is the ‘raw’ value computed by the scanner being cached, or is something else responsible?

[BenB]

Surely if this were not a bug, foobar would write the rounded replaygain value to the tag when scanned and not wait until unrelated tags are altered. That just seems odd. It's not a significant bug(?) in any case.

The thing I'm wondering about now is which value foobar actually employs when applying replaygain during playback: the more (unnecessarily) precise calculated value or the rounded value? It personally makes no difference; nevertheless, I'd like to know the answer.


(edited to clarify)

This post has been edited by BenB: Jul 11 2012, 18:44

[trout]

Surely if this were not a bug, foobar would write the rounded replaygain value to the tag when scanned [...]

It does. The unrounded value is only being shown by the "Edit RG Info" window.

[BenB]

No, it doesn't. The "Edit RG Info" window shows the actual value stored in the replaygain tag. What's shown elsewhere is the rounded value, and in the case of OP, foobar is overwriting the scanned value with the rounded value when he alters other tags.

This post has been edited by BenB: Jul 11 2012, 20:04

[lvqcl]

No, it doesn't. The "Edit RG Info" window shows the actual scanned value.

No, fb2k writes rounded value but caches (and shows) more precise gain value.

[BenB]

Hmmm, my replaygain tags aren't showing a rounded value. *scratches head*

I guess you've possibly and indirectly answered my earlier question. I assume foobar uses the non-rounded value when applying replaygain during playback; otherwise, it would be rather pointless to cache it.

EDIT:

Then again, it could still use the rounded value, but then the question becomes "why not just store the rounded value?".

This post has been edited by BenB: Jul 11 2012, 20:23

[trout]

The "Edit RG Info" window shows the actual scanned value.

But that is not what is written to the tag.

foobar is overwriting the scanned value with the rounded value

No. The unrounded value is never written to the tag.

The rounded value is written to the tag, in the actual file, from the start. The rounded value is also displayed correctly in the Properties dialog. The only place the unrounded value is found is in the editor. So apparently the editor is initially retrieving the value from internal memory / db, and updating only after tags are edited - or tag info is otherwise reloaded (exa. Context > Tagging > Reload info from file(s)).

[BenB]

I think it's safe to conclude this isn't a bug (or very insignificant if it is). Now I have to determine why I have unrounded values stored in some of my files. All of my files have been replaygain scanned using foobar (natively or through the preceding component before foobar's replaygain scanning was revised).