Broadcast Guidelines

MusicBrainz Style
, , , ,
22

Here’s an edit, hopefully this makes more sense to @dpr as well:

If the show is a recording of a live performance add “Live”. Studio recordings that were recorded over multiple takes and then edited together are not considered live, even if a ‘studio audience’ was present (for instance, to capture applause).

@IvanDobsky, I’m not sure if you’re asking me to change something re the ‘Spokenword’ section - can you clarify?

I’ll take your word for it, and let other people feedback if they feel differently.

I’ve added this to the draft, does that cover it?

  • Untitled DJ Sets for radio follow this format: YYYY-MM-DD: Radio Station Name
    • If the DJ/s represent a collective or a label follow this format: YYYY-MM-DD: [Collective/Label Name,] Radio Station Name

Examples:

23

No, you just seemed to be querying how some use Spokenword? I think I was agreeing - don’t add it to Audiobook, Audio Drama, Interview as it is obvious that these are spoken.

Something like this should be a fairly loose guideline. I can see some fan forums tweaking names of un-named shows so that “what’s special about them” can stand out. i.e. naming who was on the show, or a topic, etc. There are some brilliant fan websites out there for some shows that will give names to things that are unnamed and that then becomes an unofficial name.

I wouldn’t want to see the kinda daft thing that happens at Discogs that looses good data due to a distorted reading of a guideline. :slight_smile:

1 Like
24

If we don’t want to too restrictive we can add in a “may”, which allows people to still use the main broadcast format if it’s more appropriate?

Untitled DJ Sets for radio may follow this format: YYYY-MM-DD: Radio Station Name

But I’ve never added a radio DJ set in my life, so I’ll let others discuss it :slight_smile:

1 Like
25

Looks good. Here’s a suggested clarification with more examples.

  • Untitled DJ sets for radio follow this format: YYYY-MM-DD: Radio Station Name. If there is an actual program name, do not include the radio station.
    • If the DJ/s represent a collective or a label, follow this format: YYYY-MM-DD: [Collective/Label Name,] Radio Station Name

Examples:
2019-11-11: Hessle Audio (no radio station credited, regularly scheduled show, despite being named the same as a record label)
2021-07-15: Surf Gang, NTS Radio (guest show with DJs representing a collective, where the artist credit does not have the name of the collective)
2021-12-31: NTS Radio (no program name, so just the radio station is used)

1 Like
26

Thanks! Great to get a different type of broadcast in here (more will surface in future, I’m sure of it).

Here’s what we’ve got so far (a few tweaks to your text, in particular trying to keep the examples text-light):

Release name

Follow this format: YYYY-MM-DD: Program Name [, Series 1234, ][#1234][, “Program Title”][: Location]

Notes:

  • Only include series and/or show numbers if each individual show has these.
  • Series should be replaced with whatever term the program uses, for instance ‘Season’.
  • Only include Location if it is a live recording, or if the location of the recording changes often and is mentioned prominently in the show or on the program’s website.
  • Location follows this syntax: [Venue, ]City, [State, ]Country
  • Untitled DJ Sets for radio, use the radio station name in place of the program name: YYYY-MM-DD: Radio Station Name…
    • If the DJ/s represent a collective or a label, follow this format: YYYY-MM-DD: [Collective/Label Name,] Program/Radio Station Name…

Examples:

27

Should probably be changed to just radio station. If they’re guesting on a certain program, it should just be considered a standard program title following YYYY-MM-DD: Program, “Program Title”
Example (not sure if needed to be added to the already long list of examples in the draft):

28

Hmm, that was at least partly intentional, to allow the collective/label name to be added to the main naming format if wanted (that’s a possible scenario, I assume?) But I can see it’s still confusing. Does this make more sense:

  • DJ Sets for radio, with the DJ/s representing a collective or a label, follow this format: YYYY-MM-DD: [Collective/Label Name,] Program Name…
  • Untitled DJ Sets for radio, use the radio station name in place of the program name: YYYY-MM-DD: Radio Station Name…
29

Program name should just be replaced with radio station. The collective thing was just meant for untitled guest mixes not part of a larger program, where putting just the collective name without a radio channel name implies that it’s a regularly scheduled thing and not a one-off guest thing for a radio station. Programs have their own title format already and guest mixes credited to a collective follow those.

2021-09-20: Hessle Audio, “Trekkie Trax Takeover” shouldn’t be 2021-09-20: Trekkie Trax, Hessle Audio, it doesn’t really make sense to treat these as not part of a named title.

2 Likes
30

Cool, thanks for clarification, we now have:

  • Untitled DJ Sets for radio, use the radio station name in place of the program name: YYYY-MM-DD: Radio Station Name…
    • If the DJ/s represent a collective or a label, follow this format: YYYY-MM-DD: [Collective/Label Name,] Radio Station Name…

In regards to the ‘…’ at the end, this is because I assumed there could still be stuff added to the end like show number, live location, etc. Let me know if this is an incorrect assumption as well.

1 Like
31

Should ‘Musical Theatre’ radio broadcasts follow this, or the theatre guideline?
Another sub-set where I’m out of my depth…

To add, if only the theatre guideline is to be used:
Note that broadcasts of musical theatre shows should use the theatre guideline.

To add, if the theatre guideline should be used in tandem:
For broadcasts of musical theatre shows please also refer to the theatre guideline.

32

I would start by finding examples already in the database and write the guideline around those. That is how these guidelines grew up - from discussions with both guidelines and convention in mind.

If it is something you know zero about, it may be safer to avoid writing a guideline for now until we find editors experienced in the topic.

Closest example I own is https://musicbrainz.org/release/50543706-d30a-47b1-9f78-ae69ac1a1c82 but that is more a stage show…

33

I’m glad to see discussion happening on this topic. I have well-over a hundred radio dramas catalogued and tagged in my local collection that I’ve been wanting to add to MB; however, I find the current guidelines deeply unsatisfactory.

Having airdate, series title, series number, episode number, episode title in the track, release, and release group titles is helpful for disambiguation but extremely annoying for organization. On my local system, I simply map airdate to date, series title to album, series number to discnumber, episode number to tracknumber, and episode title to track title. If I don’t do this, my library would be cluttered with well over a thousand XXXX-XX-XX: Series Title, Series XX, Episode XX: “Episode Title” album entries. That’s not even considering the file naming scheme which ends of looking like this:

/XXXX-XX-XX: Series Title, Series XX, Episode XX: “Episode Title”/01 XXXX-XX-XX: Series Title, Series XX, Episode XX: “Episode Title”.ext

^^^^ I mean, Yikes. Just look at that string, I’m seeing every piece of information twice, and yet none of that information is isolated into a useful tag. The same files organized using a simplified system would be /series/seriesnumber-episodenumber title.ext

The disambiguation system is fine when you have limited information, but becomes progressively more annoying as you get more information. This is a problem. It means the more time I put into researching and entering data, the uglier and less useful the data becomes. It’s just redundant and annoying when track and album titles include broadcast dates, series numbers, and episode numbers, where series title and episode title would work just fine. The problem is there is nowhere else to put this data, so you either use it or lose it. The best I’ve seen is entire series categorized as a single release with series title as album, series number as discnumber, and episode number as tracknumber. The problem is this loses the airdate information for individual tracks. For radio dramas and podcasts, airdate for each track is important information.

I think that the central problem here is many broadcasts (radio episodes, podcast episodes, etc.) just aren’t “Releases.” They are standalone “Recordings” which are parts of a larger “Series.” This would make it a lot easier to add random broadcasts episodes and cluster them into a larger series without all the redundancy. It would also make it easier to group the recordings together as a “Release” for cataloguing physical compilations. Unfortunately, standalone recordings aren’t robust enough to enter all the information required to make this work. In the long run though, I think it would be a lot more useful than trying to cram broadcasts into a release category that just doesn’t work.

2 Likes
34

Someone who is clever with Picard now needs to map this to a script.

This is approx what was being done here: https://musicbrainz.org/release/be873569-cfb3-4fbd-bcf5-99ccc776bc77 and I agree makes a lot of sense. It is based on how large collections like this actually work.

35

This is solved by the current guideline suggestion, I think.

The ‘grouped’ part gives guidance on how to enter series as releases (without explicitly encouraging/allowing bogus groupings), and how to name the tracklist in a more reasonable way. It then specifies that the recording should have the longer title, with date etc, if available, so it doesn’t lose that data.

This has been the crux of any argument against ‘grouping’ podcasts, series, etc, into a single release in the past. The ‘technically correct’ way is definitely to use a series. That is also why this guideline proposal stops before explicitly encouraging people to group broadcasts into releases - It would grind to a halt, guaranteed.

The problem is that we still want people to enter and use the DB in the meantime, until features are added that make series at all feasible/usable (e.g. tag files in Picard using series)

So this guideline change attempts to split the difference, make the DB usable for you and me, and also not collide with the past or future.
Please have a read of the guideline proposal and let us know if it helps with your pain-points.

39

There are a few pain points I have with the proposed guidelines, I’ll take the Fear on Four Series as an example. Fear on Four - MusicBrainz

  1. The release date should just be the air date. Broadcast implies a special type of release based on the air date. For an example, look at the way a website like British Comedy Guide provides metadata. Initial broadcast is treated as the original release date of each episode. Air dates should not be included in release titles (except for disambiguation in episode titles).

  1. Series numbers and episode numbers should not be included in the release titles. These should just be handled by music brainz series numbering. While that feature is obviously not currently available in picard, it’s still relatively easy to auto number tracks and I think it’s better to include less information and wait for future features than to clutter release titles.

  2. Release titles should either be Series Titles or Episode Titles. Rather than 1988-01-03: Fear on Four, Series 1, #1, “The Snowman Killing” the title should just be either “Fear on Four” or “The Snowman Killing.” My preference would be the former. This may lead to a lot of releases with the same title, but that’s what disambiguation is for. I can look at Please Please Me by the Beatles and easily distinguish releases based on disambiguation and release dates. We should be able to do that with broadcast releases as well, even if they have the same title.

  3. Track titles should be episode titles. This track shouldn’t be named 1988-01-03: Fear on Four, Series 1, #1, “The Snowman Killing”, it should just be “The Snowman Killing.” If the title is missing it should be Program Title #XX or Program Title: XXXX-XX-XX (It seems like there is a preference for prepending titles with dates, but I just don’t get that. It looks better with the date following the title and it will sort just fine).

In the end, I would prefer missing data over cluttered data. As long as air dates are release dates, everything else (series number and episode number) can follow later. Then we can clean up and simplify the titles situation.

2 Likes
40

Have you had a look at the ‘grouped release’ example (and guidelines)?

That is the part more relevant to your situation, ideally without colliding with the current style:

41

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.

42

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:

image

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…

43

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)

44

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 :pensive:

(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)