I definitely prefer the cleaner style, but there are issues with this type of release for broadcasts. You lose the ability to have unique release dates for individual episodes which is crucial information for radio dramas and podcasts. When I am applying metadata to these types of files, I generally want to know when the program originally aired, not when it was bundled together (unless I’m tagging a specific compilation). The other issue I have run into is that sometimes podcast have unique artwork released for each episode. For example, each episode of Hardcore History has unique artwork, but it’s totally lost by grouping everything in one release.
This is where we have been running into trouble for the last decade… if you want to store information like a different release date for each episode, then waiting, maybe forever, for updates to ‘series’ is the only way. Updates like making it easier to add a lot of recordings/releases, and being able to use series to tag files (I think those are the main blockers?)
I’m hoping that these guidelines intersect in a way that encourage data to be added in the meantime, without breaking anything long-term. Here’s a screenshot with the recording titles included - the full data is still available:
You could also pull the first release date from the recording (in the perfect scenario, where someone has added the individual broadcast release as well).
re. Podcasts with different episode artwork, this doesn’t really explicitly say you should group episodes… just what to do if you do happen to group them. It still allows you to [only or also] add each episode separately, which I would do if I wanted to store episode specific artwork. I have a lot of podcasts I would have liked to add but individual releases just aren’t feasible, not before the heat death of the universe. This hopefully gives some structure to work with without explicitly redefining what a ‘release’ is in MB (and the resulting ‘no’ to the guideline)
Hope that all makes sense…
I have to admit, I’m a little lost because the Fear on Four, Series 1 example seems to me like a radical re-defintion of a release (a arbitrary grouping of files without an official release) whereas treating each episode as its on release (either within a common release group or its own release group) seems fairly minor. I think I’m to the point where episode numbering a series numbering are secondary to getting the correct airdate for each episode in the date and eliminating the clutter is a priority that’s keeping me from adding data. Would this scheme be accepted under the current guidelines? If so, I’m ready to start adding data, and I can wait forever for proper episode numbers.
Fear on Four (Release Group) + Fear on Four (Release) + The Snowman Killing (Track Title) + 1988-01-03 (Date)
In this case it’s not arbitrarily grouping broadcasts - it is grouping the files as they were ‘released’ digitally here: BBC Radio 4 Extra - Fear on 4, Series 1 (digital release date unknown and left blank)
That it offers guidance for entering a bogus series or podcast grouping is a side-effect, but I wouldn’t use any as an example (e.g. the Goons release mentioned earlier).
Since we already treat episodes as their own release it sounds like you’re just after a naming format/syntax change? This proposal doesn’t change how individual broadcasts should be entered, sorry. It’s still the same old long form (YYYY-MM-DD: Program Name [, Series 1234, ][#1234][, “Program Title”][: Location]) for those. That Fear on four screenshot shows how the recordings should be named.
That would be a separate proposal I think, I’m currently trying to propose additions that leave the old guidelines intact. There’s always room for another discussion however…
If it’s not helpful for your issues (bummer) all I can probably ask is that you let me know if these guideline changes make things worse for you
(Side note 1: The long release/title naming syntax made zero sense to me previously, but I’ve come across it in other situations enough now to realise that MB probably didn’t pull it out of thin air. A popular audio file sharing site I’m looking at, right now, doesn’t have naming styles for broadcasts but often titles are as follows: ‘BBC WS - Dec 04 2004 - The Lair of the White Worm by Bram Stoker’, ‘2015.10.31 - Fright Night - Ring.mp3’. This means that a lot of people do find it useful to name their files this way. I’ve since become less confident about scrapping the format… but perhaps you or others have more insight, and thus the confidence to request a change. The MB community may agree!)
(Side note 2: A previous proposal of mine from years back was to group episodes under a ‘season’ or ‘series’ release group, particularly for podcasts, but it didn’t get anywhere then. There’s still a couple of examples floating around that I meant to fix… I still don’t think it’s a bad idea, looking at that now, but it also shifted a MB definition too much - ‘release group’ - and got a lot of pushback)
(Side note 3: Just wondering, do you use Plex or something similar? I usually have no problem with individual releases with the long titles. But Plex makes a real ham when displaying it all… almost impossible to browse when I’m on the go)
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 come across a new situation that’s not explicitly covered in the guidelines, which is how to name re-broadcasts of a show.
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.
I have made some minor updates:
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.
I’ve seen podcast recording series as well.
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
@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.