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 -
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.

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 op 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)

3rd Party Plugins - (fb2k) / Re: Playlist-Tools-SMP
Last post by regor -
Great. As said, it's trivial to set picard to retrieve the key and leave any other tag untouched. KEY is not a tag usually available on free software so it's not like you have other options.
Also you may ask the MusicBrainz plugin's author to add support for additional tags if you don't want to use the native software ;)

Rewritten it and added more info.

This will be shown on first init.
Code: [Select]
All the tools use this universal tag structure:

|                           TAGS   NOTATION                              |
| Description |    Tag name    | Tag values (examples) | Notes / Allowed |
| Main genres |      GENRE     |       Alt. Rock       |   Multivalue    |
| Sub-genres  |      STYLE     |   80s Rock; Pop Rock  |   Multivalue    |
| Moods       |      MOOD      |  Not acoustic; Catchy |   Multivalue    |
| Themes      |      THEME     |  Reflection; Summer   |   Multivalue    |
| Key (any    |                |                       | Open, Camelot   |
|   notation) |       KEY      |           Am          | or Standard key |
| Beats   per |                |                       |                 |
|    Minute   |       BPM      |           95          |  Single value   |
| Composers   |    COMPOSER    |      Jimi Hendrix     |   Multivalue    |
|             |                |                       |  Preferred in   |
| Year        |      DATE      |          1964         |     year format |
| Artists     |     ARTIST     |   Lauryn Hill; Sade   |   Multivalue    |
| Track title |      TITLE     |       Amber glow      |  Single value   |
| Featured    |                |                       |                 |
|     artists | INVOLVEDPEOPLE |    Natalia M. King    |   Multivalue    |
| Rating      |     RATING     |           3           |  Plugin or Tag  |

Rationale: It's not feasible to support arbitrary tag names when there are
a dozen of tools using their own. Also tag names should use standard names
and not proprietary names. Proprietary tags like "GENRE LAST.FM" are only
meant as intermediary tags which should be renamed, remapped or merged.

If you use other tag names then you have these options:
1. Rename your tags.
2. Clone your tags and use names at top.
3. Configure scripts to remap standard tags to your own tags.
4. Configure your tagging tools to output proper tag names.

I have used the BIO panel to tag my files, and they are all tagged with

I also have my own genre tag named as "MY GENRE".

Finally I have retrieved keys for my tracks using Traktor and the tag is
written as "INITIAL KEY".

(1) Is not possible for genres, since I intend to use all of them (3 tags).

(2) Would be possible, Masstagger for ex. allows to merge different tags
into one new field. I could simply retag all my tracks this way with a new
tag name "GENRE" which contains the values of the other 3.

(3) Probably the best option. For ex. Playlist Tools or Search by Distance
already allow to remap any group of tags to GENRE, merging their values
and removing duplicates, without touching the files. I will have to look
for "Tag remapping" at the associated buttons in their config.

(4) Picard allows to use scripting to set tag names before writing tags to
files. This is obviously meant for these use-cases where you have different
sources for a tag meant to be the same (genre on All Music, Last Fm, ...)
and they should be merged or properly named. Same comment applies for other
tools. BIO may be configured too, for ex. "ALBUM THEME ALLMUSIC"
could be saved as just "THEME" if that's the only tag source used.

- KEY:
(1) "INITIALL KEY" may be renamed to "KEY" for all my files.

(2) Idem. Trivial to clone single tag as "Key".

(3) Idem. Remapping would allow to use the tag 'as is' without touching
the original files or rewriting all tags.

(4) It would be easier if from now on if I configure Traktor to write tag
as "KEY".

This will be added to the readme list:
Code: [Select]
Some additional notes for tags apply:

|                 TAGS   TECHNICAL NOTES                 |
|  Tag name  |       INTERNALS      |   Notes / Allowed  |
|            |                      |     Merged from    |
| STYLEGENRE | [...STYLE; ...GENRE] |      standard tags |
|     KEY    |     Am | 8A | 1m     |   All are allowed  |
|            |                      |   Used by default  |
|    DATE    |     $YEAR(%DATE%)    |       with this TF |

- STYLEGENRE: is virtual tag used for internal use, retrieved from
STYLE and GENRE standard tags. See "Tagging requisites" readme.

- KEY: may use Camelot notation (8A), Open Key notation (1m) or
Standard notation (Am). Programs like Picard offer standard
notation by default. There is no need to change the format in any
of the tools, since all three are supported (ex. harmonic mixing).

- DATE: as noted on "Tagging requisites" readme, year format is
preferred. In any case, at most places the DATE tag is rewrapped
to use the TF to retrieve only the year part. Usage of a different
format is at your own risk.