How to enter books broadcast chapter by chapter via podcasts?

Dear fellow editors, how should one enter the following audio recordings?

A radio show reads every day a chapter of a book. These recordings are published daily via the podcast feed of the radio station. Some books are read in three days, others in three weeks. The best readings are routinely broadcast every two years, others will be broadcast only once.

How should I enter these episodes of the show? Too many options, none of which seems 100% correct.

Option 1: One release/release group per book

Treat each book as a live release, maybe and put all the books in a series.

Pros:

  • maintains the coherence of the ā€œbookā€;
  • easy to tag downloaded files with most taggers.

Cons:

  • should we record the date in which the single chapters are broadcast?
  • if yes, what about books/chapters/episodes that have been/will be sent multiple times?

Option 2: One recording for each episode, one series for the whole radio show

Pros:

  • matches better the idea of the radio show producing an episode per day.

Cons:

  • what about duplicated recordings? Can the same recording appear twice in a series?
  • needs support for series in tagger. (BTW, which taggers can deal with series?)

Option 3: One release per episode, one release group for the whole radio show

Pros and cons: see Podcast Style Proposal, but keep in mind that there is an additional conceptual unit here: the book.

So, what do you suggest? Any practical suggestion is appreciated, Iā€™d like to start entering my collection and finally have Picard tag those abstrusely named episode files for me. :slight_smile:

Iā€™d personally opt for option 2.

If its the same audio that is simply being re-broadbast, then I wouldnā€™t make a new Recording for it. Iā€™m pretty sure a Recording can be related multiple times to the same Series (as long as the order number is different), but I havenā€™t tested.

None right now AFAIK. Picard and beets at least have open tickets/issues:

(I also commented in the Podcast proposal topic you linked.)

1 Like

Since no one could agree or find a middle ground in the topic you linked, itā€™s really up in the air.
Most people like recordings arranged into series, but if you want to make practical use (eg actually tag podcasts) of them itā€™s pretty much totally useless, which is why I use the style I proposed, eg: https://musicbrainz.org/artist/1c35d6a5-efb6-4a89-9e20-ab42aea6c43a
The only variation of the regular styleguide is that ā€˜Release Groupā€™ becomes a container for different releases in a series.
If you want to stick to current useage, just add separate releases for each episode in their own release group. Itā€™s the only way to get in useful metadata like release date and album art, and follows all the MB styleguides for a broadcast and/or release.

I tag recordings from

and

just fine. (And listen them too, Freso's Listens - ListenBrainz :+1:)

Iā€™m assuming ā€œfineā€ means without half the information we would expect on any other relase, like cover art and release date?

I would prefer option 2 as it best fits with our current data model.

I would also change picard so it can treat a series of recordings as if it is a release group.

Iā€™d go with option one. Take a look at the style for broadcasts, which specifically mentions podcasts; itā€™s being used for Welcome to Night Vale, and seems to be a decent fit. One thing I didnā€™t check there that you would want to do is add each of the release groups to a series, especially if ā€“ like on that page ā€“ theyā€™re going to be releasing multiple audiobooks or dividing them into some other category.

1 Like

Theyā€™re standalone recordings, I wouldnā€™t expect them to have release title, date, cat. no., label, barcode, cover art, ā€¦

1 Like

If it has a release date, cover art, a label, a barcode etc, then why wouldnā€™t you expect to see it and use it?

If Iā€™m going to contribute podcasts to a database then itā€™s not going to be to one that classifies the data as second-rate. Downloads come with track title and artist already anyway.
I would say that other podcast enthusiasts would think the same, but they wouldnā€™t ever know we have podcasts, since standalone recordings and series are hidden away to a casual browser, so all theyā€™ll think is ā€œI wonder if thereā€™s a good podcast resource somewhereā€ā€¦

1 Like

If every episode has its own cover art, then Iā€™d also agree with every episode being its own release.

Not the ones I linked. They mostly come as untagged .wav files. :slight_smile:

Okā€¦

For those where that is the case, that seems more of a case for the UX overhaul (maybe make a ā€œpseudoā€ (ie., just shown not an actual entity) release (group)" that can show Recordings not in any Releases? (ping @chhavi)), than fitting data into a model it doesnā€™t fit into.

1 Like

Thank you all for the discussion.

Allow me to bring back into focus a peculiar property of this radio show/podcast: there are series in series.

Shows like Night Vale or other podcasts are composed of episodes, all belonging to a particular show and being broadcast in a certain order.

This case has an additional dimension: there groups of episodes (the books) that are completely separate and with different sets of metadata. Take this artificial example:

  • 2016-12-22: The overcoat by Gogol, read by John Doe, pt 1
  • 2016-12-23: The overcoat by Gogol, read by John Doe, pt 2
  • 2016-12-24: A Christmas carol by Dickens (abridged), read by Susan Doe, pt 1
  • 2016-12-25: A Christmas carol by Dickens (abridged), read by Susan Doe, pt 2
  • 2016-12-26: A Christmas carol by Dickens (abridged), read by Susan Doe, pt 3
  • 2016-12-27: The overcoat by Gogol, read by John Doe, pt 3
  • 2016-12-28: The overcoat by Gogol, read by John Doe, pt 4
  • 2016-12-29: The adventures of Pinocchio by Collodi, read by Mel Doe, pt 1
  • ā€¦
  • 2017-12-23: War and peace by Tolstoy, read by Anne Doe, pt 43
  • 2016-12-24: A Christmas carol by Dickens (abridged), read by Susan Doe, pt 1
  • 2016-12-25: A Christmas carol by Dickens (abridged), read by Susan Doe, pt 2

Iā€™d like to have a way to ā€œsuggestā€ that A) certain recordings belong together (the ā€œbooksā€) and B) some recordings are repeated.

Neither option 1 or option 2 addresses both A and B.

I was thinking: why not both? [insert missing meme]

What we have here are two views standing on the same data. One could use something like both option 1 and 2 at the same time plus some adjustments, letā€™s call it ā€œoption 12.5ā€.

Option 12.5 Recordings for each broadcast, series of all recordings for the ā€œpodcastā€, releases/releases groups for ā€œbooksā€

  • each broadcast, being audio content, is entered as a separate recording,

The ā€œpodcastā€ view:

  • a release group for the whole show
  • a release for each broadcast (this is where the metadata goes, multiple reruns create multiple releases pointing to the same recording)

The ā€œbookā€ view,

  • each book is a release group,
  • each time a set of shows comprising a ā€œbookā€ is broadcast a new release inside the release group is created, with different release dates and so on.

Would Option 12.5 be acceptable for this particular podcast?

No data is lost and this solution is tagger friendly.

2 Likes

Not really a tagger-friendly solution, but I donā€™t personally like the idea of combining the podcasts/books into a single release group ā€“ theyā€™re certainly connected, but the episodes arenā€™t reissues, different mediums, reorderings, or anything; theyā€™re inherently completely different releases. So Iā€™d say one release group per episode, except for those that were broadcast multiple times: from the list above, ā€œA Christmas Carolā€¦pt. 1ā€ would have two releases in it dated with their individual dates, but both sharing a single recording (so long as they werenā€™t edited). You then create a series per book that collects and properly orders each release group.

1 Like

Sounds similar/ the same as my proposal?
Using current styleguides you can enter them as their own releases, you donā€™t have to worry about that. However using Release Groups to ā€˜stackā€™ them together is something new, which is what people donā€™t like. But imo, go for it, if itā€™s right for you. Youā€™re spending your time making the edits, and people can split everything up later if they really want.

I totally understand that this is why people are against using release group in a different way.
However I disagree with ā€˜fitting data into a model it doesnā€™t fit intoā€™. We already have the perfect model, we have a container thatā€™s made to sort related releases into groups, so it can be browsed efficiently and reduce clutter.

Iā€™m proposing: Use Release Groups to group Podcast releases
The other option: Modify series & recordings so that we can attach information that would be contained in releases and release groups, so that they become a different version of the same thing. Add to the UI so that we are displaying series & recordings in a similar way that we would display release groups and releases. Change Picard so that it tags Podcasts using series and recording information. Wait for other taggers to follow?

In my perfect world podcasts would have their own release group type, and perhaps then MBā€™s change-averse users could stomach release groups being used differently within that type. It could even automatically be displayed as a slightly different title - series group, or similar, without having to rewrite a whole new set of rules and code.

1 Like

Release groups are not for grouping together related releases though. Theyā€™re for grouping alternating versions of the same release. If the audio of two releases are notably different (e.g., two different broadcasts), then they should be two different release groups too.

Related items (releases, release groups, recordings, works, ā€¦) are grouped together using Series (and/or relationships or personal collections, depending on nature of relation).

2 Likes

ā€¦

My point is that regardless of what release groups currently do, they are perfect for grouping podcasts specifically.

Able to be repurposed, sure, but not perfect. Maybe if we ignore rebroadcast episodes, but how do we handle those if the entire podcast is a single release group? Two separate releases loses any indication of the similarities between them, but a single release (even with two dates) canā€™t make machine-readable note of any ETI, address, or other packaging changes on the second. From my perspective, the only thing a series wouldnā€™t give it that a release group does is a way of keeping the artistsā€™ primary tabs cleaner. To help the rest of us out, though, what do you prefer about putting them in a single release group?

Iā€™m not sure what you mean by ignoring rebroadcast episodes? I donā€™t have an opinion/preference on how to handle that. Standalone recordings donā€™t store any release date.

Iā€™m fine with releases grouped via series, in terms of data.
Release groups are purely to keep artist pages browsable/useable, and because a podcast tends to be considered a single creative ā€˜ideaā€™ / theme by the creators (you usually ask people ā€˜have you listened to this podcastā€™, not ā€˜have you listened to this episodeā€™), itā€™s not a massive stretch to group them as we do albums.
Anyone who has concurrent podcasts with hundreds of episodes is going to be unbrowsable (eg some of the idle thumbs crew).