staceygoers
commented
3 years ago I advise this not be in the RSS feed, but in the file ID3 tags.
Open swschilke opened 3 years ago
staceygoers
commented
3 years ago I advise this not be in the RSS feed, but in the file ID3 tags.
theDanielJLewis
commented
3 years ago I advise this not be in the RSS feed, but in the file ID3 tags.
Initially, I was going to say this should probably be in the episode metadata file, along with the chapters. But that's on the published side of things and wouldn't apply to the podcast-publishing tool (such as the podcast-hosting provider or content-insertion technology).
Since dynamic insertion can be used for far more than ads, I suggest a more universal name for the tag, such as dynamicContent or insertionPoint.
PofMagicfingers
commented
3 years ago I don't get the point for this. As a podcaster I would say the best position in my podcast where to put ads as a player/podcatcher/etc is : never
If I want ad break, I would like to insert them before hand at editing stage, or my hosting provider would or my advertising network would let me select where to insert them, and would modify the file content before user download it.
I don't see a situation where it could be relevant for a client (player, etc) to do dynamic content insertions. It's something that should be on producer/podcaster side.
swschilke
commented
3 years ago Never is sometimes not possible, some "free" hosts get paid by adding ads to your show. This position is shortsighted. Especially if you want or need to monetize.
The host read ad is fine, but think bigger. You might want to keep the MP3 clear and add, on demand, different ads or announcements, depending on time or location of that listener (on the fly generation of the MP3 which is served for a download request). Imagine a podcast network adding anouncements for their various shows and rotating them once in a while or replacing them with new shows.
In addition I rather choose where and how often I get any form of break instead of at the most inconvenient time for my audio.
I'm okay with a name like dynamic insertation or so.
PofMagicfingers
commented
3 years ago That is in fact to be done at hosting provider level. I don't get the point to add it to the RSS, at client level : podcatcher could simply never play ads ¯_(ツ)_/¯
The scenarios you're describing already exists and works by inserting ads on the fly on hosting providers servers
swschilke
commented
3 years ago Well, a web based player could add ads. Your hosting provider needs to know where he can safely insert adds, there are podcatcher serving ads. If I have to live with that I rarher have control about it.
BTW: Spotify just mentioned that they think about helping the average Joe podcaster to monetize, guess with what? Ads! So, again I rather control where they inject something, instead of letting them ruin my story arc.
The world and things are not always free, but Money makes it turn.
.
PofMagicfingers
commented
3 years ago That doesn't make any sense to me.
You want to monetize through your hosting provider -> your hosting provider should be in charge of that (UI/UX), and for the ad to be reliable, and distributed everywhere, it should be inserted on the fly in the file
You want to monetize through some podcast listening platform -> That platform is in charge to do that, its specific to that platform, and they'll probably provide an UI for this on their dashboard, or some specific proprietary tags
A web based (or not) player is adding ads on podcast without asking permission and where to add them ? -> That's just bad behaviour
I'm not saying you should have or not have ads on podcasts, I'm saying it doesn't make sense to define where adbreaks should be on already published RSS content. No one will enforce it and play ads if they're not forced to do so.
It's the responsibility of the advertising provider to put ads where they should be inside the media file, and it has nothing to do with the client (podcatcher), or the RSS feed.
Podcatcher that do want to play ads should play them in agreements with podcasters, if so they can provide custom tags or an UI to set time for ad breaks.
If Spotify wants to let producers tell them what is the ideal timecode for ads, I'm sure they will create a spotify:adbreak but that's specific to their platform. ( And I bet they'll probably woń't do that : ads are between tracks because it's technically convenient AND annoying enough to make you want to get a subscription)
I could be wrong, but I really do not see in which real life situation this tag could be useful.
theDanielJLewis
commented
3 years ago I don't get the point for this. As a podcaster I would say the best position in my podcast where to put ads as a player/podcatcher/etc is : never
Don't think of it as only ads, but content that can be easily changed across all affected episodes. This works for announcements, time-sensitive content, region-specific information, and more.
But it also seems like this conversation is pointing out that insertion points don't make sense to be published. The podcast-players that might insert ads inside the content would be very unlikely to support this. And currently, I don't think any player inserts ads inside the content accept by special arrangement (Spotify).
PofMagicfingers
commented
3 years ago Yes, that's my opinion on this. Dynamic content (ads or not) should be taken charge of by the hosting provider, and dynamically inserted before download on the file.
It doesn't make sense to put it inside RSS and "hope" most player will support it : that is not reliable enough if you want your ads or annoucements to be played.
swschilke
commented
3 years ago I don't think so, it's more flexible if you can say what, when and where you want this. We could extend the DCI (Dynamic Content Insertation) with a value "No" and that suits you.
PofMagicfingers
commented
3 years ago I'm not saying it would not be a great thing, I'm saying :
daveajones
commented
3 years ago The spirit of what this tag is trying to accomplish makes a lot of sense. But, it may just not have a use case yet. @swschilke have you seen any players that call back for the ad during playback? Are you thinking of apps like Stitcher? Do they call back for the ads during playback or do they embed them beforehand in the audio file before delivery?
If there were a Stitcher type service that takes public podcasts and inserts ads into them (not sure if they do that anymore) on the fly during playback, like web video players often do, I can see the usefulness here. But @staceygoers point is good too, about the audio itself having the markers.
Hmm. I think maybe put this tag on the proposal list pool and then just let it marinate. Over time, if someone wants to start fleshing it out and it gains interest we can return to it later and get more serious about it.
jamescridland
commented
3 years ago Stacey's right - this needs to be in the ID3 tags. Here's the example that would show why:
It's the same audio link from the RSS file, which is - for almost all hosts - identical when served. So, the only sensible way of flagging anything time-coded in the audio, really, is to use ID3 tags.
I'd point to NPR's RAD proposal as a good way to consider marking ad content, since that's what it sets out to do (and RAD functionality is baked-in to Hindenburg and other DAWs).
Clearly at some point in the future, Spotify or Amazon may want to insert ads sympathetically into shows (and pay producers for them). If producers want that, then Spotify or Amazon will doubtless come up with a method of marking the ad breaks: I'd hope that they'd consider the prior art here. However, for now, I'd agree with Dave to park this.
swschilke
commented
3 years ago Sorry, that I believed that people which develop ad Insertation software have actually a brain.
If you have three ad points (timestamps) in the RSS and you use the first ad point with a x seconds ad, the next (2nd) ad point is moved x seconds further (2nd timestamp plus x seconds), at this point you play y seconds of ad. Likewise the third ad point is then moved x+y seconds (3rd timestamp plus x + y seconds). So the time when it's playing is adjusted. That works if you skip the first ad point as well. Just have to keep track where you started (and if you have had ads before, you have to ad their length (all of them) to every ad break which follows)
For me that's Problem solved, isn't?
How would this work if it's embedded in the MP3 / id3 tag? Just by moving bits and bytes further or splicing data bytes in between?!?
I think that proposal has potential and leaves control with the creator especially if we ad a "No" value, so no timestamps for ad breaks (even if you could still put pre-/post-roll ads / announcements with the contents).
.
jamescridland
commented
3 years ago Sorry, that I believed that people which develop ad Insertation software have actually a brain.
It's worth not being rude about the very people you're expecting to implement this work.
The issue is with dynamic ad insertion, which occurs when you request the MP3. It is only at that point when the audio is fixed: when the dynamically-inserted ads are injected into the audio. Until that point, there is no actual MP3 to get any timings from. Unlike broadcast radio, an ad does not have a set duration, or even need to exist at all.
So the RSS feed cannot know the timings of dynamically-inserted ad breaks, since the RSS feed is being consumed at a different time than the MP3 is requested, and is also in most cases being requested by a central RSS scraper rather than by the client.
So the only sensible way of flagging anything time-coded in the audio is to use something within the actual audio as served, which for MP3 feeds is the standard ID3 tags, or the ID3 tags with the RAD markers inside.
(This, as a by-the-way, also means that RSS-specified chapters don't work too well with dynamically-inserted ads.)
swschilke
commented
3 years ago @jamescridland I tried to be sarcastic, which probably seems to have failed. For me it sounded like you assumed that "they" would mess it up (your The Daily example), as that "they" didn't take this into consideration.
Some services (like Spotify) download the MP3 before serving it to the listeners or apps, i.e. podcatcher, could use this as well.
If you work with id3 tags a feasible way would be to adjust all time based tags if you dynamically inserted some content.
I know of one free hoster which is inserting ads to recoup the hosting cost (just can't come up with the name right now) which "forces" you to set at least one ad break timestamp when you upload content.
As I said, before someone else chooses the timestamps they insert ads, I rather tell them where to do it upfront.
.
PofMagicfingers
commented
3 years ago I know of one free hoster which is inserting ads to recoup the hosting cost (just can't come up with the name right now) which "forces" you to set at least one ad break timestamp when you upload content.
That's what I meant when I was saying hoster or ad publisher would be the one providing you a way to set ad break timestamps. They're the one inserting them, they are the one in charge of providing an UX for this (or any technical solution)
Again, IMHO, they won't use a RSS tag because or anything "declarative" because they would have no way to enforce the ad insertion.
If they currently use on the fly modified media files, and not a custom namespace and RSS tag, it's because they could not have faith in all existing podcast player and modifying the file is the most reliable way to have your ads on the final play.
If one day Spotify or any other player adding ads want to let podcasters set their time break timestamp they'll do so with their own UI or rss tag because it will be specific to their platform.
Player inserting ads into podcast content is an exception not the rule.
It would be good if a podcaster could define (several) AdBreak's Tag (with hh:mm:ss as the position/time) which defines the best positions in a podcast where Ads breaks could be (dynamically or static) inserted. Some platforms do something on or in their platform, but doing so it would be a generic way that could be utilized by every player, website, or podcatcher. I.e. everybody who uses the RSS feed could know where it's safe/possible to place an ad.
Not like in YouTube today, where YouTube dumps ads wherever they want.