qaac icon indicating copy to clipboard operation
qaac copied to clipboard

Option to suppress ignoring of ReplayGain tags

Open paolorodriguez opened this issue 7 years ago • 8 comments

Hello

I understand the current behaviour of qaac is to ignore any ReplayGain tags (even if it is specified manually in the command-line), and the rationale provided is that the values may change post-transcoding.

I would like to request to add a command-line option --no-ignore-replaygain-tags to suppress this behaviour. Specifying this option will cause qaac to copy any existing ReplayGain tags in the source file, or apply them if specified in the command line, thus following the behaviour for other tags.

paolorodriguez avatar Sep 17 '17 22:09 paolorodriguez

Hi,

the rationale provided is that the values may change post-transcoding.

Yes. Actually, difference in gain value should usually be tiny, so value in the source file can indeed be useful. However, difference in peak value (from lossless source) can usually be quite large and is not negligible. Since spec (http://wiki.hydrogenaud.io/index.php?title=ReplayGain_specification#Metadata) says that all of the four replay gain tags are must, we cannot do just copying gain tags and discarding peak tags. Therefore, I'm reluctant to allow copying them knowing that peak values are quite false.

nu774 avatar Sep 18 '17 14:09 nu774

Thank you --- fully understand where you're coming from

Given that the change in the peak values are mostly (if not wholly) from the artifacts introduced by the encoding process, and that (or at least I imagine) these peaks are only a few samples in duration which should be mostly imperceptible, would it not be accurate that the original computed ReplayGain values from the original are a better and closer representation (at least perceptually)?

paolorodriguez avatar Sep 18 '17 14:09 paolorodriguez

Well, I have an insanely loud electronic song with track_peak at 3.189 (ripped from CD and encoded with iTunes), and peaks in this song constantly go beyond 1.0 (not only a few samples). The difference is quite large, and false value here should completely spoil clip prevention feature of players such as foobar2000. I don't want to do that... You can always re-scan, or manually copy tags from original if you really want to do it.

nu774 avatar Sep 19 '17 03:09 nu774

I've been thinking about the same, so I've been playing around with ReplayGain:

  • found a flac that has a peak tag value: 1
    • checked it with latest 1.4b3 foobar2000 scanner to see if it's correct
    • qaac --normalize functionality properly recognised it as being 1
  • transcoded it with:
    • qaac without any switch:

      • the resulted file has higher (!) value than the original one had (~1.14) according to foobar2000 scanner
    • qaac --normalize switch:

      • I've got the same higher result as above

That means @nu774 is right, we can't even rely on the original value at all because during transcoding something strange happens.

chros73 avatar Feb 02 '18 14:02 chros73

That means @nu774 is right, we can't even rely on the original value at all because during transcoding something strange happens.

No it's not strange. Peaks are just not preserved by lossy transcoding (MP3, AAC, Vorbis, or Opus, they are all same in this regard).

nu774 avatar Feb 04 '18 04:02 nu774

Peaks are just not preserved by lossy transcoding

Thanks, I didn't know this. This fact makes this ticket unuseful.

chros73 avatar Feb 05 '18 11:02 chros73

we cannot do just copying gain tags

Is it not what ffmpeg does when converting flac to mp3?

bardware avatar Mar 24 '18 16:03 bardware

ffmpeg does when converting flac to mp3?

It has a lot of bugs in it that propagated in mpv even.

ValZapod avatar Jan 28 '22 07:01 ValZapod