Open theDanielJLewis opened 3 years ago
Isn't this already available in the <itunes:duration>
?
Yes, but didn't we decide we want the podcast namespace to work without Apple's tags?
This is a big point, because if we want the podcast namespace to work without Apple's tags, then we do need that, as well as episodeType, season, etc. for episodes.
Do you have any guidance here @daveajones ? Does the podcast namespace coexist with the iTunes one, or is it meant to stand alone?
IMHO the namespace should coexist with iTunes until we have enough adoption. At least in the beginning, our efforts should be on extending what is possible in podcasting rather than renaming tags.
What Tom said. The desire for independence is there. But, I see that as something we tackle down the road after a lot of the new ideas have been exhausted. The entrenchment of the itunes namespace will be here for a long time, and that's fine. If there were ever some move by them to restrict their API we should move faster. But, barring that, the overlapping functionality should be pushed off into the future.
I would love to see
"In addition to duration, maybe there would be the need to clearly indicate whether it's audio or video.
So maybe we need something like
It would be great to be able to just find video podcasts - or just PDFs or .....
The Alternate Enclosure standard which needs to be crafted should definitely include more info including audio/video type, length, encoding quality type and maybe even storage protocol (http vs ipfs).
Yes, but didn't we decide we want the podcast namespace to work without Apple's tags?
It would make sense to coexist as long as Apple has a stronghold on the podcasters with the directory and 98%+ is kind of refering back to it.
Like chapters and related to this conversation, I think we need to consider bringing some information usually only in the enclosure file into the feed.
Primarily, I'm thinking about duration.
Unfortunately,
<enclosure length="…">
is not reliable. It's the size of the file in bytes, and you can't determine length from size (get your mind out of the gutter!).For example, 64 kbps and 128 kbps audio will have significantly different
length
values even if the audio is the same duration.Also, two 64 kbps files could have different byte sizes depending on how big the ID3 header information is (significantly affected by the embedded image).
In addition to duration, maybe there would be the need to clearly indicate whether it's audio or video.
So maybe we need something like
<podcast:episodeMedia>
or<podcast:mediaMeta>
with sub-elements for duration.Or merge these needs with the expanded enclosure model so each enclosure can have more metadata for it.