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: My thoughts on two ReplayGain taggers: loudgain and r128gain (Read 25948 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

My thoughts on two ReplayGain taggers: loudgain and r128gain

loudgain and r128gain can be used to tag Replay Gain for entire music collections. I was searching for such a tool and was recommended these two.

First of all they both use ffmpeg so they will always calculate the same replaygain values.

It's how they tag the music files and how fast they do it.

From the authors of these tools:
  • loudgain: "loudgain is designed to do its thing correctly, sometimes at the sacrifice of raw speed"
  • r128gain: "r128gain is a fast audio loudness scanner & tagger"


How they tag the music files:

Tags and values for a FLAC file: The Great Gig in the Sky // The Dark Side of the Moon /// Pink Floyd

Tagsloudgainr128gainRemarks
Album replay gain-4.32 dB-4.30 dB
Album replay gain peak1.0132611.000000
Replay gain-4.34 dB-4.30 dBfor track
Replay gain peak0.9871140.984772for track
REPLAYGAIN_ALBUM_RANGE14.39 dBn/a
REPLAYGAIN_TRACK_RANGE18.00 dBn/a
  • r128gain rounds the values to 1 decimal place (unless the value is below 1) and pads the value with 0 for the number of places required by the ReplayGain v2 specification.
  • loudgain tries to be as precise as it can be.
  • loudgain (by script default) uses extra tags "REPLAYGAIN_ALBUM_RANGE" and "REPLAYGAIN_TRACK_RANGE".
  • I don't know what the above two values are useful for. ReplayGain v1 & v2 does not need those tags. So don't let these tags prevent you from using r128gain.

Tags and values for an OPUS file: The Great Gig in the Sky // The Dark Side of the Moon /// Pink Floyd

OPUS uses EBU R128 for taging ReplayGain values. It uses Q7.8 number format instead of decimals. Don't worry I will convert them back for you.

About this topic from the author of loudgain.

Also European Broadcasting Union's recommendation (EBU R128) is 5 dB lower than what ReplayGain targets. So all the values here will be 5 dB LESS than FLAC values.

Tagsloudgainr128gainRemarks
R128_ALBUM_GAIN-1102 which is -4.30 dB-2381 which is -9.30 dBadding 5 dB it is 4.30 dB. Same as FLAC.
R128_TRACK_GAIN-2387 which is -9.32 dB-2381 which is -9.30 dBadding 5 dB it is 4.32 or 4.30 dB. Same as FLAC.
For whatever reason loudgain decided to add +5 dB for R128_ALBUM_GAIN but not R128_TRACK_GAIN.

r128gain did not add +5 dB to neither of the values.

I don't know which behavior is the correct one.


How fast they do it:

loudgain and r128gain are asked to calculate and tag ReplayGain for different audio files.

Commands for loudgain:

A script "rgbpm" is used with following switches for each codec type. Same options are used on all codecs except AAC where loudgain is asked to use lowercase tags.

Code: [Select]
loudgain -a -k -s e *.opus
loudgain -L -a -k -s e *.m4a
loudgain -a -k -s e *.flac

-a, --album   :   Calculate album gain (and track gain).
-k, --noclip   :   Lower track/album gain to avoid clipping (<= -1 dBTP)
-s i      :   Write ReplayGain 2.0 tags to files. ID3v2 for MP2/MP3, Vorbis Comments for FLAC, Ogg Vorbis and Opus, iTunes-type metadata for MP4.
-s e      :   like '-s i', plus extra tags (reference, ranges).
-L      :   Force lowercase 'REPLAYGAIN_*' tags (MP2/MP3/MP4 only; non-standard)


Commands for r128gain:

Code: [Select]
r128gain -r -a 'album/'

-r, --recursive   : Enable recursive mode: process audio files in directories and subdirectories. If album gain is enabled, all files in a directory are considered as part of the same album. (default: False)
-a, --album-gain   : Enable album gain (default: False)



Pink Floyd (Albums: 13, Tracks: 147, Runtime: 11h 44m 6s i.e. 42246 seconds)
OPUSAACFLAC
loudgain1019.6708s (41.4x)800.3497s (52.8x)815.8843s (51.7x)
r128gain360.2873s (117.2x)512.9899s (82.3x)580.3019s (72.8x)
r128gain is2.8x1.5x1.4xfaster than loudgain
Radiohead (Albums: 9, Tracks: 100, Runtime: 7h 6m 53s i.e. 25613 seconds)
OPUSAACFLAC
loudgain614.8086s  (41.7x)478.6597s (53.5x)509.9963s (50.2x)
r128gain223.2037s (114.7x)322.8559s (79.3x)400.3865s (63.9x)
r128gain is2.7x1.5x1.2xfaster than loudgain
Linkin Park (Albums: 9, Tracks: 136, Runtime: 7h 43m 22s i.e. 27802 seconds)
OPUSAACFLAC
loudgain668.0454s  (41.6x)529.3178s (52.5x)542.5243s (51.2x)
r128gain242.5906s (114.6x)363.5199s (76.5x)446.2279s (62.3x)
r128gain is2.7x1.4x1.2xfaster than loudgain
Bob Marley and The Wailers (Albums: 10, Tracks: 110, Runtime: 6h 37m 0s i.e. 23820 seconds)
OPUSAACFLAC
loudgain577.1740s  (41.2x)452.8059s (52.6x)499.9137s (47.6x)
r128gain209.2830s (113.8x)295.4661s (80.6x)417.0530s (57.1x)
r128gain is2.7x1.4x1.2xfaster than loudgain
  • r128gain is always faster than loudgain.
  • OPUS: loudgain is the slowest while r128gain is at it's fastest.
  • AAC: r128gain is 1 and 1/2 times faster
  • FLAC: Both have similar speed.

 

Re: My thoughts on two ReplayGain taggers: loudgain and r128gain

Reply #1
Tags and values for a FLAC file: The Great Gig in the Sky // The Dark Side of the Moon /// Pink Floyd

Tagsloudgainr128gainRemarks
Album replay gain peak1.0132611.000000
  • r128gain rounds the values to 1 decimal place (unless the value is below 1) and pads the value with 0 for the number of places required by the ReplayGain v2 specification.
  • loudgain tries to be as precise as it can be.

May I ask how can the peak of an album of FLAC tracks be higher than 0dBFS ?  I would actually say that loudgain cannot be correct here. Of course, I cannot be sure if what is seen here is the incorrect usage of ffmpeg or something else.[/list]

Re: My thoughts on two ReplayGain taggers: loudgain and r128gain

Reply #2
    May I ask how can the peak of an album of FLAC tracks be higher than 0dBFS ?
    It must calculate so called true peak. Intersample peaks can exceed digital fullscale by a few dB.[/list]

    Re: My thoughts on two ReplayGain taggers: loudgain and r128gain

    Reply #3
      May I ask how can the peak of an album of FLAC tracks be higher than 0dBFS ?
      It must calculate so called true peak. Intersample peaks can exceed digital fullscale by a few dB.[/list]
      Each sample cannot exceed 0dBFS, but the samples may not correspond to the peaks of the reconstructed waveform .  Hence the peaks can exceed 0dBFS, even with a lossless codec.

      True peak should be the default in r128gain (when in R128 mode), although the album peak looks suspicious.  Performance varies dramatically depending on whether true peak is being measured or not.

      Re: My thoughts on two ReplayGain taggers: loudgain and r128gain

      Reply #4
      Developer of loudgain (past v0.1) here. Great writeup, @pr0m3th3u5, thanks for your testing!

      Just a few quick answers:

      • Precision of LU/dB values: Internally, a much higher precision is used. I was undecided for a while whether I should follow the EBU recommendation (for loudness meters) that specifies 1 decimal digit, or the ReplayGain 2 standard of 2 digits and decided to go with the latter. So all presentation (tags) are rounded to 2 decimal digits.
      • Peak values: Yes, I actually use the true peak values (as calculated by libebur128) for all file types, because, unfortunately, in the days of the loudness wars, tracks could actually otherwise clip. So yes, these can actually go way up above digital 1. (sigh) You might want to read Analyze audio files. Good (and correct) answer btw, @lithopsian!
      • Clipping prevention (-k or -K n switches): I actually a) also use the true peak to do this, and b) reduce the gain as much as needed to follow the EBU recommendation of "max. true peak <= -1 dBTP" when using the "-k" switch. You can modify this by using "-K x" instead and specify the desired max. dBTP value (i.e. 0 or -2). (Ex.: "-K 0" would be how the old mp3gain and others behave.) If you’re interested, read Clipping prevention.
      • Opus files, R128 tags: The standard clearly defines these can only be having a target loudness of -23 LUFS. Fortunately, many players (and IDJC) already behave correctly and add +5 LU when using "replaygained" playout. If you absolutely want to tag these with the "wrong" -18 LUFS-based target, you can: Just add a pre-gain of 5 LU by using the "-d 5" switch. :-) Please read How I handle Opus audio files.
      • Why FFmpeg libraries? Well, they are actively developed and support a lot of different file types. You might have noticed that loudgain already now can correctly calculate the loudness values for much more file types than it can write to. Just try WAV, WavPack, or something else. If loudgain gains momentum, I might decide to support tag writing for even more file types.
      • Why add "RANGE" tags? In (professional) broadcasting and production, you are often required to keep within a certain dynamic range, and I’m also personally interested in filtering my collection by this. Since libebur128 gives us easy access to these values, why not add them? (These are only added upon request, in "-s e" and "-s l" tagging modes, so if you don’t want them, use "-s i" instead.)
      • Why add a "LOUDNESS_REFERENCE" tag? Again, this is only added in "-s e" and "-s l" tagging modes. I do have a mixed collection of EBU-compliant (-23 LUFS) and RG2-compliant (-18 LUFS) files and just want to be sure to be able to identify these (or mis-tagged Opus files), so the playout chain can always behave correctly.

      Have fun trying out loudgain, file issues if you find a bug and ask questions! Thanks for your interest!

      Re: My thoughts on two ReplayGain taggers: loudgain and r128gain

      Reply #5
      Thanks for the detailed comparison, I am the author of r128gain.
      I welcome any constructive critiscim and also bug reports if needed!

      Quote
      From the authors of these tools:

          loudgain: "loudgain is designed to do its thing correctly, sometimes at the sacrifice of raw speed"
          r128gain: "r128gain is a fast audio loudness scanner & tagger"

      I must add here that even though speed was a big factor in how I implemented r128gain, there is no sacrifice on the correctness of precision of the calculation. The trick is to do as much as possible in parallel using threads and/or processes.

      Quote
      r128gain rounds the values to 1 decimal place (unless the value is below 1) and pads the value with 0 for the number of places required by the ReplayGain v2 specification.

      There is no rounding happening.
      r128gain uses FFmpeg's replaygain peak calculation which is the sample peak, so it can never exceed 1.0. It was not the case for older r128gain versions, see https://github.com/desbma/r128gain/issues/4 for some context.

      loudgain probably computes the true peak, hence the difference.

      FFMpeg true peak calculation can be completely off because the sample format and rate is converted before the ebur128 filter, so this does not represent the reality of the original track's true peak.

      I would be curious to see what true peak value loudgain calculates for this track.

      EDIT: Fixed many typos.
      Opus 96 kb/s (Android) / Vorbis -q5 (PC) / WavPack -hhx6m (Archive)

      Re: My thoughts on two ReplayGain taggers: loudgain and r128gain

      Reply #6
      True peak should be the default in r128gain (when in R128 mode)
      The Opus standard explicitly deprecates the peak tags :
      Quote
         Peak normalizations are difficult to calculate reliably for lossy
         codecs because of variation in excursion heights due to decoder
         differences.  In the authors' investigations, they were not applied
         consistently or broadly enough to merit inclusion here..

      So I kept sample peak calculation for compatibility with the replaygain format, but avoid them when using the new R128_XXX tags.

      Performance varies dramatically depending on whether true peak is being measured or not.
      Actually computing the true peak with FFMpeg is cheap when the ebur128 filter is already used to compute the loudness.
      However, computing the sample peak requires a completely different filter chain to avoid the implicit conversions when entering the ebur128 filter, and as a result it is slower. That is why analyzing Opus files is faster than other formats: the second peak calculation filter chain is avoided.
      Opus 96 kb/s (Android) / Vorbis -q5 (PC) / WavPack -hhx6m (Archive)

      Re: My thoughts on two ReplayGain taggers: loudgain and r128gain

      Reply #7
      Hey @dutch109, good to see you around. (I’ve actually been using r128gain in Python stuff before :-))

      But first—and much more important—let me say @pr0m3th3u5 actually found a BUG! Of course the album gain and the track gain should be the same if you only work on one track! This must have escaped my testing, I’ll be correcting this in v0.6.2 asap.

      And of course I’m happy to compare @dutch109 ’s sample. It can only be good if we all work together and get the best results, whatever tools we use.

      Here’s the result of the 3_45.flac test file, as output by loudgain’s -O:

      Re: My thoughts on two ReplayGain taggers: loudgain and r128gain

      Reply #8
      Here’s the result of the 3_45.flac test file, as output by loudgain’s -O:


      I believe you have a bug similar to the one I mentioned and fixed in r128gain.

      That >1.5 true peak is way too high to be correct. The cause is the sample format (float) and sample rate (48 KHz) conversions that FFmpeg does when entering the ebur128 filter.

      See :
      https://github.com/desbma/r128gain/issues/4
      https://trac.ffmpeg.org/ticket/7813

      And the documentation bug the FFmpeg guys did fix: https://trac.ffmpeg.org/ticket/7812

      Opus 96 kb/s (Android) / Vorbis -q5 (PC) / WavPack -hhx6m (Archive)

      Re: My thoughts on two ReplayGain taggers: loudgain and r128gain

      Reply #9
      That >1.5 true peak is way too high to be correct.
      It is correct. And peaks can go way higher than that too. If you for example look at it with a proper audio editor that shows the reconstructed waveform you can see the peak is high. Or if you are limited to Audacity just resample the sample rate high enough to see it.

      Re: My thoughts on two ReplayGain taggers: loudgain and r128gain

      Reply #10
      Well, I also somehow object to using obsolete (=older) technologies like "sample peak" or "RMS peak" if we can have (almost) "true peak". The peak tags are, after all, just an enhanced mechanism to avoid clipping. Also, ITU and EBU fighted long enough to get the industry aware of using LU and true peak metering. There’s a good write-up in ITU-R  BS.1770-4, pages 18 ff.

      It is also interesting that I arrive at the same values, not even using any FFmpeg filter chains (as stated, I use libebur128 directly), and I don’t really consider it a bug. But maybe the given sample should be analyzed by a professional on a good DAW or the like, so we can be sure what’s correct and what not.

      ITU and EBU (and the author of libebur128) put a lot of effort in the recommendations, and libebur128 actually uses a custom polyphase FIR interpolator that will oversample 4x for sample rates < 96000 Hz, 2x for sample rates < 192000 Hz and leave the signal unchanged for 192000 Hz, just to re-construct the original waveform (and of course thus find inter-sample peaks). It only works on 48 kHz input samples, true, but you’d be astonished how many soundcards, JACK implementations and DACs actually also internally run on 48/96/192 kHz (and of course resample). So I actually believe the 1.510972 peak value to be correct, as @Case also pointed out.

      In the interest of following ITU and EBU standards, and keeping loudgain as "professional" as possible, I think I’ll not revert to sample or RMS peak but instead keep using true peak values. At least for the time being. Just think of it as an extra "safety margin", if you will. I would not want to risk any audible damage in the playout chain (or just on my ears).

      I feel it should probably be discussed to refine the ReplayGain 2.0 specification and propose using true peak values.

      I only had Audacity available here right now, but just to visualize it—this is what libebur128 sees on the "3_45.flac" sample (resampled to 192 kHz, 32 bit FP):


      Re: My thoughts on two ReplayGain taggers: loudgain and r128gain

      Reply #11
      I agree true peaks is the way to go. I'll attach an old test file that demonstrates audibly how a high true peak can cause distortion.

      For the test to work digital volume has to be at 100% and automatic clipping preventions can't be used. On Windows that nowadays means one has to try it with ASIO or WASAPI exclusive outputs.

      Re: My thoughts on two ReplayGain taggers: loudgain and r128gain

      Reply #12
      Thanks for the test file. Loudgain output on "overloadtest.flac":

      Code: [Select]
      [✔] Scanning 'overloadtest.flac' ...
      [✔] Stream #0: FLAC (Free Lossless Audio Codec), 16 bit, 44100 Hz, 2 ch, stereo
       100% [========================================================================]

      Track: overloadtest.flac
       Loudness:    -1.63 LUFS
       Range:        9.03 dB
       Peak:     1.546352 (3.79 dBTP)
       Gain:       -16.37 dB

      Wooo-ha! :-)

      Re: My thoughts on two ReplayGain taggers: loudgain and r128gain

      Reply #13
      It is also interesting that I arrive at the same values, not even using any FFmpeg filter chains (as stated, I use libebur128 directly), and I don’t really consider it a bug.

      I believe FFmpeg and libebur128 both have correct implementations of the algorithm. Some versions of FFmpeg also directly uses libebur128.
      But both (correctly) require a specific sample format and rate before the analysis, which requires conversion, and may lead to wrong values.

      As for loudgain, I did not look closely at you code, and maybe the true peak value is correct, I may have been too quick to call that a bug. ;)

      Well, I also somehow object to using obsolete (=older) technologies like "sample peak" or "RMS peak" if we can have (almost) "true peak".
      I agree true peaks is the way to go.

      Guys there is no doubt true peak can go above sample peak and cause clipping, I believe nobody is questioning that.

      The real questions in my opinions are:

      1) Is storing peak value in audio tags really useful and reliable to prevent clipping at playback time?

      The Opus developers (who know a lot more than I do about audio) seem to think not.

      Also modern codecs have more reliable way to prevent clipping, that do not rely on storing metadata written by third party tools.

      2) Is it reasonable to store true peak in replaygain peak tags which break the RGv1 standard, the RGv2 draft standard, and the de facto standard of tools following RGv2?

      This is where I believe the goals of loudgain and r128gain somewhat differ. My understanding is that loudgain was written for specific (professional as you say) needs, and the use case for r128gain is just the casual user who wants to listen his music at equal loudness.

      I wrote r128gain initially to fill a need that I had myself, as there was no tools to tag Opus files on Linux at the time.
      I have thought carefully about compatibility with old tags and tagging tools, and playback of files with different formats aud loudness tags, as did the guys who wrote the RGv2 document.
      I was also careful not to introduce new tags to avoid confusion with an already quite fragmented tag format landscape.
      I have filed bugs in other audio players, and helped developers of some of them to implement the proper playback behavior for Opus, because I was using it myself daily.

      Now, think about the user that has audio files tagged with RGv1 taggers (vorbisgain for example), and then another file with the true sample peak in the REPLAYGAIN_TRACK_GAIN tag. Loudness will vastly differ just because the tagging tools are different. This only contributes to the painful compatibility issues.

      This my main rational for using sample peak : compatibility. And breaking the standard and common usage is not even that useful to prevent clipping because that problem is solved with modern codecs (Vorbis & Opus included).
      Opus 96 kb/s (Android) / Vorbis -q5 (PC) / WavPack -hhx6m (Archive)

      Re: My thoughts on two ReplayGain taggers: loudgain and r128gain

      Reply #14
      Well, same here. Sticking to standards insofar possible (like tag formats and sometimes unthought-of combinations of things), but also embracing changes to the better (like the ITU and EBU recommendations now being around since 2011 or 2012). Does the RG v2 "standard" (which is officially still a proposal!) actually explicitly forbid using true peak? I guess not, but assume that 2012 or so, when it was proposed, we (and the authors) just had not many tools calculating true peaks.

      Regarding the true peak values: I strongly assume that using the true peak values will not provoke "painful compatibility issues" or dramatic "loudness jumps" when used  as a typical user, reasons being:
      • The usual heavy negative gain computed nowadays is (almost) the same. It even seldom differs from what we used to have using RG1 (-18 LUFS has been chosen for a reason). Standard players usually just read the gain value and adjust accordingly. Clipping prevention must sometimes even be enabled before it’s used (and many don’t).
      • Due to the usually drastic gain reduction, the clipping problem will almost never occur, because the resulting dbTP after applying the gain will be much lower. This can easily be analyzed and verified using loudgain’s "-O" (capital letter O) switch and writing the results to a .csv file (it shows columns like "True_Peak", "True_Peak_dBTP", "Will_clip", "Clip_prevent" and "New_Peak", "New_Peak_dBTP").
      • Peak info has almost always just been stored in tags because it can only be achieved at a cost. As you rightly say, Opus devs have actually decided to drop the tag because they knew the difficulties (and software just using sample oder RMS peak, so still possibly clipping). This is of course especially bad when using low quality (compressed) input material, or speech, because that can generate huge amounts of transients/harmonics.

      All in all, using true peak instead of sample or RMS peak, I feel I’m not violating standards, but going the right way. Somehow like a person who has a huge RG1-gained collection and postpones re-tagging but tags all her new music using RG2. It will (mostly) work just great. (This is actually what I did for my own collection of about 150,000 tracks of various file types. Which was the original reason for me to fork loudgain and develop it further.)

      So now I’m pondering how I could convince you to use the same true peak values that FFmpeg calculates, the libebur128 uses, and I use, in r128gain … ;-) I actually believe r128gain did it "better" before reverting to sample peak.

      Let’s go forward and change the RG2 proposal to a real specification, advocating true peak! :-))) [If mankind would never be courageous enough to break existing "rules" and try something new, we’d still live in the stone age, right?]

      Btw, alone from people known to me, almost a million tracks have now been tagged using loudgain, and nobody yet reported any loudness or clipping problems! (Some had clipping issues before.)

      Re: My thoughts on two ReplayGain taggers: loudgain and r128gain

      Reply #15
      Just FYI: I haven’t been using Windows for about 6 years, but I actually now installed Windows 10 and the latest foobar2000 1.4.6 (stable) in a VM, to find out how this nice and often-used player/tagger handles the peak values.

      First result: All the Loudness and Gain values foobar’s replaygain scanner calculates exactly agree with loudgain’s (well, except for my Opus album gain bug).

      Peak values is very different with foobar: You get a default mode but can also enable a variety of "true peak" upsamplers: "auto 2x oversample", "auto 4x oversample", "auto 8x oversample", "Resampler (PPHS)" and "Resampler (dBpoweramp/SSRC)". The latter two can even be configured for sample rate and some "Ultra mode" (whatever that means). A plethora of settings, but I’m a little undecided whether I should give kudos to the developers for the possibilities or boo them for confusing the average user.

      Almost all of foobar’s true peak calculators arrive at even higher peak values than my loudgain (and put those values in the tags). Since I value foobar 2000 a lot, for Windows users, and they really care, I assume they’ll also go the way towards using true peak tags. Makes sense to me.

      For the calculation of true peak values, I’ll keep on relying on whatever the authors of the widely-used and well respected libebur128 come up with. This library is used by many programs, even by FFmpeg, so I reckon they understand much more about filter calculations than I do. :-) And, besides, the results are the same.

      Re: My thoughts on two ReplayGain taggers: loudgain and r128gain

      Reply #16
      loudgain v0.6.2 is out, with the Opus album gain corrected. Thanks again for the find, @pr0m3th3u5.

      It has taken a moment, since real-life users tend to come up with the craziest ideas, i.e. mixing files of different types and declaring them "an album". Correct calculations in these cases are difficult, or sometimes impossible.

      Loudgain will now warn/error out in such cases:
      • It will issue a warning if you mix files of different types (=codecs) in the same album (but still proceed).
      • It will abort with an error if you try to mix Opus and non-Opus files in the same album (it’s not possible to calculate a correct album gain in this case).

      Apart from Linux, loudgain will also run in Windows 10’s "bash" shell (preferably use Ubuntu 18.04) and can be brew-installed on MacOS X (at least on 10.14 Mojave). It is also available in Arch Linux’ AUR, and older Linux versions (i.e., Ubuntu 14.04, Linux Mint 17) are supported by using loudgain.static.

      Enjoy, your feedback is much appreciated!

      Re: My thoughts on two ReplayGain taggers: loudgain and r128gain

      Reply #17
      Just to report on my experience attempting to process 28,000 tracks in one go, all organized as one-folder-per-album. R128gain was a total fail. After several retries (over many hours, mostly unattended) I realized that after just a few minutes of running ffmpeg would error out in some random album, and after that, r128gain stops all tagging - it continues to do "loudness" analysis for all other songs and albums but it doesn't write a single tag! i.e. burns power for hours without producing any result.

      I tried foobar (over play-on-linux/wine) on one of the offending albums and it gets tagged with no fuss.

      I tried to install loudness via homebrew on ubuntu 19.04 and it wasn't a pleasant experience. Hundreds of packages got parallel-installed from JDK to openssl (??) and it errored out in the middle. I will try to build this. It would be so much nicer if loudness gets packaged for debian. or flatpak or snap.



      Re: My thoughts on two ReplayGain taggers: loudgain and r128gain

      Reply #18
      Loudgain experience attempting to tag 28K ogg tracks: failed. 
      For context, these tracks are all cut and encoded from my main collection which is all in Flac + Cue, a mix of regular 44.1K and HD.
      I ended up compiling loudgain which took 10 seconds and worked great. I'd suggest the author to remove references/recommendation of using homebrew on linux/ubuntu as it turned out to be a waste of time,  and would have had no advantage anyways.

      Now to the problem: with loudgain, I didn't get any track erroring out during the analysis phase. However, random quality checks immediately showed a problem, some of the ogg files became corrupted, deadbeef would refuse to play them back and pop up an error message, and "ogginfo" would hang when run on the same track (I've never seen this before). This happened in a large number of tracks (large enough for me to spot with random checks). So for anybody attempting this: backup your ogg collection before starting. Once I identified a few tracks with this problem, I could reproduce this issue 100% by running loudgain (with the "golden parameters" -a -k etc) on them alone. Running loudgain would corrupt them.
      My system: ubuntu 19.04, with the stock ffmpeg that comes with it. No customizations.

      Finally, I tried "vorbisgain" which I understand is the old-school way of tagging replaygain in ogg, using an older psychoaccoustic model etc.
      In order to run it, I adapter the "rgbpm" script that comes with loudgain to just run vorbisgain and also preserve original timestamps. It tagged all 28K songs in one pass with no apparent issue (spot/random checkups all OK so far, and my mobile players are able to use the replaygain tags that were added).

      Lesson learned: vorbisgain is still the only solid solution out there thus far. Hopping that loudgain will mature and hopefully break dependency with ffmpeg that impacts its reliability.

      Re: My thoughts on two ReplayGain taggers: loudgain and r128gain

      Reply #19
      @katraska: Most probably, you ran into taglib bug #864 which unfortunately affects a lot of other Linux software, too. They also don’t have a version check in their API, so I could check the version and warn. :-(

      It’d be time they came up with a new version for the distros to pick up, the last official version is from end-2016.

      The bug is fixed in the meantime, but usually the distros don’t deliver a current version (except Arch-based Linuxes). So you’d be careful when using taglib-based software that touches/rewrites Ogg Vorbis files!

      There’s two ways around this desaster:
      • compile taglib yourself from the current latest GitHub version
      • use "loudgain.static" which has been compiled using a taglib version that doesn’t have this bug

      I mentioned this in loudgain’s NEWS/CHANGELOG:

      Quote
      2019-07-12 — Temporary solution to the taglib problem:

          If you need to loudgain Ogg Vorbis files, you can use the provided loudgain.static in the bin/ folder. I have built it against taglib 1.11.1-3 on Manjaro, a version that doesn’t show the bug. Read loudgain.static.

      2019-07-10 — Warning:

          There seems to be an open bug in taglib (which loudgain uses) that also affects lots of other programs: Upon writing Ogg Vorbis files, they can possibly get corrupted.

         I advise not to save tags to Ogg Vorbis files right now, until this issue is resolved upstream and you can compile a bugfree taglib or the distros provide one!

          Analyzing Ogg files is fine, as well as analyzing and saving to MP3 and FLAC.

      Hint: The bug seems only to appear when there are empty tags in the Vorbis Comments (i.e. "TITLE=").

      Sorry for the inconvenience. You might want to report the problem to your distro (so they include a bug-free version of taglib) and/or upstream taglib, so they come up with an official new version (or at least a version check in the API).

      Re: My thoughts on two ReplayGain taggers: loudgain and r128gain

      Reply #20
      Just to report on my experience attempting to process 28,000 tracks in one go, all organized as one-folder-per-album. R128gain was a total fail. After several retries (over many hours, mostly unattended) I realized that after just a few minutes of running ffmpeg would error out in some random album, and after that, r128gain stops all tagging - it continues to do "loudness" analysis for all other songs and albums but it doesn't write a single tag! i.e. burns power for hours without producing any result.
      I did a quick test, and invalid tracks are simply skipped and should not affect the rest of the scan.

      If you have time you can describe your problem in detail so I can look at it by opening an issue here https://github.com/desbma/r128gain/issues/new
      Opus 96 kb/s (Android) / Vorbis -q5 (PC) / WavPack -hhx6m (Archive)