I have been following this with interest, but I would like to echo what the others are saying and suggest that changing the meaning of the existing ReplayGain tags would be a huge mistake. It breaks the (admittedly undocumented) ReplayGain specs and would instantly break all existing players and cause a lot of long-term confusion and frustration with users of ReplayGain (which is probably not what anyone wants).

If you want to have a different meaning to the tags thatís fine, but I think you should use different names in that case, like REPLAYGAIN_TRACK_GAIN_EBU, or something. What is the advantage of keeping the same tag names when the meaning has changed and the players will have to be modified to use them anyway? Players that want to take advantage of the new method can query the different names.

You could still have the --transitional option to write out compatible tags, but having the default behavior be to break existing players makes no sense to me. It would be sad if this new and better scanner/tagger got a bad reputation because of this oversight.

You could still have the --transitional option to write out compatible tags, but having the default behavior be to break existing players makes no sense to me. It would be sad if this new and better scanner/tagger got a bad reputation because of this oversight.

Just to give you another reason: The example above, Jethro Tull's "Budapest", taken from the original CD "Crest Of A Knafe" (no remaster), was not chosen by accident. The amplification and peak values are with respect to a pre-amp of 2 dB relative to -23 dBFS (EBU R128). If you consider a build-in "pre-amp" of 5 dB the play-back would be hopefully clipped by as much as 3 dB.

EBU R128 is completely different than traditional ReplayGain. The people should know what they are doing.

I think the "--transitional" mode is fine. You get exactly the same as what original ReplayGain delivers, just computed by a better loudness estimator.

But using the name "REPLAYGAIN_*" for new, incompatible R128 tags is really bad and would lead to a lot of confusion. This mode should not be the default! If at all, give it a "--babylon" switch, which is IMHO the most adequate description.

I'd vote for writing "--transitional" (or traditional) tags as default and add an additional set of "R128_TRACK_GAIN" etc. tags for players, which want to follow R128 to the last word (I don't really see any practical benefit in comparison to traditional RG).

Now my question: Is it possible to implement an option for tagging (FLAC) files without copying them?

Technically tagging only is the following anyway:

Read the original file and in parallel write a new file using a temporary name.

If writing of the temporary file appears to be successful remove the original file and rename the temporary file to the name of the original file.

The disadvatages of such an approach are:

If writing appears successful from the technical perspective but is not (e.g. the content of the file is broken) the original file is lost. Everybody using "original" files (e.g. payed MP3s) as input should think about twice using such an option.

If you are going to tag a huge amount of files the tool will have no idea where to continue after having it interrupted.

Propably the tool will offer such an option with the next release. But please don't blame me if something's going wrong and your original files are lost.

QUOTE (Surfi @ Jan 24 2011, 22:06)

Oh, and I get exactly the same results for --fast and --true-peak=off. Where's the difference of these two switches?

If you try this on contemporary over-compressed (hard limited) CDs you will observe inter-sample peaks up to 0.8 dBFS (which is impossible for sample peaks with a technical maximum of 0.0 dBFS).

Currently there is no difference between these two options. They're just synonyms.

FYI - I did a comparison of ReplayGain and R128 (based on the libebur128 code in the other thread) and found -17.25 LU to be a good reference loudness level for R128 to match the 89dB reference level of ReplayGain.

More specifically, regression analysis indicated that the gain adjustment should actually be -17.5 - 1.05*R128 (e.g. an R128 value of -10LU would correspond to -8.55dB gain adjustment), but I don't like the idea of having the beta coefficient not be 1.0.

I assume you both did the comparison in track mode and I am curious if the results are the same in album mode.

Duh, I see now looking at lvqcl graphic is that it contains both track and album mode so I assume the result is the averaging of the two. I am still curious what the results are when just comparing track or album mode.

Obviously I am not quite awake yet but now I see that lvqcl's result is based on track information. How does it compare to album and the averaging of the two?