Submit your "listens" with foobar2000

Tags: #<Tag:0x00007fcb4be48608>


I already do that.

I hadn’t noticed because none of my tracks contain it. I use foo_musicbrainz for tagging which doesn’t write it.

edit: if people enable this option (it’s off by default)

…they can see the full JSON payload in the Console when it’s sent.


Track MBIDs are more specific than Recording ones and should be submitted as they’re TXXX:MusicBrainz Release Track Id fields. (A Track MBID is a Recording in a specific position on a specific Release, so one Track will always equal exactly one Recording, though one Recording can equal multiple Tracks.)

So MessyBrainz should be able to figure it out if it has a full set of the other MBIDs. Of course, if won’t help much for standalone recordings that do not have a Track MBID, due to not existing on any Releases.


I really, really doubt that it would generate millions of e-mails, and besides, we already have a manned e-mail/contact address for just this purpose:

According to the tag mapping, Picard should currently use UFID: for Recording MBIDs. If it doesn’t set this field already, that’s probably a bug.

However, using that field doesn’t mean we can’t also use TXXX:MusicBrainz Recording Id.


Yeah, from everything I’ve seen digging into the files, we do properly set UFID: I did a quick search, and it seems like foobar2000 doesn’t have any intention of supporting it, though, because it isn’t a plain text tag. A bit shortsighted in my opinion, but as you said, the track IDs would be more accurate.

My complaint was that ListenBrainz only seems to add a link on the song title if it’s given a recording ID, rather than being able to guess it from the track. It does make some sense – the recording linked to a track may change – but it seems like LB or MeB might give up too quickly.


Right, I’ve discovered my first bug, If you have properly tagged m4a files, my script won’t submit musicbrainz track id tags as specified on the tag mapping page.

I actually think this would be the best bet as an “alternate” for id3v2 as well as it matches the existing naming convention of all the other MBID specific TXXX frames as well. However, if you guys want to list others, I may add them.

edit: An updated version with a fix for the m4a problem has been uploaded. I’ve also updated the first post mentioning that musicbrainz_trackid or musicbrainz track id written as TXXX may be used for files containing id3v2 tags. This is because foobar does not support and isn’t likely to support UFID tags.


Here you go.

$copy(_id3:TXXX:MUSICBRAINZ TRACK ID,musicbrainz_recordingid)

I only tested on one album so you might want to test it on copies a bit more thoroughly.

If you open the file with mp3tag, you should see the new MUSICBRAINZ TRACK ID match the MUSICBRAINZ_TRACKID (which is the UFID frame) like this…

and obviously foobar2000 can now see it…

Latest version of the script is required for this, check the first post for details.


If we’re going to make a new ID3 TXXX frame, can’t we please call it “Recording Id” as that’s what it is? The reason it’s called “track id” in some contexts is for legacy purposes. “Recording ID” is the proper term for it.


Well anything is possible because we’re not really dealing with frames at a lower level within foobar. Everything is plain text strings so musicbrainz_trackid will remain an option because it’s used by flac, vorbis, opus, wavpack, musepack etc and musicbrainz track id is used in m4a files. I thought it would be good for id3v2 because it matches the existing naming convention.

I guess I could provide a dialog of some sort for people to use whatever they like.


Well I’m pretty much done with my next update…

it has support for caching listens when LB is down or you are offline (no doubt real world usage will break it in ways I haven’t imagined yet!!)
bulk submission of cached listens (50 at a time if needed)
client side validation of MBIDs
other sanity checks/adherence to API guidelines

Are you guys going to agree amongst yourselves on a new recording ID tag name or do you want the option to use anything you like?

@Freso @mfmeulenbelt


For what it’s worth, I’d vote for consistency, but am perfectly happy either way.


New version uploaded, details in first post. No changes to supported tag names have been added for now.


Looking at the docs, “TXXX:MusicBrainz Track Id” would be most consistent with other, similar tags. I don’t really understand why it isn’t simply called recording id in all those tags by the way. Is that for historical reasons?

History of Tracks and Recordings

A post was split to a new topic: History of Tracks and Recordings


I just tried the “$copy(_id3:TXXX:MusicBrainz Track Id,musicbrainz_recordingid)” tagger script and it seems to work with the current version of the ListenBrainz script. Jay!

Now I just need to re-tag my entire music collection. :slight_smile:


Link rot:


I had a bit of a temper tantrum over on the foobar forums and removed that github account!! I have a new one with an updated component but it’s not really ready for all users just yet due to a lack of documentation. I’ll post back in a few days when it’s done

My updated component even supports Windows XP which it never did before but unfortunately this is not good news for anyone here because it simply doesn’t support the security protocols necessary to communicate with listenbrainz over https.


Well anyway thanks for still being a part of the MusicBrainz community. I thought you had left. I’m glad you are still here and working on things :slight_smile:

…and I do appreciate your previous efforts to add instructions. I hope that your tool becomes good for Windows users. I suppose we other *nix users can use stuff I’ve already posted in my list here:


It seems to now be at (thanks to @marc2k3 comment) :


Ah, I didn’t realise I could retrieve the old wiki from That will help, thanks.


I can’t edit the first post any more but the new link for the project is what @jesus2099 posted above.

If anyone is using v2.0.0, they should upgrade to v2.0.1 because I introduced a silly bug that broke the caching feature. Anyone still using component version v1.x.x is unaffected. Also, there is no compelling reason for v1 users to upgrade at this point. I’ll update the thread if any worthwhile changes are made.