STYLE-2606 Broadcast style seriously detracting from podcast experience on listenbrainz

MusicBrainz Style
,
1

I think that listenbrainz as an alternative podcasting interface is an attractive idea, but current style guidelines are seriously diminishing the experience.

Current broadcast guidelines recommend the following naming scheme for release groups, releases, tracks and recordings YYYY-MM-DD: Program Name [, Series 1234, ]1234[, “Program Title”][: Location]

This approach creates a couple of issues in the listenbrainz interface.

1: The long string makes it almost impossible to distinguish between broadcast releases on an artist page (and displays redundant date information):

https://listenbrainz.org/artist/e7cf427d-402b-49a8-b869-17e2ac5139c0/

Compared to the spotify which displays episode title in a similar situation:

2: The long strings seems to seriously effect the ability of listenbrainz to find recordings on external services.

Listenbrainz has no issue finding this sanitized recording title on youtube:

However, listenbrainz fails to find this recording following the guidelines:

I don’t have a premium spotify or apple music account for testing but I would expect similar results.

Recommendation - Podcast should follow the following guidelines:

When available, podcast recordings, tracks, releases, and release groups should use the episode title provided by the source. Featured artist credits should be moved to track artists per current guidelines. If episode titles are not provided by the source, titles should either be “Program Name [, Series 1234, ]1234” or “Program Name [Release Date]”

1 Like
2

+1 to a better podcast style/styleguide for MB.

I think the proposed guideline is a little bit thin though - migh need a definition of what a “podcast” is, and could use some examples. I’m also not sure if all the edge cases have been dug into/explored? Better to try pre-empt any possible mess, ideally by including some tricky cases in the examples.

Personally I also think this can be dropped:
“titles should either be “YYYY-MM-DD: Program Name [, Series 1234, ][Episode Number]” or “Program Name [Release Date]””
Otherwise it seems a bit of an arbitrary choice/personal preference which one to use?

“[Release Date]” is also non-specific as to what format the date should be.

1 Like
3

Whoops! Discourse keeps messing with my formatting and i think I mis-copied trying to fix it.

Current guidelines:

YYYY-MM-DD: Program Name [, Series 1234, ][#1234][, “Program Title”][: Location]

Proposed style for release group, release, track and recording, in order of preference:

Episode Title

Series Title[: Series 1234, ][#1234]

Series Title[: YYYY-MM-DD]

YYYY-MM-DD is the date that particular program was first broadcast or the release date provided by the source (RSS feed / website / store page).

These naming conventions are merely a matter of disambiguation where titles are essentially unknown. Release groups should also be related via a release group series and where applicable, broadcast dates should be attributed to recordings using a “broadcast by” relationship. The date of the release should be the date it was published to the source (RSS feed / website / store page). (note: MB does not currently support a broadcast status or broadcast medium, if there is no official digital or physical release it should be added as status unknown with the broadcast date attributed to the “broadcast by” relationship.)

The release artist should be the credits artist, or host, or main performer or various artists. If the episode title contains a featured artist (featuring… or with…) that artist should be add to the release and track credit following the provided formatting. If the artists or guest is the title of the episode, use their name as the title, but only credit them as release artist if they are the main performer.

Recording locations should be related using a “recording location” relationship.

If further disambiguation is desired, see the Live recordings title style.

Cover art should be the artwork provided by the source at the time of release, even if the artwork has been re-used by earlier releases.

Information should preferably be sourced from an official website or feed before podcast store front like Spotify, Apple Music or Youtube. The URL source should be related via a “download for free”, “stream for free”, or “streaming page” relationship.

This applies to single episode releases for a collection (or season) you can follow the broadcast collection guidelines.

I suspect current broadcast style guidelines were modeled on the bootleg style. However, the bootleg guidelines specifically note:

For bootlegs with actual titles, just follow the standard titles guideline.

Hence, this would bringing broadcast style more in line with the bootleg style by preferring given titles. Beyond that, the big change would be moving the date to after the series title, I think this makes more sense

Examples:

Duck in a Tree 2024-09-28 | The Aesthetics of Tautology | A Duck in a Tree
source title: Duck in a Tree 2024-09-28 | The Aesthetics of Tautology
title: The Aesthetics of Tautology
release artist: zoviet*france
release group series: A Duck in a Tree (#636)
release date: 2024-10-01
broadcast by: Resonance FM (2024-09-28)

WFMU: Best Show Gems with Tom Scharpling: Playlists and Archives
source title: Philly Boy Roy Reads ‘Twas the Night Before Christmas, Philly-Style’, featuring Kurt Vile (originally aired on December 21, 2010)
title: Philly Boy Roy Reads 'Twas the Night Before Christmas
release artist: Tom Scharpling
track artist: Tom Scharpling with Jon Wurster (Philly Boy Roy) and Kurt Vile
broadcast by: WFMU (2010-12-01)
release date: 2013-12-23
release group series: Best Show Gems (automatic)
release type: broadcast+spoken word+compilation (highlights release)

BBC Radio 4 - Beyond Belief, The Gift of the Garden
source title: The Gift of the Garden
release artist: Giles Fraser
release date: 2024-08-20 (sourced by RSS Feed)
release group series: Beyond Belief (automatic)
broadcast by: BBC Radio 4 (2024-08-20 15:30)

Eaten By A Grue #29: Kay Interviews Steve Meretzky -- Infocom games, text adventures, and interactive fiction -- Infocom Podcast
source title: Kay Interviews Steve Meretzky
title: Kay Interviews Steve Meretzky
release artist: Kay Savetz and Carrington Vanston
track artist: Kay Savetz and Carrington Vanston with Steve Meretzky
release group series: Eaten By A Grue (#29)

Wait Wait...Don't Tell Me! for June 30, 2012 : Wait Wait...Don't Tell Me! : NPR
source title: [unknown]
title: Wait Wait… Don’t Tell Me!: 2012-06-30
album artist: Peter Sagal
release group series: Wait Wait… Don’t Tell Me! (automatic)
release date: 2012-06-30

https://open.spotify.com/episode/1OvOh2QFP3QVv0nV5HbobQ
source title: Ep 140. John Goodman
release title: John Goodman
release artist: Sam Jones
track artist: Sam Jones with John Goodman
release group series: Off Camera (#140)
release date: 2020-11

if a podcast episode title is the same as the release artist, you can append the date:

Harry Styles - Tiny Desk Concerts - Audio - Apple Podcasts
source title: Harry Styles
release artist: Harry Styles
release: Tiny Desk Concert: 2020-03-16

The Audio Long Read
source title: Morality and rules, and how to avoid drowning: what my daughters learned at school in China
release artist: Peter Hessler (credit writer of original article)
release type: broadcast+audiobook
release group series: The Audio Long Read (automatic)

Sometimes podcasts are released as seasons:

TANIS Podcast Series - Apple Podcasts
release: Tanis: Season 1
release artist: Nic Silver

Sometimes podcasts are short run, for example, college lecture series, these can just be added as a collected broadcast release:

release: Human Behavioral Biology
release artist: Robert Sapolsky

2 Likes
4

Is this more of a call for a specific Podcast type? Would then be easier to make a title style for them that doesn’t then change how other broadcasts are done.

A lot of broadcast title styles was built around organising old radio shows. This is why the titles are able to be alpha sorted. Swapping to a “Program Name” only system would loose that ability.

5

Possibly, of course many podcasts are also radio shows which could lead to confusion.

At this point, my main concern is this style breaking listenbrainz functionality. Listenbrainz appears to use recording titles for it’s look-ups, so perhaps the simplest change would be to set track and recording title using the episode title when available and reverting to the older style when un-available.

Having said that, I think the current style provides one function, alpha-sorting titles by date, a function which could be a achieved by use of a series. Personally, I would be in favor of a broadcast status or medium for capturing the release date.

6

So is that not just a Listenbrainz problem as to how they represent the data?

Taggers get told off for trying to change the MusicBrainz database. Don’t see why ListenBrainz should be treated different?

Series is not really a concept within MusicBrainz when it comes to radio shows \ Broadcasts.

Don’t get me wrong. I’d love a good way of organising radio shows and podcasts. But stripping out all the useful data to leave a raw show title is too extreme.

1 Like
7

I’m not sure I’m following you here. To me, using a series seems like the most natural way for organizing these releases. Release artists can change between broadcasts, so series is really the only way to consistently organize these types of releases:

Since series is really the only way to organize broadcast releases, I think it makes sense to use the sorting functionality provided by series rather than depending on sorting by title.

3 Likes
8

What I meant is when you are looking at an artist’s page there is no way to show a Musicbrainz “series”. Linking a number of episodes as a “series” would not show up without a change of GUI design.

1 Like
9

True, what about still including the series title in the release, but just greatly simplifying the title scheme?

A Duck in a Tree: The Aesthetics of Tautology
Wait Wait… Don’t Tell Me!: 2012-06-30
TANIS: Season 1, Episode 4

10

By reversing how the titles work you break the alpha sorting. The reason the date \ season \ episode is first is alpha sorting. If you need to flip that for ListenBrainz then this is like a tagger asking to change the data. That makes more sense it is done at the app level and not in the database.

The titles are important like that as you don’t always know the actual recording dates. Episode numbers may be the only way to set the order on the artist page.

11

It breaks alpha-sorting but alpha-sorting is only necessary if the release date is blank. Most podcasts have a known release date, and therefore the information in the title is almost always redundant. Perhaps it does make sense to just split podcasts into a different type (or use “other”) until their is a clearer consensus on how to handle a literal broadcast release (i.e. should the broadcast date be used as the release date). I’m all in favor of that as it would allow sorting on the artist page without resorting to alpha-sorting.

12

heh, resorting

jokes aside, I’ve also found podcasts to be difficult to add to MusicBrainz due to the broadcast guidelines (which I’m only now finding might not be universally applied for Podcasts?), and I’ve always thought that the date in the title is a bit redundant, since (at least in the case of podcasts, where the release date is known) that could be added with a simple Picard taggerscript

disclaimer, I haven’t worked with broadcasts or podcasts, but I would like to

1 Like
13

If you are comfortable using the command line, yambs has a feature which lets you seed podcast releases using a local rss feed. It handles title formatting for you, which definitely saves a lot of time.

14

I think the “Broadcast by” is pretty new. Not sure if Picard can get at it?

I have added and edited a lot of radio shows in my time. And don’t think “Broadcast by” was around when I started doing it (otherwise I would have used it). Date is not always part of the show titles - partly because date is not always known for older shows. Series and Episode is more common.

I see [date] swapped with [Series, Episode] in some places. Old archiving is not always consistent. Sometimes only dates are known. Other times only Series\Episode is known. What is important is a way to keep shows organised in a clear way.

There is a thread around here somewhere when podcast title styles were being organised. In there it was also when they were deciding between using a Release Group or a Release as a Series. This is also a point when Podcast started to drift into a different style than other Broadcasts.

I think the guidelines should allow flexibility. This data is used in many other places. So it should not just be changed for taggers or Listenbrainz.

I would think all of the following should also be acceptable - especially now there is somewhere to store a date.
(Show Number) Show Name
(Series x, Episode y) Show Name (Including the s01e08 style)
(Date) Show Name

What worries me is when a guideline is changed by a few people in the forum, and suddenly lots of data is then lost in the database when an editor strips out “messy dates” but doesn’t put them in a relationships instead. This is why it really should be a style tweak available to ListenBrainz in the same way a Picard script manipulates titles.

You need to be able to look at the Artist page for a show and see the shows in order. If there are 100 shows it is going to be confusing to have it A,B,C by show name as you can’t then play them in the right order.

Personally my own podcast files are tagged with a date they are downloaded(released), and then the show title. Often that show title has the episodes number in it but not always. That really depended on the source. I have never added them to Musicbrainz as I know the MB style is far from my own personal style on those.

15

Currently only available through a plugin but there is an open ticket.

It’s not mentioned in the style guidelines, but it’s a very valuable relationship. 1. It allows for repeat broadcasts, 2. it includes a time attribute and 3. it effectively creates an index of a station’s broadcast schedule:

:+1:

The inconsistency in the data is exactly why I don’t like about the style. It makes it very difficult to add releases with partial or incomplete information.

The problem is adding the information to the beginning only makes sense for date. It would need to be Show Name (Show Number) to keep shows from mixing by season, but if we are depending on date for sorting releases, it probably just makes sense to use the broadcast date as the release date rather than adding it to the title.

1 Like
16

Not really. As long as you are consistent for a show it still works.

#1, #2, #3
s01e03, etc
Series 1, Episode 4
etc etc.

Just follow the other episodes in the Release. It is also short enough to fit in a title. My car hifi has a short readout and it is easy to keep this kind of style useable on that so should be usable for listenbrainz too.

This keeps shows in the correct order unlike a title only.

17

What do you think about simply removing the broadcast date and adapting some audiobook style for series naming?

The Hitchhiker’s Guide to the Galaxy, Series 1: “Fit the First”, Episode 1: “This is the Story”

with this option if there is no series numbering or titles

The Hitchhiker’s Guide to the Galaxy, 1976-11-01

1 Like
18

Better to keep it as on release. Especially as a lot of the time you don’t have the dates available. Track names and titles are important to people.

Use Picard if you want to change your tags to use the date instead. Maybe make a plugin for “listenbrainz friendly tags” :slight_smile:

19

Thank you for sticking with this @diskotechjam! I was actually recently thinking the same thing re. removing the date. I hope that this would be a uncontroversial change (I don’t think anyone tags podcasts like that?) and more changes could always be made later.

e.g.

YYYY-MM-DD: Program Name [, Series 1234, ][#1234][, “Program Title”][: Location]

becomes

Program Name [, Series 1234, ][#1234][, “Program Title”][: Location]

20

That looks good to me, the one caveat I would add is the ability to name the sub-series, it’s not super common. I also prefer using Episode 1 to #2

Program Name [, Series 1234: “Subseries Title”][#1234][, “Program Title”][: Location]

What about when there is no unique identifier other that the broadcast date though? How should we format the title in those instances? Currently this doesn’t matter because we always include the date, but it would seem odd to revert to prepending it now. Maybe just this?

Program Name, 2025/03/12

1 Like