Podcast Style Proposal

Tags: #<Tag:0x00007f05094fc288> #<Tag:0x00007f05094fc120> #<Tag:0x00007f0509503f88>


One topic I’m missing because it’s not that popular in podcasts (except maybe in Germany), is “chapters”.

Especially long podcasts (>1 hour) benefit from those. I think it could be argued to include these as tracks for a release (episode).

Have a look at http://podlove.org for more information.


You would still be able to set the begin date on the official download link, for what it’s worth.
But another missing thing would the cover art. I don’t know if podcast usually have one, though.
They may rather have a global series cover art…


are two I’ve personally added and am maintaining.

As soon as taggers actually implement support for it, I don’t see why not. (Picard ticket, beets ticket)



Is there a reason you didn’t enter podcasts with the style discussed before? Are there issues with it?

Series tagging can be complex, maybe something can be done but simply adding series flag doesn’t really solve anything as so much duplication of data.


I may be wrong because I am not really in that Podcast knowledge but the cool thing about MB series is that we don’t have to add text in our titles saying this comes 4th in the list. It’s all meta data. :slight_smile:


I think there are cases (even going by the 2 test cases we had to cater for - that cover many podcasts) that are more complex than the flat ordering the series entity gives.

I am fairly aware of series and involved in the initial discussiond. Series does have numbering (and automatic if you choose) but frankly we don’t use it for releases. Often with good reason. Otherwise we would have to change the release titles and remove all the volume info.


Just so I’m sure I’m well understood, I didn’t mean to remove anything.
I meant series allow to not add things where they were not before coming into MB (cf. the first releases in the series you’ve just sent, we don’t need to add a number 1 in its title). :slight_smile:


Maybe you missed my point.

you said [quote=“jesus2099, post:11, topic:5911”]
cool thing about MB series is that we don’t have to add text in our titles saying this comes 4th in the list. It’s all meta data

whereas I gave a list of examples where we do not do this.

I am taking about volumes 2 to n they all have the number in the title.

is not just titled
Now That’s What I Call Music!
and left to a series entity to fill in the number.


I don’t quite see the point here, can you elaborate? I have seen series used for releases, but how does this affect the release title?

But as the cover art clearly shows the number is part of the title, so it is just natural we have it set in the title. It is not some artificial number added to aid the sorting. But having the sorting separate helps us solve the cases where there is no or inconsistent numbering (Part One, Part 2, Part III)


My thinking is like this. (:wink: Sorry I would be typing the same thing :))

To be honest, I’m not too sure why so many people (it seems) are interested in having this done via series.
It seems more work and dev clutter to update Picard and Series entities to somehow make them suitable for storing all the required data and then be able to tag this data, then it does to just implement a style guideline that makes use of a system that we already use for very similar things like broadcasts and audiobooks.

Releases might seem like ‘overkill’ to some, who perhaps haven’t tried tagging podcasts, or for another reason that I don’t quite get, but most of the advantages provided by MB’s release system are useful or even indispensable when it comes to Podcasts. An episode release date, an image, a label, an annotation, an album artist and a track artist are not optional if we want to provide and store podcast information in a practical and useful way.
Luckily MB already has all of this capability! We just have to let people know they can use it.

If people want to take a look at a tidy example they can see one here:
The Infinite Monkey Cage: Series 1
I can tag everything I need using this structure (making a few adjustments, eg using the the release group as the ‘album’). It’s still missing useful data like album art, and crediting all the guests as artists on the individual tracks, but that’s not a problem if we’re using releases!
There are a few other examples that are tricky enough using the release group > release structure.

If someone can get a similar taggable result (without waiting another 3 years for updates to X and Y) using another method, and wants to draft a guideline for that, I’m perfectly happy to see it, but I think people may be overestimating the simplicity of podcast data and the variety of cases. And as the delineation between broadcast/music/podcast blurs more and more in future, we might run into a bit of trouble as well.
I can already sense the “When is it a podcast series / when is it a music or mix release?” thread in the far off future :wink:

Of course if anyone wants to give their time to making a release structure specifically for podcasts (eg storing all the necessary information inside the tracklist or series list) I have nothing against that.

We will have to make special rules for podcasts either way. There has been a fair amount of thought in various different podcasts with this those interested should read a summary of these thoughts in the forum post linked at the start.
That thread was initially before series came out but I am not sure there is any difference as it is around now.

Maybe this is one of these tagging vs database mindset issues that often butt heads here from time to time. I don’t see the release structure proposed as being especially problematic and it also works well for tagging, in any tagger.

For example what would the pseudocode for the default file name script be for allowing these podcasts as a series of recordings? Currently the default works fine. And it is always worth considering other data consumers (in this case I am thinking of other taggers) when open data projects start to grow beyond a hobbyist project into a mainstream de facto project.


Maybe I am not explaining myself here.

I agree we should keep the information in the title (or album) information. Jesus seem to be arguing that we should not as we have the series entity now. I was explaining that we do not do that with all the releases in the Musicbrainz database.
For the podcast this information is (mostly) somewhere in the tags (title or album) when you download. It is about preserving that and styling it a little - as we do with any other release in MB.

I have understood that the series entity is supplemental information not fundamental information for the release. Making it fundamentally a part of the organizing data is a paradigm shift in the way we do things here.


OK, I only meant that things like series allowed to get rid of title text modifying guidelines. We have faithful title as printed (with or without numbers). :sweat_smile::sweat_drops:


Now I see your point, thanks for the clarification. I agree that a series as the only structuring element in a, well, series of podcasts might be overly limiting, and given that it does not quite fit into the MusicBrainz structure either way we are probably better served using releases for it.


Haha, well Rovastar quoted the post I wanted to remove, so guess it must have had some good points > <

The reason I took it down is because I wanted to have a closer look at Freso’s series examples, which do seem to do a pretty good job of ordering podcasts, much better than I initially imagined they would. But not having a track release date, album art, and an album artist (as far as I can tell?) is a real bummer when it comes to actually using the data (though maybe you’ve had some luck tagging with those series @Freso?). But it doesn’t actually look that bad.

I do like that it’s a bit tidier because individual episodes aren’t their own release, but unfortunately that is why we lose some data. We could achieve exactly the same thing by putting all the episodes as ‘tracks’ in a single release though, so I’m not sure why we wouldn’t do that instead.

I guess this is the most concise description of why I’m a bit confused regarding the push towards using series for something like this. It seems like a roundabout way of doing things. Perhaps because the description ‘series’ seems to hit the mark for this? But just because the wording fits doesn’t mean that podcasts can’t be releases…
Giving each episode a release inside a release group seems to be the only big divergence from other release types, but it works fine.

People should also note that once the guideline is up, this is an easy candidate for population via automation/ scripts so I’m quite hopeful that things will progress quite fast if we can come to some kind of agreement :grin:


I could not resist posting (although i left off the octopus similie - no idea what that means! ) I thought it had a far amount of valid points worth saying.

I think no solution is ever going to be perfect here.

For the release method we are changing the way release groups are used a bit to make the current schema/design work with podcasts. Fitting a square peg in a round hole. But we sort of do the same with broadcasts that was used a starting point for this. Also some duplication of information.

For the series of recordings although functions and tge majority of info is there does not feel right.
Tagging is a pain/unavailable and I also think others use our data they will have to change how they organise it from the more established release group/release format.
There can be some information loss.
Changing the use of the “series” behaviour .

But more discussion on this is welcomed.

What are the next steps?
I am hoping there is a desire to have “something” official style wise about podcasts.


Note that I don’t really use or edit podcasts in Musicbrainz so take my opinion here with a grain of salt.

I do however like to tag stuff which is similar, namely tracks which are released over time in a blog-style format (e.g. Jonathan Coulton’s “Thing a Week”, #13root’s “Evil Morning”, Party Ben’s mashups…)

I think there are two things that would be most useful for this format:

  1. Tagging of recording-series in Picard.
  2. Giving a series entry a “number” based on date rather than a serial number. This is probably technically possible now but the interface is not built for it.

But I think this reflects the reality best, in that there are often no good demarcation points (“volumes” or the like) to group the recordings into releases, and the release date is at best a fiction (I have used the date of the most-recent track but that doesn’t really help for the others).

Treating them all as singles should also work, though some people likely won’t like how that clutters up the artist’s page. So probably some work on how such things are displayed would be in order as well.


[quote=“Hawke, post:23, topic:5911”]
But I think this reflects the reality best, in that there are often no good demarcation points (“volumes” or the like) to group the recordings into releases, and the release date is at best a fiction (I have used the date of the most-recent track but that doesn’t really help for the others).[/quote]
Not sure if you’re talking about blog-style recordings or Podcasts now, but Podcasts are always very clearly grouped, because of the nature of being played back through Podcast providers where users have subscriptions to series/volumes/groups.
Release dates are also always (in my experience) set in stone & easy to find :slight_smile:

In this proposal each episode is essentially treated as a single release, the only ‘hack’ of the regular single treatment is to put them all in one release group. But that takes care of the mess and is helpful in the case of podcasts anyway (eg very convenient for tagging where it can take advantage of the two layers of information for podcasts - series information and episode information).

Overall this isn’t really looking that positive I have to say…
When discussion in MB starts turning to coding in new features before making something work, I usually mentally bookmark it as ‘check back in five to ten years and see’ :frowning:


Are they? Most podcasts I have seen have been closer to a… channel or an ongoing series than to something like a TV “season”. Occasionally you have something a bit closer to a miniseries, but even that seems iffy as a “release”.

For a concrete example, having a look at http://www.npr.org/podcasts/510208/car-talk I can see that the episode numbering follows a year+week format, but I wouldn’t want to say that all the episodes 1501 through 1552 are part of the same release.

What would you say is the clear grouping for episodes of that podcast? What would be the release date? December 26, 2015 (because that’s when the release is finished)?

Dates of individual episodes are generally solid and often easy to find, but not for anything that I would normally think of as a release.

This is why I lean toward treating them as singles.


Sorry if I wasn’t clear!
What you’re describing is more or less what the Podcast style proposal does -

It groups a ‘channel’ or ‘ongoing series’ under a release group, and treats episodes as singles within them.
In some of the examples we’ve split apart specific ‘seasons’ into their own release groups, but that’s just where there’s a clear definition.

The proposal has examples (in this case ‘Dr Karl’s Great Moments in Science’) that represent most usage cases we’ve come across. Feel free to take a look.


It was recently said in another topic, but I just want to reiterate: we should never, ever design our data around the software that uses it. It may be inconvenient that “OMG I can’t use right now!!”, but in the long run it is much better to store data properly and have software adapt to that. I will vehemently be against any style guideline violating this principle.

I’ll be mostly off for the coming week, but if the discussion is still going when I get back, I’ll try and return and answer some of the questions/comments directed at me earlier.

How to enter books broadcast chapter by chapter via podcasts?