Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: ReplayGain value changes when tag is updated. (Read 3299 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

ReplayGain value changes when tag is updated.

Reply #1 –
What are you changing, and how?

ReplayGain value changes when tag is updated.

Reply #2 –
With foobar2000.
If I change genre etc.

ReplayGain value changes when tag is updated.

Reply #3 –
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?

ReplayGain value changes when tag is updated.

Reply #4 –
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.

ReplayGain value changes when tag is updated.

Reply #5 –
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?

ReplayGain value changes when tag is updated.

Reply #6 –
(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"

ReplayGain value changes when tag is updated.

Reply #7 –
Quote from: Porcus on
(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

 

ReplayGain value changes when tag is updated.

Reply #8 –
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. 

ReplayGain value changes when tag is updated.

Reply #9 –
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.

ReplayGain value changes when tag is updated.

Reply #10 –
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.

ReplayGain value changes when tag is updated.

Reply #11 –
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?

ReplayGain value changes when tag is updated.

Reply #12 –
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)

ReplayGain value changes when tag is updated.

Reply #13 –
Quote from: BenB on
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.

ReplayGain value changes when tag is updated.

Reply #14 –
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.

ReplayGain value changes when tag is updated.

Reply #15 –
Quote
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.

ReplayGain value changes when tag is updated.

Reply #16 –
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?".

ReplayGain value changes when tag is updated.

Reply #17 –
Quote
The "Edit RG Info" window shows the actual scanned value.

But that is not what is written to the tag.

Quote
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)).

ReplayGain value changes when tag is updated.

Reply #18 –
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).