Skip to main content


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.
Recent Posts
Opus / Re: Opus and replay gain
Last post by Garf -
Well it shouldn't, because that is literally against the spec.

Foobar2000 has volume control, and - once again - straight from the spec:
       If a player chooses to apply any volume adjustment or gain
       modification, (such as the R128_TRACK_GAIN (see Section 5.2),) the
       adjustment MUST be applied in addition to this output gain in
       order to achieve playback at the normalized volume.
By being able to have volume control and not apply the header output gain, foobar2000 is literally breaking the spec.

I do think you are misunderstanding this. See my last comment: this specifies that the gain tags are being applied ON TOP OF the output gain, and that the need to combine these operations is a hard requirement to get the right result. Hence the MUST for "in addition order to achieve playback at the normalized volume". It's important that the implementer understands these need to stack or they'll get the wrong outcome when switching Track Gain to Album Gain and the reverse.

Saying that a player that has a volume control is not spec compliant if it offers an option to ignore that tag is not just uninteresting, it's easily verified as wrong because the spec does use SHOULD and not MUST for applying the gain in the first place (see, I can RFC2119 language laywer too!). This very exact point is literally *spelled out* in the spec revision here:
Opus / Re: Opus and replay gain
Last post by Garf -
My point remains that even today, it is far more difficult to get loudness normalization to work correctly with Opus files than it is to get it to work with other common music file formats like mp3/m4a/ogg/flac on Android.

I'm not sure what pointing to a few buggy libraries is supposed to prove. With MP3 and MP4, you have tools that rewrite and change internal gain values (with limited granularity) to a single setting- those tools don't even exist for Vorbis (AFAIK). For everything else, you rely on the player correctly implementing the tag handling. It's the same for Opus, except that if the latter isn't present, you can still use the "internal gain" method but it has good granularity. So you get the best of all the previous formats.

I'm a bit baffled by your claim and I can't make much sense of it. If developers get the channel order wrong (this was an issue with Vorbis too! You don't remember because it was fixed so long ago, but the Winamp plugin had a workaround for it), or can't tell signed from unsigned values, I'm afraid that there's nothing we could have done in the format spec to prevent that.
Opus / Re: Opus and replay gain
Last post by Garf -
I haven't said anything incorrect and you haven't disagreed with me, yet you phrased what you said in a manner that indicates disagreement. Kinda confusing.

Maybe language lawyering over which RFC2119 definition "forbids" corresponds to exactly wasn't the best way to get to a constructive discussion.

First of all, a specific loudness normalisation gain should not be something the muxer "wants other tools to use by default". Whether track- or album-based or even no (this one is important - see next paragraph) loudness normalisation should be used should be up to the decoder's/player's settings.

You're assuming here the decoder or player HAS these settings or even knows what ReplayGain is. When we discussed this 8 years ago there was no such assumption that all players would have this, and I suspect that's largely been borne out in practice too. So if, as a user, you want Album ReplayGain, then that's what you want your muxer (in this case foobar2000) to write out in the gain field, because that's the very minimal one the player will apply. (The discussion a few posts above points out that even that is gotten wrong by some libraries, but of course at that point all bets are off...)

If you want Track Gain instead, your muxer needs to be configurable to write that out to the gain field instead.

The foobar2000 behavior that you seem to object to is the one that gives the most desirable behavior with the dumbest players (while still working with better ones). If you have a problem with that, that's on you, but don't be surprised that the developers continue to ignore you.

Going back through the past comments and how the spec evolved, you can actually see that R128_ALBUM_GAIN didn't exist initially, and was a reason for 2BDecided's frustration with not being able to interpret the default gain value. So arguing that the default gain shouldn't be album gain and that this is somehow wrong is weird, because it would mean that'd have been a backwards incompatible change and the format would've been Opus 2.0 (no such thing happened!). I'd still maintain that a player that writes out R128_ALBUM_GAIN with non-zero values and a neutral internal gain field is just being bad, because it will break loudness equalization in non-ReplayGain capable playback devices, for *no advantage whatsoever* in players that do actually support it.

Furthermore, "use by default" out of context is misleading here, because it indirectly implies that the "other tools" can opt to not apply the header output gain.

It doesn't imply any such thing. It describes what will happen if the user doesn't configure anything, or CANNOT configure anything, because the player doesn't really know about ReplayGain.

We can now language lawyer a bit more whether the final output volume being different from what's in that tag (due to the user selecting another ReplayGain mode or there being additional album gain tags causing an additional scaling) means that the stated gain is "being applied" or not, but the spec makes it clear (and was always clear) that all the other gains are on top of that one, so there's no real misunderstanding possible in the implementation.

Arguing that a player having *an option* to ignore parts of the spec is "breaking the spec" is simply not interesting.
General - (fb2k) / Re: FB2K-Windows works well on macOS 10.15 Catalina thanks to latest Crossover-Wine
Last post by roc -
I’ve been using Foobar with Crossover for 6-7 years, never had an issue.

Do you happen to use Facets (foo_facets)? That's the main one I can't live without and I found it causing a crash intermittently (couldn't figure out which situations exactly) when using Foorbar on Crossover.
Couldn't find a suitable replacement for it either.

Another one that I suspected was causing an issue was Playlist Organiser (foo_plorg),

Without using an additional plugins indeed I faced no issues using Foobar on Crossover.
3rd Party Plugins - (fb2k) / Re: foo_musicbrainz
Last post by paregistrase -
Will be possible to select the tag name (like album type and status) of the rest of tags like label, catalog, etc.

And about the dates.

I would like to have a structure like:

DATE:                                                      YYYY format of original release date, if not YYYY of release date
RELEASE DATE:                                       YYYY-MM-DD format (if available), if not YYYY
ORIGINAL RELEASE DATE:                      YYYY.MM-DD format (if available), if not YYYY

And have all 3 tag written even if are the same.

How can I do it?

3rd Party Plugins - (fb2k) / Re: Playlist-Tools-SMP
Last post by regor -
Let me know if more things need clarification,  I will try to revise the entire UI to make sure all is clear.

Showing the tag on queries menus is not feasible (too many), but the query is always shown on the console (and thus the tag used).
The tags are already shown at other tools. So that's discarded.

Also moved all tag remapping into the same global submenu (i.e. some tools may have its own submenu for it, but it will now appear at both places).
Spoiler (click to show/hide)