Proposal: <podcast:dynamic-ads-adjusted>

[AdrianMachado]

I am sure many of you are aware but a prominent system of monetization for podcasts is Dynamics Ads. Essentially, ads of varying lengths are inserted into the stream. This is problematic for podcast platforms as any other data under the podcast namespace that utilizes timestamps (ex. srt transcripts, chapters, soundbites, etc.) will be rendered inaccurate as all of the times might be shifted by the ads.

Personally I feel like the onus is on podcast hosts providing dynamic ads to adjust these timestamps based on the ads they insert (side note: for the purposes of discussion, lets refer to different dynamic ad variations of a podcast episode as renditions ). I recognize that not all hosts are capable of doing such adjustments so I am proposing a way of signaling if the podcast timestamps have been adjusted to accommodate for dynamic ads.

Here's an outline of what I am thinking

<podcast:dynamic-ads-adjusted isAdjusted="[true | false | not-applicable]" >

• isAdjusted (required): Indicates if the podcast host has adjusted the podcast namespace data to account for dynamic ads
• true indicates dynamic ads are present and the podcast namespace data has been adjusted accordingly
• false indicates dynamic ads are present and the podcast namespace data has not been adjusted (essentially data relating to timestamps is unusable
• not-applicable indicates dynamic ads are not present

Alternatives Considered

We considered having a tag to mark the insertion points and duration of the ads but feel like this can be abused by ad blockers to adoption by hosts would be limited

Potential Platforms

We at Facebook would be very interested in having this tag available so we can fully utilize any podcast namespace data without worrying about dynamic ads

[daveajones]

Very simple. I can see the value here for sure. Would the default (if this tag is not present) be “not-applicable” I assume? Also, is this an item level tag? Some episodes in a feed may not have DAI.

Maybe some hosting companies can speak here to the feasibility of tracking this data from their DAI workflow into the feed when it’s generated.

Cc: @tomrossi7 @PofMagicfingers @eteubert @KieranMcKeefery @cio-blubrry @dan @jonbuda

I’m not sure if NPR does any DAI. @staceygoers?

[PofMagicfingers]

I see the underlying issue, it has been discussed multiple times here ( #175 for example ).

At podCloud we do not use DAI for now. So I´ll let the people doing it speak for themselves.

However, here are my 2 cents (because I like to give my opinion on everything :eyes:)

false indicates dynamic ads are present and the podcast namespace data has not been adjusted (essentially data relating to timestamps is unusable

If it's unusable why would the host include an unusable chapter list ?

not-applicable indicates dynamic ads are not present

If it's not applicable why would the host include this tag ?

Why not simply recommend to either adjust the chapter list timecode or fully drop it if it's becoming invalid.

That would not need a tag, and it seems more logical : you're not adding meta content and then telling consumers to not trust it.

[staceygoers]

I agree that if you are using DAI, you need to have your chapters and/or transcript markers be updated or just not include at all.

We do use DAI at NPR but we also use it for other elements beyond ads: content (Consider This podcast) and cross-promos, marketing podcasts across the catalogue.

I recommend calling this something different than "dynamic ads," as that's limiting. Perhaps something associated to the media enclosure, that could show that the length could change?

(FWIW, we've long been curious on how much change is too much within a file -- can hosts handle if 1 episode changes by 10 minutes or 20 minutes based upon the request? We did some testing last year to try to find the outer limits.)

[francosolerio]

The way I see it is there should be a 1:1 correspondence between what's in the item/enclosure tag in the RSS feed and the actual audio file. Any other solution would provoke non-solvable problems for podcast player apps.

We already (at Castamatic) have issues with podcasts that use DAI as the enclosure file length is always variable and almost never corresponds to what is reported in the enclosure length in the RSS feed.

The correct way to implement DAI should be to dynamically serve different RSS feed files to different listeners, so that the info in the RSS feed always reflects what's in the audio file.

[AdrianMachado]

Thanks for the discussion this proposal.

@PofMagicfingers I agree with just dropping fields if they are not to be trusted, but are all fields droppable? Ex. episode duration?

@staceygoers any amount of change beyond a few seconds is actually too much from our perspective. For certain features we want to build, user-by-user variance in the content creates quite a bit of a pain when it comes to social/sharing use-cases

@francosolerio do you forsee the current model of DAI changing anytime soon? I agree that it should be the RSS feeds that are dynamic, not just the mp3 file

[ryan-lp]

I think having a simple yes/no flag would be very helpful so that affected podcast apps would know to exclude these podcasts.

One example of where it would be useful is so that timestamp-based podcast search engines would know to exclude these podcasts from search results. For instance, if a person searches for a topic and the search engine finds an episode that talks about that topic at the 1 hour and 57 minutes and 29 seconds mark, the search results provide a timestamped link into the correct timestamp where the result was found. We would like to know how to exclude podcasts where this user experience would not work, and the proposed tag would be helpful here.

Another example is in timestamp-based clip sharing. For instance, where a listener wants to pause the episode and share a link to this exact moment in the episode with a friend via a timestamped link. With this tag, it would be possible for apps to disable this feature when each listener potentially has incompatible time codes, and timestamped link sharing would not work.

Another example is when a listener wants to embed a link to a specific timestamp of the episode on their blog or social board and comment on it.

One final example is in order to support timestamped inter-app comments where we would like comments made in the comments section by one listener at a certain moment to show up at that exact same moment when a different listener replays that same podcast. In this and other cases above, it would be nice to know when an app dynamically changes the timestamps so that it can know to exclude that podcast from such user experiences.

I can see how a podcaster might not want their podcast to be excluded from features that would allow their podcast to be shared and thereby reach a wider audience, but I think it would create a poor user experience for an app to actually provide a timestamped link that does not work, and so we unfortunately need a way to discriminate such podcasts so that affected apps would know how to exclude them.

I think that in order to support such use cases for podcasts that use dynamic ad insertion, the client side (i.e. the app) needs to be involved, either by letting the app know where the ad insertion points are, or by adding an option VAST-compliant apps to dynamically insert ads on the client side (see #556 ).

[francosolerio]

There's a much more common use pattern than sharing that makes DAI very bad.

User has 2 devices, say a phone and a computer. Both have the same podcast player installed, which syncs current listening position. Computer and phone download the attachment of the latest episode directly from the host, and receive 2 different files, with different ads and different duration. User begins listening on the phone while commuting, gets to a point and then pauses. When he arrives home he resumes listening on the computer, but being the attachment durations different, the resume point is wrong.

The usual result is the user complains with the app developer that sync doesn't work properly.

I'm strongly convinced that with the actual state of technology and standards, DAI should always insert ads of the same length at the same position for all variants of the same episode. That's the only solution that respects the podcasting standards and specifications.

[staceygoers]

We need to solve problems for the majority of podcasts/podcast tech, not outliers. I am going to wager that majority of RSS feeds are hosted by providers that do DAI in some capability -- I would actually love this data, if anyone is able to provide it. (Ha, I realize the OG tag proposal here would solve that data search query, funny enough ...)

DAI isn't just ads, it can hold the future of dynamic content delivery. What we should do is move toward smart, clean and user-friendly DAI experiences -- build a future where DAI exists, but perhaps has boundaries that makes it clean and easy for any new hosting platform or podcaster to enter, without screwing up a user experience.

This below is kinda getting in that direction, but oftentimes, you have ad inventory that just doesn't fulfill in some targeting location (i.e. you can serve ads in the US, but not in the UK ... or you have content that meets an audience in Boston, but not Kentucky):

I'm strongly convinced that with the actual state of technology and standards, DAI should always insert ads of the same length at the same position for all variants of the same episode. That's the only solution that respects the podcasting standards and specifications.

[francosolerio]

@staceygoers I don't understand what you mean by outliers. If you mean podcasts without DAI, you may as well call them podcasts that made podcasting successful because they have happy users who find the correct resume point when they press the play button 😄

Humble suggestion for hosting companies: make all ads of the same duration, or produce some bumpers and stingers with different durations containing the hosting provider callsign + music / effects, and use them as padding to make all insertions of same duration. For shows that have no ads, produce default insertions by the hosting company and let podcasters upload their own "void insertion replacements". Your listeners will be thankful. There is no podcast app in the world that I know of, from tech giants or outliers, than can correctly resume variable length DAI episodes from different devices.

[johnspurlock]

Dynamic content is pervasive and here to stay, standards should understand this and work with the grain instead of against it. I like the productive recent discussion around sending request-level transcripts as link headers in the dynamic response, for example.

You're right Franco that it is much more difficult for apps to deal with for specific time-based features, but that's not an unsolvable problem - just an order of magnitude harder, and is a differentiation opportunity for apps willing to do it.

[ryan-lp]

It's true that guaranteeing that ads always have the same length and position would prevent timestamp shifting, but it has two problems:

1. When a search engine indexes an episode transcript, it should only index the episode itself and not the dynamic content, because a search index can only feasibly index a single version of the episode. What will happen is that it will end up not only indexing the static content of the episode, but also indexing a particular version of the dynamic ad. When the user clicks on the link, they will not get the thing they clicked on, they'll get something else, and the search result was therefor irrelevant to the user's search query.
2. As @staceygoers pointed out, it may not be realistic to force all ads to be the same length.

As someone who habitually clicks the "skip forward" button when I hear an ad, or an intro or an outro, I think one of the limitations of the current approach is that it is a bit too easy to skip ads. Back in the old days, I used to do this with TV shows I had recorded onto video, and I got pretty good at knowing how long to hold down the fast-forward button and time it exactly to stop when the ad break had finished. Today I am subscribed to a streaming service that includes ad breaks, and I've similarly figured out the exact number of times I need to click the "skip forward" button to perfectly jump over the ad break (it's 15 times, by the way ;-) . And with podcasts, I find ads are really quite uncommon (even if many podcast hosting platforms may support it, only a fewer number of podcasters decide to use it, presumably because they are not doing this for money, and they don't want their listeners to get annoyed). Although in the one podcast I listen to that actually does have ads, I habitually click the skip forward button, and I have a button programmed on my headset to allow me to do that easily.

Now having said all of that, I'm not actually of the mind that ads are a bad thing. I honestly think they are a one of many valid revenue models. And it's also true that if I actually gave myself a chance to listen to the ads, I might find the occasional one that was just what I needed. I know this because on YouTube, it forces me to listen to at least the first 5 seconds of an ad before deciding whether to skip it, and although I almost always skip it the very millisecond that that skip button becomes clickable, sometimes those first 5 seconds are enough to sell me on something that I really want, and I let the ad play through.

Proposal #556 is something I came up with when trying to think of what an ideal solution might look like if it wanted to provide the most advantages to both the advertiser+podcaster+host and the listener and the app developer. It employs the VAST standard for client-side dynamic ad insertion (basically the same sort of thing that YouTube does, so that it is possible to prevent the user from skipping an ad until they have at least listened to the first 5 seconds), but it only offers this to apps that declare themselves to be VAST compliant, otherwise it defaults to the current approach which is server-side dynamic ad insertion. The way I see this working is that most podcast apps wouldn't need to bother changing their logic. But then if a podcast app is timestamp sensitive, e.g. it wants to offer a timestamped clip sharing feature, or any of the rich user experiences described in the above comments, then it can declare VAST compliance, and implement a VAST-compliant player. Fortunately SDKs for VAST players are available on Android, iOS and Web, and actually the standard Android SDK for playing audio supports VAST by default.

So #556 is, as far as I'm aware, the only proposal that provides a way for apps to prevent listeners from skipping ads too soon, and it is also the only proposal that can correctly handle dynamic ad insertions of different lengths and different positions in a way that is compatible with all of these rich user experiences described above.

I still think we need the proposal in the top post, though, because for any podcast that dynamically adjusts timestamps (without a way for VAST-compliant apps to deal with unadjusted timestamps), apps will still need a way to exclude those podcasts.

There is no podcast app in the world that I know of, from tech giants or outliers, than can correctly resume variable length DAI episodes from different devices.

Well actually, putting aside the usual workaround of clicking the fast forward or rewind button, there are several technological means by which apps can detect and skip ads or other kinds of dynamic content automatically. Two apps that do this are AdSkipPro and Adblock Podcast. Once an app has the ability to detect ads, it can also solve the problem of finding the correct resumption point on a different device, within the same app.

The problem comes when trying to share timestamp points with other people who use a different app.

I'd like to see a proper solution to dynamic ad insertion. My proposal is an attempt to brainstorm one that is modelled after the way YouTube handles ads, but with a backup option for regular podcast apps to continue working the way they currently do. I wouldn't want to say this is the only way possible, although it is so far, I think, the only proposal that can handle all scenarios, including dynamically inserting ads of different lengths and positions. I would welcome any other proposals that can similarly solve these problems.

But in the meantime, as long as the current approach to dynamic ad insertion persists, we need a way to flag which podcasts do this so that it would be possible for podcast search engines and other apps to be able to exclude any podcasts that prevent timestamp-based features from working.

You're right Franco that it is much more difficult for apps to deal with for specific time-based features, but that's not an unsolvable problem - just an order of magnitude harder, and is a differentiation opportunity for apps willing to do it.

However, without having a standard that explicitly supports this, It is a "solvable problem" only within the app, but not between apps. A search engine should ideally be able to produce timestamped results that can be opened by a separate podcast app. Yes, if the same company controls the search engine and the player app, then the problem is solved. But we don't really want one company to control the market, we'd like an open ecosystem where different apps can all work together in an interoperable way, and for that we need a standard, rather than a way for smart apps to work around the problem at the expense of interoperability.

[jamescridland]

There is no podcast app in the world that I know of, from tech giants or outliers, than can correctly resume variable length DAI episodes from different devices.

The ULID (universal listen ID) could achieve this. There used to be a nice website here that explained it, but it seems to be not working currently. This is a drier and more technical writeup.

It's a listen ID that is produced by your podcast app, and is specifically not tied to your user ID: it's just a listen ID. If you're running a podcast app that works on multiple devices, you'll be logged-in to it, and so it can manage the ULIDs on a per-account basis. You send it as a parameter as part of the request for the MP3.

A DAI system looks for the ULID and logs which ads it served to that ULID. That then allows: a) correct deduping of listens across platform by the same person, therefore better stats b) resuming a podcast correctly at the right place, since the audio file should be identical c) transcripts and JSON chapters would also work, since they know which ads were served and thus what lengths. It also allows JSON chapters and transcripts for the actual ads to be stitched in.

It also comes with the benefit that we're not signalling to podcast apps where the ads are (allowing bad actors to automatically skip them), and it respects the creator's work.

Humble suggestion for hosting companies: make all ads of the same duration

There's no technical need to do this, and filling unsold inventory with trailers is a poor user experience. Learn from the radio business, and if something is unsold, please don't fill it with jingles and nonsense; just skip ahead to the next bit of content.

[ryan-lp]

Well, detecting dynamic ad insertion points is not difficult, app developers apparently just haven't realised it yet.

All it takes is for one person to publish the solutions in a blog post, or to publish an open source library to do it, and then apps will be able to leverage this to support clip sharing "within apps", and search engine links "within apps owned by the same company".

As a thought experiment, try running the Risk-Benefit analysis on this and tell me that it won't turn out any differently from DVD region locking. Once the solution is published and app developers become aware of how easy it is, the obfuscation immediately becomes useless. But as a consequence, every DVD player now includes the same ugly and pointless workaround for what was a weak system in the first place. The legacy of these efforts is not a successful enforcement of region locks, but rather, pointless workarounds.

So the question is whether we want to have a well-designed system that promotes app interoperability, or a poor system that encourages workarounds at the sacrifice of interoperability.

P.S. I would be happy to demonstrate how easy it is to work around this. Would anyone like to share links to a few podcasts that do dynamic ad insertion?

[ryan-lp]

A DAI system looks for the ULID and logs which ads it served to that ULID. That then allows: a) correct deduping of listens across platform by the same person, therefore better stats b) resuming a podcast correctly at the right place, since the audio file should be identical c) transcripts and JSON chapters would also work, since they know which ads were served and thus what lengths. It also allows JSON chapters and transcripts for the actual ads to be stitched in.

Again, this is incompatible with social use cases. Each user will get different timestamps, so they won't be able to socialise about timestamped moments with each other. It's also incompatible with search engines.

Also, the ULID approach is incompatible with targeted advertising. Maybe you think that's a good thing, but not everybody does. There are ads that would only make sense to Australian consumers, even though the podcast itself would appeal to an international audience. For example, what if a local Australian camera shop wants to advertise itself on an Australian podcast about photography that can be listened to by anyone around the world? Podcasts about photography are not country specific, but ads selling photography products sure can be. Likewise, when I listen to an American podcast, I don't want to receive ads about American businesses that aren't applicable to me.

Apps can always skip ads if they want to despite attempts at obfuscation and I'm willing to demonstrate how easy this is to do if you want me to demonstrate on specific examples, and so the only question is whether you want to stifle the development of these other beneficial features on the misguided assumption that stifling innovation will also prevent ad skipping. It won't.

Ironically, there is only one way to actually prevent ad skipping, and that is to trust the app developers with the very thing people are afraid to trust them with: the dynamic insertion points.

[jamescridland]

Also, the ULID approach is incompatible with targeted advertising.

Do explain that to me, Ryan?

[ryan-lp]

When you use an idempotent ULID that is "just a listen ID" and aims to hide the country of origin (according to the article you linked to), how does a local Australian business target an ad to an Australian audience and prevent paying for ad exposure to American listeners?

[AdrianMachado]

FWIW it's been years since I left FB (and also they shut down podcasts). For context, I was working on captioning and social sharing of podcasts.

0. Download the podcast server side (golden copy)

The solution for social that we came up with was essentially

1. Stream the golden copy to the client for the user to choose their sharing point (we allowed you to select a start and end point to create a clip)
2. Clip the golden copy between those two timepoints, and create a new asset that is shared to a friend

For captions

1. Generate captions for the golden copy (in the standard timestamp to caption text format I forget the name of)
2. Generate a mapping of pools of bytes to captions
3. In our player, we would look ahead at the incoming bytes of the podcast, if we found a match in our byte-pool -> caption table, we would display the matching caption

Essentially dynamic content went uncaptioned which is great because its a waste for most people. I recognize that for most platforms out there, both of these are pretty expensive and unfeasible, but thought I would sort of close the loop on what inspired this suggestion

[jamescridland]

Interesting misunderstanding - happy to help.

The ULID is just a per-listen ID. It's not used for targeting. Nothing there changes - the MP3 is still requested from a podcast host, which reads the IP address for location, could also use the useragent, might even do some "what else has this user listened to" stuff. The audio ads injected therein can still be targeted.

Additionally, there is this ULID which tells the podcast host nothing other than "this is the ID of one listen event from one person". The podcast host could use that to remember what ads they stitched in, and tie the ULID together with the request for the transcript and/or chapters JSON. But there's no change to targeting - that continues to work as before.

You also say that it doesn't help with timestamp shares. You're right there - a timestamp share will never work properly with DAI (though will get you relatively close to the right bit). However, one way to achieve better timestamp sharing is to use the JSON chapters element to work out the most recent chapter event, and give a time offset from there. That isn't foolproof, but is significantly more likely to be an accurate timestamp in the audio - "chapter 6 plus 2'35". A ULID approach to correctly set the chapter timestamps would help this. We should probably be realistic here and recognise that this form of sharing is very rare.

You're also right that it's relatively easy to build an ad-skipping podcast app by analysing the audio. Here, we're just trying to avoid actual signposts in each podcast feed saying "here is where the ads are". If you want an analogy: while I'm sure my front door's lock is pickable with a modicum of talent, I still lock it, rather than leave the front door wide open with a sign on the street saying "come steal my stuff".

[jamescridland]

@AdrianMachado - interesting that "create a new asset that is shared to a friend" was chosen as the concept. The podcaster gains no benefit from that new asset (since it isn't registered as a download at their server), and it's a transformative work of a piece of copyrighted material, which needs a copyright owner to agree to. (Facebook will have sorted that in the T&Cs, but a typical podcast app has no such T&C agreement).

Putting that aside, there have been plenty of apps which have led on the idea of clipping interesting bits out of podcasts. None have shown much success. I do wonder whether it's behaviour which would ever be anything more than super-niche; complicated slightly by the fact that it's even hard to link to specific episodes outside of one specific podcast app; both Apple and Spotify use proprietary IDs for podcasts and for episodes. I would rather we focus on things that have, or could have, mass adoption - like transcripts - and work out how to fix that; if we can fix transcripts, then the timestamp stuff ought to come free.

[ryan-lp]

Interesting misunderstanding - happy to help.

Of course you are ;-) It's interesting that you would characterise this as purely a misunderstanding on my part, when both of the articles you linked to that explain ULID make such a big thing about this being a way to prevent your privacy from being violated, and to move away from tracking of IP addresses and user agents. I quote:

Every time you download a podcast episode, your IP, and therefore your private information, is being stored, examined, analyzed, and recorded. A profile about you is being built, slowly, every time you listen.

And then in the other article:

DuckDuckGo announced recently that they will be creating an email privacy service to block user behavior tracking by advertisers and publishers. They join many others including Brave, Firefox and CloudFlare who are also tackling web privacy. Additionally, we can now add Apple to the mix who recently planted their flag firmly on app privacy.

This is becoming more than common. It's a trend. We are routinely hearing from big industry players who are aiming to squash user behavior tracking in as many digital spaces as possible. Yes, that plays well with their public image. But, it's more than that. It’s what we, as their customers, want.

And of course with a clear and unambiguous title:

Time To Hang Up the Egos and Move Beyond IP Addresses

And of course, nowhere in your explanation of how this privacy-respecting ULID solution could also be extended to solve the DAI timestamp problem did you mention that actually, we are not going to "Hang Up the Egos and Move Beyond IP Addresses" and we'll go ahead and track the IP addresses and user agents anyway.

So yes, an "interesting misunderstanding" indeed, purely on my part, of course.

So let's take a quote from the first article:

And perhaps most importantly, ULIDs ensure listeners get the privacy they want while podcasters get the reliable, truthful listener data they need.

Now presumably these SAME servers that are tracking the ULIDs (for privacy-based reasons, of course), would not also be the very same servers that are also tracking the IP addresses and user agents which can be used to "reveal your personal Internet service provider, your employer, and much more", right?

But I have apparently misunderstood you on this point. So let me quote from your helpful explanation which is supposed to clarify my misunderstanding:

The ULID is just a per-listen ID. It's not used for targeting. Nothing there changes - the MP3 is still requested from a podcast host, which reads the IP address for location, could also use the useragent, might even do some "what else has this user listened to" stuff. The audio ads injected therein can still be targeted.

Yes, an interesting "misunderstanding" indeed. If the very same server that tracks the privacy-protecting ULID also tracks the IP address and user agent, one wonders whether privacy is really being addressed by ULIDs, or whether the ULID is not actually solving privacy, it's just there to uniquely track listens. Nothing more. Put aside privacy, and forget about the title of the article.

But this all just obfuscates the real point of this issue which is that apps legitimately need a signal for dynamic timestamp adjustments, and if the spec is not going to recognise that, open source libraries are going to pop up to defeat all efforts to stifle this anyway so we're better off doing it properly from the start. Unfortunately, proper solutions are receiving very little attention in favour of this misguided attempt to hide insertion points.

You also say that it doesn't help with timestamp shares. You're right there - a timestamp share will never work properly with DAI (though will get you relatively close to the right bit).

No, there is at least one solution that solves this problem, and your denial of it hinges on your belief that the risks outweigh the benefits.

However, one way to achieve better timestamp sharing is to use the JSON chapters element to work out the most recent chapter event, and give a time offset from there. That isn't foolproof, but is significantly more likely to be an accurate timestamp in the audio - "chapter 6 plus 2'35". A ULID approach to correctly set the chapter timestamps would help this. We should probably be realistic here and recognise that this form of sharing is very rare.

Could it be because advertisers are stifling attempts to offer this? I want to do everything I can to make it easier for apps to implement these sorts of features, and that is why I am fighting hard to convince people that there is actually no point in trying to hide the insertion points if one day an open source library will render the whole effort pointless. Why not do it properly from the start rather than wait to see it turn out the same way as DVD region locking?

You're also right that it's relatively easy to build an ad-skipping podcast app by analysing the audio.

I never said that. Analysing the audio is the hardest way to do it, so I'm not sure why you think that approach would be relatively easy to build. It would be quite difficult, actually. Until 3 years ago, detecting ad insertion points was quite computationally expensive and not easy to implement. But with the introduction of timestamped transcripts 3 years ago, it can now be done at extremely low computational cost. So having an open source library that can implement the algorithms for you, and can be quite performant, it will defeat the whole effort to obfuscate.

Here, we're just trying to avoid actual signposts in each podcast feed saying "here is where the ads are".

You haven't done the risk-benefit analysis on someone publishing an open source library that tells you "here is where the ads are".

If you want an analogy: while I'm sure my front door's lock is pickable with a modicum of talent, I still lock it, rather than leave the front door wide open with a sign on the street saying "come steal my stuff".

I find this to be a very misleading analogy. There is no stealing here. Everything is on public display, and everyone is free to look at everything, or to look at different things in different orders, and to talk to each other about what they see. And while picking the lock of one's private residence is illegal, sharing a podcast timestamp with a friend is not.

[ryan-lp]

Essentially dynamic content went uncaptioned which is great because its a waste for most people.

Except for the people who actually rely on transcripts to understand what is being said.

I realise it's not actually easy to do this properly when advertisers are making it hard to do it properly, but that is why ideally we could turn the discussion towards a proper solution. In this case, a proper solution should make it possible for different agents to agree on timestamps for static parts of the audio while disagreeing on dynamic ads, but should still have captions for everything.

Failing a proper solution, we need your proposal to have a boolean yes/no flag. Even if advertisers never agree to a proper solution, it would not hurt to have this boolean yes/no flag anyway. Or maybe it would, because it means that some apps would use it to exclude those podcasts from social experiences. In that case, we'll just need to create another open source workaround to automatically infer whether a certain podcast gives stable timestamps or not.

[jamescridland]

Jeez, Ryan - I give up.

[ryan-lp]

Putting that aside, there have been plenty of apps which have led on the idea of clipping interesting bits out of podcasts. None have shown much success. I do wonder whether it's behaviour which would ever be anything more than super-niche;

You might be thinking too narrowly about this when you think of clips. Compare this to YouTube for a moment. People certainly do take clips from other videos and re-upload them in legally questionable ways. But we're not just talking about clips here. I send timestamped YouTube links to other people on a very regular basis. I don't want them to go hunting for the right position in a 2 hour long lecture, so I find the correct timestamp for them and then share that with them. A YouTube timestamped link looks like a regular YouTube link, but with the timestamp parameter appended to the end, like ?t=timestamp. The YouTube player also has a convenient share button for creating a timestamped link. Magically, those timestamped links work even in the presence of dynamic ad insertion, as per the same proposal I am submitting.

Now you listen to a 2 hour long podcast interview where the guest says at the 1h33m mark something interesting or controversial and you want to tweet some comment about it (or X it) with a link or post it to Facebook, or even post it in a discussion comment here. People want to talk about things and that's difficult to do without being able to refer to them in a stable way.

You yourself recently shared a podcast episode link with me (https://github.com/Podcastindex-org/podcast-namespace/discussions/556#discussioncomment-6574689) because you wanted to comment on a specific conversation that occurred somewhere within that 2 hour long episode. Now, you just sent me an untimestamped link to the whole 2 hour thing:

http://adam.curry.com/html/PC2013320230519Podca-MB6Wp7j2fbRbnW0PMGtZDd73vpMwcS.html

Hopefully we can agree that it would have been more helpful to send a timestamped link so that I wouldn't have had to hunt through the episode myself to find which part you wanted me to listen to in such a long episode, like for example this timestamped link:

https://overcast.fm/+6A0A23YZE/51:01

In this scenario, surely what we ideally want is

1. a timestamp-based search engine to quickly find the right position in the right episode, and
2. a share button that you can use to easily copy and paste the timestamped link into your comment.

I don't consider search engines or link sharing to be niche. They are practically two of the most common things people do on the Internet. There is an opportunity for someone to create a timestamp-based podcast search engine API that other podcast apps could use, and here we could have a many-to-many relationship between search engine endpoints and podcast apps that connect to those search engines. But in this scenario, we would like the timestamps returned by the search to actually be valid and precise regardless of which app and which user opens it.

(Oh, and one more thing: Jeez, James - I give up! (Well, no not really. You should understand that even rhetorical questions have a point and deserve real answers.))

[jamescridland]

You're very keen to argue, Ryan. I wish you'd think a little before posting, and consider that some of us may have a little more experience in this field than you do - and instead of instantly arguing back, think about whether their comments to you have merit. To be told I'm "thinking narrowly" is, um, ever so slightly patronising. There's probably a reason why nobody else is even bothering to engage with you here. I'm guessing most people have you muted. I'm not sure why I've not yet done that.

Hopefully we can agree that it would have been more helpful to send a timestamped link so that I wouldn't have had to hunt through the episode myself

See, you start here by accusing me of being deliberately unhelpful. That's not a great look. I assume you just want to argue again. Try dialing it down a notch, and being a little kinder in your responses.

It's evident that you do send timestamped YouTube links to others. I'd suggest to you that YouTube has this functionality built-in, while most podcast apps don't. I don't use Overcast; I don't believe that any other popular app - one that I might assume you'd use - actually has a "share from this point" built-in.

I'd also suggest that the amount of timestamped YouTube links actually used on the internet is a tiny, tiny minority of all YouTube links. What thirty years of working on human-facing websites has taught me is that power features like this are used by a very small number of people.

Actually, I'd prefer that apps shared chapter points. That would be a) more respectful of content creators, since sections of shows can be done in context; b) ID3 chapter points are automatically amended with variable DAI, and JSON chapter points could be with use of the ULID.

As to your ULID conversation - (patiently) the way the internet works is that IP addresses and user agents are used for targeting advertising. A big database of those is sold by large companies to help target, too.

Separately , in order to count correct play data, IP addresses and user agents are also used currently. The IAB specification requires this as a method to calculate unique users. The ULID is a method to remove this use of IP addresses and user agents. It is not anything to do with dynamic ad targeting, and much less a replacement.

Now, if you are willing to have a civil conversation, I'm willing to help you learn. But if you're purely here to argue under an anonymous account, I'll simply not engage with you further. Treat others with respect.

[ryan-lp]

When I say that a timestamped link is more helpful than just a link, please don't assume that is a personal insult. The more charitable reading is that I am commenting about the usefulness of timestamped links "themselves" over and above ordinary links, and am in no way trying to suggest that the person is at fault for being unhelpful. I would say "of course" I did not mean it that way, but because our personalities are all diverse, we can never assume how another person thinks, and by the same token we should not assume that the least charitable interpretation is the one to take as true and be vocal about how insulting the other person has just been.

You may not have realised it, but many of the comments you have made (including the ones immediately above) could equally be construed as being insults, patronising and/or condescending, all of those same qualities that you criticise in others. We all have the ability to take offence where no offence was intended, and so I would rather we put those assumptions aside and focus on the arguments for and against each idea.

We are all equal here. There is no need to elevate or degrade someone because of their qualifications or industry background. We all come from diverse backgrounds and we all have valid interests and perspectives to contribute equally. An idea stands on its merits alone and not the person behind it.

I will have to leave it here, sadly. Despite your assumption that I don't think before writing, I actually do think quite a lot before writing, and that is partly because my physical condition makes it impossible for me to both sit at a computer and type for longer than a few minutes at a time. It probably takes about 3 hours for me to get a comment like my last one out to you, and in all of that time, there is necessarily less typing and more thinking. But ultimately I have used up my computer time budget today to defend myself rather than defend my ideas. Next time let's try to focus on the ideas. Ideas which are discussed, debated, reasoned and argued.

[AdrianMachado]

@AdrianMachado - interesting that "create a new asset that is shared to a friend" was chosen as the concept. The podcaster gains no benefit from that new asset (since it isn't registered as a download at their server), and it's a transformative work of a piece of copyrighted material, which needs a copyright owner to agree to. (Facebook will have sorted that in the T&Cs, but a typical podcast app has no such T&C agreement).

Yes that's very true - so product side we upsold watching the full episode whenever you saw a clip. We limited clips to 30s as I believe it falls under fair use. Just wanted to share my 2cents

[theDanielJLewis]

I wonder if there might be a different way to approach this that could address the different needs and interests.

Nearly all dynamic content-insertion (DCI) tech affects only the media file and nothing else. Chapters in the external episode metadata file might be redownload while listening, so you can't put DCI information in there since a metadata download today might not match with the media downloaded yesterday.

So here's the idea. We propose new ID3 metadata that indicates the timestamp and length of DCI content. Being in the ID3, it can be written at the same time the media is edited and delivered. I could foresee "streaming" might be an issue, but most "streaming" is actually just progressively downloading the full episode in the background while you start playing. So it's very possible the enter file will download while you're still listening to the first few seconds. Much larger files might be downloaded in chunks (like I've seen 50 MB chunks before, but I'm not sure any apps still do this anymore).

But anyway, with those timestamps and lengths in the media file itself, a podcast app could read it and then automatically shift the timestamps for any timestamped metadata in the episode: chapters, notes, images, comments, boostagrams, transcripts, time-based value splits, and more. Thus, this external metadata could always match what the file actually contains, without the DCI tools having to edit any of the external metadata.

[ryan-lp]

This idea is discussed in #175 with the ID3 tags also being proposed in https://github.com/Podcastindex-org/podcast-namespace/issues/175#issuecomment-773387297

The objection was that it makes it easy for app developers to skip ads. Even if the proposal were to cover DCI more broadly, most of that content in practice would be ads because ad revenue drives business models, and so it could still in practice be used to skip ads. I don't actually disagree with you, and I have already given my own response to that objection, but do you also have a response?

My response has been that security through obscurity just doesn't work, in that once a solution is developed and freely published, the means by which an app developer can query the ad insertion points (or DCI points) will not be substantively different from if they were included in the ID3 tags.

One can imagine, for example, creating a fork of the Transcriptator library that gives you the insertion points as part of its API. For the app developer who uses a library to do the work anyway, there would be no difference as to whether the insertion points were in the ID3 tags, or in the RSS feed, or automatically inferred using efficient algorithms that have now (because of the very introduction of transcripts themselves) become very practical.

I have also mentioned that my particular use case is a podcast search engine. If the ad insertion points were available to me, would I use them to skip ads? Yes, I certainly would. The search engine will simply not function correctly unless only the static content were indexed. So I really have two options: One is to filter out just the dynamically inserted content, so that only the static content is indexed (that would be enabled by #175), and the other is to filter out the entire episodes or entire podcasts (that would be enabled by this issue, #254). I actually don't mind which of those two options I take, so having a simple boolean flag as proposed in this issue to indicate that an episode or podcast dynamically adjusts timestamps would be a compromise I think both the advertisers and search engines could agree to because it would allow the advertisers to still implement security through obscurity, while also signalling to the search engines which episodes and podcasts should be excluded to allow the search engine to function correctly.

[theDanielJLewis]

The objection was that it makes it easy for app developers to skip ads. Even if the proposal were to cover DCI more broadly, most of that content in practice would be ads because ad revenue drives business models, and so it could still in practice be used to skip ads. I don't actually disagree with you, and I have already given my own response to that objection, but do you also have a response?

Ugh. Ads ruin many things. That's my response.

My broader concern is that I'd like to see us solve the timeshift problem with DCI more than making a boolean to indicate "this episode's timestamps are nearly worthless because it might have ads."

But on the "bright" (?) side, I think we'll potentially see FTC and other government organizations start to actually require disclosing the timestamps and lengths of all compensated endorsements (no matter the compensation method). So I believe that podcasters will be forced into this scenario of essentially providing the means for ads to be skipped anyway.