-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More audio/video metadata in feed? #60
Comments
Isn't this already available in the |
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 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). |
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.
The text was updated successfully, but these errors were encountered: