Proposal <podcast:soundbite>

[snookfin]

I think we should consider giving podcasters a way to identify one or more soundbites at the episode level (they already have trailers for the overall podcast). Apps could use these to generate episode previews, they could highlight them on their main browse screens, or they could build discover functionality like the old FM radio scan mode (check out the Shuffle app). I'm sure someone could also come up with some clever ways to use this to promote episodes on social sites...

<podcast:soundbite startTime="[123]" duration="[30]" />
OR
<podcast:soundbite startTime="[123]" duration="[30]">[Title of Soundbite]</podcast:soundbite>

Item (optional | multiple)

A short extract from the episode, chosen because it summarized the episode and/or persuades further engagement.

• startTime (required) The time where the soundbite begins
• duration (required) How long is the soundbite (recommended between 15 and 120 seconds)
• node value (optional) Used as free form string from the podcast creator to specify a title for the soundbite (otherwise default to episode title)

[theDanielJLewis]

I like this idea! And I think it could be leveraged for something more, too.

How about <podcast:excerpt>? That could reference the information you mentioned. It could also be used to link to excerpt audio, video (like audiograms), or maybe even images.

[daveajones]

Oh, I like this a lot. If I understand, this would instruct the app to jump to that start time and play for that duration. Not necessarily visibly in the GUI, but just as an internal clip?

[mikek999]

Sounds like a good idea... but I can see issues with dynamic ad insertion.

[theDanielJLewis]

Sounds like a good idea... but I can see issues with dynamic ad insertion.

Good point on time-based excerpts/soundbites. But I would think a hosting-provider with dynamic content insertion could then appropriately update the feed to at least some degree. But that won't work for other forms of DCI, such as someone NYC hearing a 30-second spot, someone in LA hears a 60-second spot, and someone in Dallas hears no spot.

[mikek999]

Well it really depends on how the dynamic ad insertion works. Everyone does it differently. Some just put the spot into the stream. Some will shrink or stretch the ad to fit an allotted time span. While other will either shrink or stretch the audio before or after the insertion. I had a client that would do it all three ways and had no clear consistently. I'm way over thinking it..

But it rather makes the itunes:episodetype redundant, since it accepts a value of "trailer" which is intended just for this purpose.

[normand1]

I like it. I assume there would just be a single instance of this tag per episode?

[theDanielJLewis]

I like it. I assume there would just be a single instance of this tag per episode?

I think there could be multiple instances of this per episode, especially if we might it support my idea of more than soundbites, but also additional "excerpt" methods.

[snookfin]

DIA is a bag of hurt. Hosting providers already have to account for time shifts when implementing transcripts and chapter markers. We’re working on a dynamic content tool now and had to develop a way to account for this. Anyone doing DAI well should have similar systems in place.

Personally, I’m not a fan of extending this tag beyond soundbites. Linking to videos and/or images introduces complexities that I think it’s best to avoid at this point (resolution, codecs, aspect ratios, etc.). I think it’s best to provide a simple tag that points to a notable soundbite(s) in the episode and let app developers get creative from there.

If the episode includes a high-fidelity transcript, the app devs could generate a captioned audiogram on the fly.

Re: Apple’s episode type... That’s a tag to mark the entire episode as a trailer. This is very different as it points to a notable section(s) of a “full” episode.

[theDanielJLewis]

Personally, I’m not a fan of extending this tag beyond soundbites. Linking to videos and/or images introduces complexities that I think it’s best to avoid at this point (resolution, codecs, aspect ratios, etc.). I think it’s best to provide a simple tag that points to a notable soundbite(s) in the episode and let app developers get creative from there.

I envisioned such other uses as easier ways to share excerpts from the episode in ways the podcaster has already prepared. But maybe this "soundbite" idea could be focused on "teaser" or "preview" while my other suggests could be split into something focused on sharing.

But then there might be overlap and thus redundancy.

[vandys]

I guarantee that you'll find that you want a fade point as well as the stop time. There are lots of excerpts which would be good, but a hard truncate at the end makes them sound bad. It can also take some time seeking in a large audio file on slower networks.

Note the element on iOS web does not do fading, so they'd still have to hear the hard chop, unless you do something fancy on the backend.

You may want a variant of this where a straight URL to an audio file is used instead.

[tomrossi7]

you'll find that you want a fade point as well as the stop time.

This sounds more like the implementation on the player and not something specified in the feed.

[vandys]

I've done a lot of time in radio production, and clipping is much more art than science. Your player, in the general case, will NOT be able to pick how to transition out of a clip.

[mitchdowney]

@daveajones @snookfin @tomrossi7 can we reopen the podcast:soundbite tag for re-evaluation? As we've discussed before, it seems that it was a mistake to finalize this tag without making the title a required field.

One of the main advantages of the podcast:soundbite tag is that, by adding it to your feed, those soundbites can be discoverable in any Podcasting 2.0 compatible app, but without titles, all we have are time stamps, so we have no searchable title or information to pique listeners interest. Untitled soundbites have almost no practical UX value in podcast apps.

As of today, there are over 200,000 soundbites in Podverse's database, scraped from RSS feeds (mostly Buzzsprout), but only 50 of those soundbites have titles.

I'm worried that people think there isn't a demand for the Soundbite tag, when in fact there is a huge demand for it, but almost no one is seeing how valuable it can be because almost no one can add titles to their soundbites. I genuinely believe this will be one of the most adopted and loved of all Podcasting 2.0 tags, if only titles were included with soundbites.

Personally I'd like to see soundbite titles made a requirement for this namespace. I can't imagine a use case where these untitled soundbites will bring value to podcast apps. If a podcaster doesn't want to fill in a title, the hosting company can apply its own placeholder text as a title.

No one is talking about soundbites, and at this point I think we should acknowledge something is seriously wrong with this tag, because clip sharing is so essential to podcasting, and yet no one is talking about the soundbite tag. I'd love to hear your thoughts and we at Podverse will do everything we possibly can to helping implement soundbites with titles.

[johnchidgey]

The following are my initial thoughts on how we might extend the podcast:soundbite Tag. Wasn't sure the best way to add this so I'm adding it as a comment for the moment. Let me know your thoughts.

Purpose

SoundBites to date have been placed in the podcast source of truth: the RSS feed. Whether they remain embedded in the XML or converted into a referenced JSON file (as per PC2.0 Chapters) as a potential future evolution should be considered to reduce potential feed bloat/hosting bandwidth considerations. The podcaster controls and owns their RSS feed (or should) and as such controls the flow of value and approval of that feeds' content.

SoundBites remain a burden (however slight) to the podcaster to create and embed in their feed. Traditionally SoundBites have been shared via applications, encoding as separate audio files and attaching/posting to social media platforms, or via embedding them in a website and shared as a link. All existing methods do not allow the podcast creator to easily import them in their RSS feed, nor to reward those that created them. (Soundbiters)

To accomplish this, a standard SoundBite sharing format could permit sharing in a simple form that can be imported by the podcaster using local tools or easily added to hosting provider platforms, as well as played in any web/device app. Such a format should contain the existing elements of the SoundBite tag, but also reference the audio file and value address for V4V.

In this way the podcaster could present a new incentivisation pathway for V4V redistribution, with any playback of the SoundBite they incorporate into the RSS feed getting a set split of streaming value of an agreed fixed limit (per minute is not useful as clips vary in length and longer clips would incentivise poor behaviours) between the SoundBiter and the podcaster.

Requirements

Audio only, Constant BitRate encoded audio file.

Implementation Challenges

The onus on playhead position and duration for audio/video remains on the client application, and if the podcaster chooses a non-linear format (eg VBR encoding) then playhead position and duration can be difficult to determine. There are many video formats in use which could be problematic, hence restricting this to Audio/MPEG3 at Constant BitRate (CBR) is the best place to start as a requirement for use in this standard.

SoundBite Tag Ammendments

Group soundbites under a podcast:soundbites element, with each soundbite being an individual element beneath that, with the option to use JSON (per the Chapters standard). With the introduction of the alternate enclosure tag and to allow editing without needing to query the RSS feed item directly, linking to a source audio file of truth will reduce ambiguity and guarantee timestamps are correctly aligned.

Parent

<item>

Count

Single

Attributes

• split (OPTIONAL): The number of shares of the payment this recipient will receive, hence 50 = equal amount to podcaster and to soundbiter, 1 all to soundbiter, 0 all to podcaster.
• url (OPTIONAL): The URL where the soundbites file is located.
• type (OPTIONAL): Mime type of file - JSON preferred, 'application/json+soundbites'.

Examples

<podcast:soundbites split="50" url="https://example.com/episode1/soundbites.json" type="application/json+soundbites" />

Soundbites Element

The valueRecipient tag designates various destinations for payments to be sent to during consumption of the enclosed

Parent

<podcast:soundbite>

Count

Multiple

Attributes

• startTime: (UNCHANGED) The time where the soundbite begins
• duration: (UNCHANGED) How long is the soundbite (recommended between 15 and 120 seconds)
• title: (Now required, was a node value now a named attribute) Used as free form string from the podcast creator to specify a title for the soundbite. Please do not exceed 128 characters for the title value or it may be truncated by aggregators.
• url: Source Audio file URL

Value Attributes

• name (OPTIONAL): A free-form string that designates who or what this recipient is.
• type (OPTIONAL/REQUIRED): This is the service slug of the cryptocurrency or protocol layer hat represents the type of receiving address that will receive the payment.
• method (OPTIONAL): This is the transport mechanism that will be used. (TBD: Was Keysend now blank in podcast:value?)
• address (OPTIONAL/REQUIRED): This denotes the receiving address of the payee.
• customKey (OPTIONAL): The name of a custom record key to send along with the payment.
• customValue (OPTIONAL): A custom value to pass along with the payment. This is considered the value that belongs to the customKey.

Value notes:

The value tag attribute: 'split' is defined at the top level and should be equal for all soundBites in a given feed, which is set by the Podcaster. Both the Podcaster(s) and the soundBite(r) should be compensated for their effort and hence a 50/50 split (0.5) should be default.

The fee is a per play amount before the split and is derived from the podcast:value tags suggested attribute, applied over the recommended maximum duration of a soundbite (nominally 120 seconds). For a client to process a soundbite value split therefore, it is mandatory to have a podcast:value block defined as well.

TBD 1: For Lightning, 1 sat/min streaming rate, 50/50 split is only 1 sat/soundbite which is too small to route. So we consider a 10x multipler by default to avoid this? How much do we value soundbiters - I think that's probably fair?)
TBD 2: Which is the Podcaster true recipient? In a multi-host podcast there could be multiple therefore perhaps an split between all parties defined in the value block for this item.

There is nothing stopping a podcaster from changing this split after multiple soundBites have been created however those creating the soundBite that are motivated by this would observe no value from that effort and would stop contributing in future in that was the case.

Value attributes are all optional, however if they are to be used, optional/required indicates they are required if value is to be used. Some soundbiter(s) may be happy with name attribution, no attribution whatsoever and not have a streaming value destination available to them.

Examples

<podcast:soundbites split="50" url="https://example.com/episode1/soundbites.json" type="application/json+soundbites" />

<podcast:soundbites split="50">
  <podcast:soundbite
    startTime="1234.5"
    duration="42.25"
    title="Why the Podcast Namespace Matters"
    url="https://somewhere.hostingplace.com/ashow/E001-anEpisode.mp3"
    name="A Soundbiter"
    type="node"
    address="02d5c1bf8b940dc9cadca86d1b0a3c37fbe39cee4c7e839e33bef9174531d27f52"
    customKey="[optional key to pass(mixed)]"
    customValue="[optional value to pass(mixed)]"
/>
  <podcast:soundbite
    startTime="134.5"
    duration="30.0"
    title="Why Soundbites Matter"
    url="https://somewhere.hostingplace.com/ashow/E001-anEpisode.mp3"
    name="A Soundbiter again"
    type="node"
    address="02d5c1bf8b940dc9cadca86d1b0a3c37fbe39cee4c7e839e33bef9174531d27f52"
    customKey="[optional key to pass(mixed)]"
    customValue="[optional value to pass(mixed)]"
  />
</podcast:soundbites>

JSON Example

{
	"version" : "1.0",
	"soundbites" :
	[
		{
			"startTime" : "1234.5",
			"duration" : "42.25",
			"title" : "Why the Podcast Namespace Matters",
			"url" : "https://somewhere.hostingplace.com/ashow/E001-anEpisode.mp3",
			{			
				"name" : "A Soundbiter",
				"type" : "node",
				"address" : "02d5c1bf8b940dc9cadca86d1b0a3c37fbe39cee4c7e839e33bef9174531d27f52",
				"customKey" : "[optional key to pass(mixed)]",
				"customValue" : "[optional value to pass(mixed)]"
			}
		},
		{
			 "startTime" : "134.5",
			"duration" : "30.0",
			"title" : "Why Soundbites Matter",
			"url" : "https://somewhere.hostingplace.com/ashow/E001-anEpisode.mp3",
			{
				"name" : "A Soundbiter again",
				"type" : "node",
				"address" : "02d5c1bf8b940dc9cadca86d1b0a3c37fbe39cee4c7e839e33bef9174531d27f52",
				"customKey" : "[optional key to pass(mixed)]",
				"customValue" : "[optional value to pass(mixed)]"
			}
		}
	]
}

Soundbite Sharing Specification

Sharing a soundbite has to be easy for client or web applications to implement and for podcast hosts or podcast servers to ingest with tools to add/insert into the RSS/JSON for the source of truth RSS Feed.

Two methods are suggested for sharing: JSON File and a Query string URL. In either scenario, only one soundbite may be shared per file/string. Each soundbite will be parsed individually.

JSON File Example

{
	"startTime" : "134.5",
	"duration" : "30.0",
	"title" : "Why Soundbites Matter",
	"url" : "https://somewhere.hostingplace.com/ashow/E001-anEpisode.mp3",
	{
		"name" : "A Soundbiter again",
		"type" : "node",
		"address"="02d5c1bf8b940dc9cadca86d1b0a3c37fbe39cee4c7e839e33bef9174531d27f52",
		"customKey" : "[optional key to pass(mixed)]",
		"customValue" : "[optional value to pass(mixed)]"
	}
}

Query String Formatting

String formatting shall comply with RFC3986.

TBD 3: Finish the sharing query string section

[theDanielJLewis]

I'm all for moving this to the episode metafile alongside the chapters. I think that makes a ton of sense.

I'm not so sure about the need or use case for the V4V detail on a soundbite. Why make it different from the main episode split (if there's even a reason to make the episode split different from the show-level split)?

And like chapters, a problem that needs to be accounted for is dynamic content insertion, which would likely shift the timings for soundbites and chapters.

[mitchdowney]

It'd be cool if soundbite and chapter creators could be incorporated into V4V splits. There are two big questions for me though 1) how does the creator get their V4V address / key / value info into the split? and 2) how does the soundbite creator update their V4V address in the soundbite if their address changes?

I suppose an answer to 1) is that the podcaster selects which soundbites to add to the RSS feed, and is provided the address / key / value from the soundbite creator somehow (presumably whatever service listeners are using to create the soundbites).

To address the problems of 1) and 2) without totally centralized solutions...is there a new/additional V4V paradigm we might need for something like this? For example, instead of a value block with address / key / value, what if there is instead a link to an external file containing that value tag info for that value address, and the player is expected to parse these external files on demand to get the corresponding address/key/value for the soundbite creator? Maybe the idea of a "perma-address" like this would have broader utility in V4V?

This is adding significantly more complexity and network requests to compose the final feed info however. Just throwing out ideas.

[theDanielJLewis]

… what if there is instead a link to an external file containing that value tag info for that value address, and the player is expected to parse these external files …

If we put it in an external file, I would suggest only within the episode metadata file. Already, we have a long list of potential requests for every episode:

• Media file
• Episode metadata file
• Episode artwork
• Chapter artwork
• Transcript