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.
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.)
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ā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.
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āā¦
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.
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.
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.
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.
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.
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).
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).
)