since it seems the guidelines are settling on using a series, I went ahead and put in a ticket for a new series type, and found one for radio shows turns out “radio show” is for events, not release groups
1 Like
Should the series type “Podcast” be for releases or release groups? 
I understand the suggestion in the guideline is mostly to use RGs? The ticket should specify, in any case.
Did you see reo’s post @UltimateRiff?
For what it’s worth reo, this is what I wrote into the guideline:
Note: Not because I personally dislike the idea of podcast recording series, but because the guideline that I’m expanding/clarifying was already release-based.
@aerozol I did, I just forgot to respond, lol
based on how I understand podcast releases to work, I think release group series should probably be the standard.
that said, I don’t usually work much with broadcast releases in MusicBrainz… I just saw a ticket that hadn’t been made, then subsequently added my first podcast entry, lol
1 Like
@aerozol I’ve been investing more time in documenting relationships which has caused me to have a realization about broadcasts, radio series, and podcasts. I think they all should be entered as standalone recordings without associated releases or release groups.
For 1980‐06‐21: Haunted: Tales of the Supernatural, Series 1: “Little Girl Lost”
Depending on available data, the recording title would be the “Little Lost Girl”
or “Haunted: Tales of the Supernatural #1”
or “1980‐06‐21: Haunted: Tales of the Supernatural”
It would have a relationship to a recording series called “Haunted: Tales of the Supernatural #1.”
It could also have a relationship to a place of recording on a recording date.
What’s missing is a label type relationship for Broadcaster.
A Broadcasted By relationship would allow adding multiple broadcast dates from a broadcaster which means both the original broadcast date and additional repeat broadcast dates could be added as well.
Other sites which store this type of data often include repeat broadcast dates. For example, British Comedy Guide and BBC Radio
Using stand alone recordings would better reserve the Release and Release Group relationships for actual physical and digital releases, such as book-on-tape and audible releases.
2 Likes
@diskotechjam This is quite a good idea imo. Broadcasts often simply don’t fit the ‘release’ format. I just like browsing stuff by the default ‘release’ tab in MB, but I should probably let go of that (and the MB UI should surface those other elements a bit better).
My bugbear for tagging with standalone recordings is that we don’t have ready access to relationships - e.g. I’m not sure if I would be happy with removing the first recording date from the title. I think it’s a primary piece of information that a lot of people use when browsing/searching and tagging. I don’t know if there’s a good way around that?
The other information that is missing is cover art, for modern releases like podcasts. But I could probably live without.
‘Broadcast by’ is a excellent idea and I will make a ticket for it right now! imo that is exactly the kind of rich data that we want - right @reosarevok?
…hey, you have already made a ticket, and reo is already looking at it 
[STYLE-2416] Add "Broadcasted By" relationship for Labels or Places - MetaBrainz JIRA?
I have stolen some time to have a think, but I am too flat out to really go through and rethink the guideline suggestion as a whole, incorporating this, sorry - but if you would like to collect more feedback and make specific edits or suggestions please do!
I just like browsing stuff by the default ‘release’ tab in MB, but I should probably let go of that (and the MB UI should surface those other elements a bit better).
I agree, the current UI really prioritizes releases. It would be nice if there were more detailed relationships between series and artist (like created by or hosted by).
My bugbear for tagging with standalone recordings is that we don’t have ready access to relationships - e.g. I’m not sure if I would be happy with removing the first recording date from the title. I think it’s a primary piece of information that a lot of people use when browsing/searching and tagging.
Obviously, there are situation where you have no choice but to include the broadcast date in the title (for example, if there is no episode title or episode number). It’s worth noting though that dates can be used as the sorting number in a series which I think would be a superior way to browse through episodes.
At the moment, the lack of tagging support is definitely the biggest problem. Picard would need to support using a series as a release, or someone would need to develop a plugin.
The other information that is missing is cover art, for modern releases like podcasts. But I could probably live without.
Yeah, podcasts in general are a little trickier. Podcasts don’t really have “broadcast” dates per se and it’s not always clear what is a standalone recording and what is a proper release. For example, Hardcore History has very clearly demarcated “releases” but most podcasts do not.
I’ve started a dedicated thread for collecting more detailed feedback.
@aerozol Here’s an example of how I think we can nest series in a way that improves the browsing experience. The main series lists all episodes sorted by original broadcast date and includes the broadcast series as sub-series. I think this is preferable because it puts the episodes front and center and allows the sub-series to be used in a flexible manner. They could be used to group together broadcast series, or used to represent a subtitled sub-series of a podcast (akin to Hardcore History), or used to represent an unofficial series (like all episodes containing a character, topic, or story arc).
I don’t have a problem with this, in theory. But unfortunately it has those drawbacks I mentioned - it buries these broadcasts from the view of most MB browsers/viewers (unless you are familiar with where to search), we can’t store some data like cover art, and it’s hard to pull important data (e.g. date) into taggers.
One thing to note is that the guideline changes in this thread were tidying up the existing broadcast guidelines, without changing their core structure.
I agree that they still do not make big changes, and essentially MB will still handle broadcasts in an unsatisfactory manner.
This is because there were too many blockers for overarching changes when I suggested them in the past - It would probably be a good idea to continue this discussion in your new thread, and we can leave this one as ‘tidying existing guidelines’
Speaking of which, @reosarevok, can we please get this merged? I’m happy to walk you through the changes on IRC some time.
Is there anyone in this thread who thinks this is worse than we currently have? If everyone agrees it’s at least to some degree an improvement, then it seems good to me to look into merging it.
1 Like
The only tiny thing I’d tweak is the bit about episode numbers. Currently it has a very American # being used. Would be handy to also have an example with “episode”, “ep”, “no” or some of the other ways a show number will be named. Just trying to avoid seeing a daft edit war trying to veto wording.
1 Like
It would be simple enough to add:
- # should be replaced with whatever term the program uses, for instance ‘Episode’.
And an example.
But this may stray into changing something, rather than expounding on what’s already in the current guideline? The current guideline does seem to say we should standardise to #. If so, we should probably have a separate thread with a poll or something to see what the community thinks about changing it. On the other hand, if standardisation was never the intention then let’s clarify it with this update
Any idea if the pointer to always use ‘#’ is accidental @reosarevok?
I would have thought it makes more sense to use the way that release was named. MB follows artist intent in many places. For example, BBC shows will always be Episodes. And that name will then appear on the CD and Cassette releases as well as the website. This then also allows for a German show to use their own language, etc.
Probably not the best example, because Episode = Episode
2 Likes
Hahaha… 
Well, no doubt that is our shared Anglo-Saxon roots… I knew Part \ Teil is different.
The expanded broadcast guidelines have now been implemented.
Thanks @reosarevoks for taking over an hour to go through the changes with me today, and making improvements.
If you wanted to see more changes then please treat this as a springboard for further change! I am super happy to at least get those that have consensus over the line - more threads with additions/changes to the guidelines are very welcome.
2 Likes
That’s fantastic! It’s very clear and I like that there are many examples.
I have a question though. Many podcasts come with an image that could be considered cover art. Should this cover art be added to the episodes? The downside, I would think, is that we’re then uploading the same image sometimes hundreds of times, because every episode gets a separate release group. This seems rather wasteful of server resources.
2 Likes
Also a great way to annoy voters
If the ‘release’ comes with official art, then you can add it afaik 
Even if it’s being duplicated, a lot of people will appreciate being able to use the art in their tags.
P.S. very considerate re. server resources, but keep in mind that the internet archive hosts the images for us, and I’m sure that all of our images put together will be a miniscule drop in their bucket. They are trying to back up the whole internet after all!
4 Likes