Podcast Style Proposal

MusicBrainz Style
, , ,
1

I listen to a lot of podcasts, and podcast release information and tagging resources is a bit of a black hole on the internet (similar to audiobooks, which has pretty good MB support, though perhaps not that many editors).
I would love to see a styleguide developed regarding podcasts, so that we can start adding them in a more or less coherent style and format.

We already discussed this in the old forums (3 years ago!):
http://forums.musicbrainz.org/viewtopic.php?id=4228
And I think we more or less reached a conclusion/ something suitable, but then it didnā€™t progress beyond that.

You can find my proposal (with previous discussion taken into account) here: User:Aerozol - MusicBrainz Wiki
I would like to know if it would be possible to get this added as an official style (@Hawke ?)
Of course any further discussion, criticism or contributions are very welcome!

Eventually an actual ā€˜podcastā€™ type in MB would be ideal, because when tagging podcasts you usually want quite different behavior (eg from Picard), in particular putting episodes into ā€˜seriesā€™ folders instead of a new folder (ā€˜releaseā€™) for each episode. But this seems like a start!

4 Likes
2

Do I hear a call for a ā€œPodBrainzā€?

3 Likes
3

I feel that adding podcast episodes as releases is little bit too much. Most of the attributes seem unnecessary. One benefit is using release events for release dates but even then would keep using [worldwide]. I would consider adding podcasts as recording-series. We could have a new series type ā€œPodcastā€ and add episodes as standalone recordings. Series entity already supports volume numbering. If keeping episodes as releases is necessary we could use series for releases.

Our guidelines for release groups currently mention ā€œSeries consisting of different volumes (typically released over a period of time) should have different release groups for each volumeā€. We would need to add an exception if proposed guideline would be accepted. Thatā€™s one more reason why I would recommend using series entity. It might not be necessary to change our guidelines.

1 Like
4

Iā€™m not that familiar with stand-alone recordings grouped via series - would this really be navigable and useful for tagging? If it doesnā€™t have a release date attribute Iā€™m afraid itā€™s already missing the mark by a bit :frowning:
The examples Iā€™ve added so far (linked in the proposal) have all the necessary information, and donā€™t seem particularly troublesome in any way (eg no complaints yet!)

It seems unproductive to add an exception to to the release group guidelines for any of this. Iā€™ve never heard of a podcast referred to as a ā€˜volumeā€™, and regardless, we donā€™t add an exception to every style that is done differently/ is trumped when using the classical style guidelines. At least, I hope notā€¦

1 Like
5

Haha, why not!
But it seems (just) a little bit easier to just make a new style page in MB a la Audiobooks and Broadcasts :wink:

6

3 years since that threadā€¦wowā€¦
I think most of the interest in it has been added already to that thread.

The proposal likely the best we are going to get. We have tried many different use cases and no real objections. Maybe someone could add itā€¦

7

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.

8

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ā€¦

9

and

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)

3 Likes
10

@Freso

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.

1 Like
11

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:

12

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.
eg
https://musicbrainz.org/series/4b5f2897-9b05-4799-b895-6620e27143e7

13

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:

15

Maybe you missed my point.

you said

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

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

16

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)

17

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.

1 Like
18

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.

2 Likes
19

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:

20

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.

21

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: