Transcoding seemingly stripping replaygain tags

[tordenflesk]

Looking at the resulting command that's ran by the transcoder, it looks like it's simply removing the RG tags, not calculating them: https://i.imgur.com/VCJ1hJ5.png

I've tried both mp3_rg and opus_rg. Are these not supposed to (in my case redundantly) calculate RG as part of the transcode?

[tordenflesk]

Also, the file extensions are not being changed, so transcoded MP3s retain the .flac extension.

[sentriz]

@spijet hey any ideas on this one?

[spijet]

It does strip RG tags in force-RG profiles (mp3_rg, opus_rg) so the client (if it so happens that it supports RG tags) doesn't apply them to already RG-corrected audio stream, but it also applies RG adjustments via audio filters:

	if profile.forceRG {
		args = append(args,
			// set up replaygain processing
			"-af", "volume=replaygain=track:replaygain_preamp=6dB:replaygain_noclip=0, alimiter=level=disabled",
			// drop redundant replaygain tags
			"-metadata", "replaygain_album_gain=",
			"-metadata", "replaygain_album_peak=",
			"-metadata", "replaygain_track_gain=",
			"-metadata", "replaygain_track_peak=",
		)
	}

Or at least I hope it does. :) As for the extension — yes, I found that some clients, like iSub on iOS, report that the stream has the source format (also .flac in my case) and bitrate too, even though in reality it's not. I think that it has something to do with MIME type (and/or something else) not being set up correctly by the HTTP handler.

@sentriz, maybe there's a way we can hack up ServeStream() so it, for example, extracts the file format from selected encoding profile (it's already there in the first parameter of the Profile struct)?

[dertasiu]

@tordenflesk

Also, the file extensions are not being changed, so transcoded MP3s retain the .flac extension.

I think this is fixed in this pull request: #249