Ah, I see, that makes sense. I’ve spent a lot of time collecting programs from the BBC website. I think it’s the closest thing to an “official” release for a lot of these programs that aren’t popular enough to get on Audible.
I think opening things up to a more informal release style is extremely helpful. It’s exactly because of website like the BBC that I’ve ended up with so many random audio dramas and series, but those types of website are situated in such a odd place. What qualifies as a “release” when you are essentially talking about a massive nearly century old archive? I recently download Bertrand Russell’s Reith Lecture from 1947 off there. How am I suppose to enter that into MB These new guidelines at least move towards clarifying those issues, and they do it cleanly as well. Plus, once the recordings exist in the database, we can easily create new releases in the future which are more representative of the initial broadcast information. So I don’t think the new guidelines would set anything back.
I’ve always suspected it came from a need to clearly differentiate rips of live music broadcast. So if you had multiple live broadcasts from the same program they wouldn’t overlap. I’m just surprised that broadcast date was never added to relationship types like recorded date was. I just find it anathema to other style guidelines on MB, it’s the equivalent of having featured artist or (live) in the track name. Titles are for titles, not for dates.
Yup, I’ve saw this listing when I was tagging Infinite Monkey Cage for my collection, and I think it’s the closest I’ve seen to a system that actually works. Theres still something slightly awkward about the naming convention for the releases though. I think the problem is that certain broadcast types just break the release conventions. Is “Infinite Monkey Cage” the artist, the series, or the release? My instinct is that’s the title of the release, and there are simply several releases with the same title but different content. Should they be under the same release group? It seems simpler, but I guess you wouldn’t strictly have to do it that way.
I use Jellyfin and Kodi for my music, but I’ve switched over to audiobookshelf for this type of content. I can’t praise it highly enough, it’s great for listening to audiobooks, podcasts, lectures, and audio dramas. It treats each episode as a chapter, remembers playback positions, and generally just works a lot better than plex for that type of media. It’s not as great for bigger series though, so I’ve had to split up a lot of releases into smaller seasons.
I’ve set the 2013 broadcast (well, broadcast rip) to still have the prefix ‘1980…’. Just want to see if this makes sense to others? And if the situation should have a mention in the guidelines.
Perhaps a note like:
YYYY-MM-DD represents the date of the first broadcast, even if you are entering a later re-broadcast
Assuming nothing has been edited, the original date makes sense - it is still a Broadcast of a 1980 recording. Just stick notes in the annotation as to the source date of your recording. Happens with BBC shows all the time.
In the main, it is still the 1980 recording. If we are going to get fussy, the recording length could be tweaked to make sure it is only the show length and not the 2013 presenter that may be on the recording. The nature of radio rips often mean extras may be included.
under ‘Release name’, added the note: “YYYY-MM-DD is the date that particular program was first broadcast.”
Based on the two posts prior to this one.
Changed references to ‘Grouped Broadcast Guidelines’ (etc) to ‘Collected Broadcast Guidelines’, as I think the term ‘grouping’ was bringing something new to the table, and confusing people.
Text like “For shows (episodes) collected together, for instance on CD or as a download.” should be more immediately understandable to MB users.
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
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.
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.
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
@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.
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.
@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
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.
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.
# 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.
These new guidelines at least move towards clarifying those issues, and they do it cleanly as well. Plus, once the recordings exist in the database, we can easily create new releases in the future which are more representative of the initial broadcast information. So I don’t think the new guidelines would set anything back.
Well, no doubt that is our shared Anglo-Saxon roots… I knew Part \ Teil is different.