Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Replaygain backend ffmpeg #3056
comparision with r128gain backend
#3055 also uses ffmpeg, but with an intermediary python module ("r128gain"). This pull request replicates some of the work done in r128gain, but avoids the (beta-) dependency.
The album gain algorithm implemented in this backend - the mean of all track gains, also used by the bs1770gain backend - gives different results than the implementation in r128gain (calculating the gain for a concatenation of all tracks). Calculating the mean is obviously faster than rescanning the whole album, but might deliver worse results.
This backend also does not implement any kind of threading (a single track is scanned at a time), but r128gain does.
sampsyo left a comment
Awesome! Thanks for getting this started. It looks great already; I noted the two issues inline.
We don't currently have a variant of
referenced this pull request
Jan 24, 2019
Testing this backend's accuracy (especially the custom album gain calculation) with an unscientific sample size of 1:
These are with #3314 merged (otherwise every backend will produce garbage).
r128gain calculates the album gain by truly concatenating all tracks and letting ffmpeg re-analyse all audio. We are only 0.0078125 LU (= (1664-1662)/pow(2,8)) off. Considering the difference between bs1770gain and r128gain is 3.5 times as large (or for the track gain 5 times as large) this seems quite good.
Both ffmpeg and bs1770gain can calculate either the sample or true peak. At least to my understanding the sample peak is the highest stored value and thus really fast to compute, while the true peak is the maximum of the resulting waveform and takes somewhat longer.
The ffmpeg backend currently offers the
But the bs1770gain backend unconditionally chooses the sample peak (by using the
I guess bs1770gain should also respect
Huh, good point. I don’t know why that was chosen as the default behavior for the existing backend. It does seem like the backends should be consistent, but that true peak should be the default. Let’s make it do that—perhaps in a PR just for cleaning up the semantics of the “peak” config option?
If its semantics are off that should be fixed right here and only bs1770gain's support added in a separate PR to avoid merging suboptimal code. Or should we move the whole