Speaker 0: Beware these 7 deadly sins in podcast hosting providers.
Thank you for joining me for The Audacity to Podcast.
I'm Daniel J. Lewis.
There are plenty of great podcast hosting providers, but some of
them are committing podcasting sins that could make it harder for
you to use those providers or impair your podcast performance.
I won't shame any hosting providers in this episode because
although some of them are doing things wrongly at the time of
publishing this episode, they might fix these problems later,
maybe even by the time you're hearing this episode.
But I will praise some companies that do things correctly.
And keep in mind that just because I don't praise a particular
company doesn't necessarily mean they're doing it wrong.
If you'd like to follow along in the notes for this episode, they
are a simple tap or swipe away or at the idacityto
podcast.com/hostingsins.
Sin number 1, not redirecting your podcast RSS feed.
If you use your podcast hosting provider's RSS feed for
publishing your podcast, what happens if you ever want to leave
that provider?
You need to take your audience with you and not cause any
interruption in their consumption of your podcast.
What hosting providers should do is allow you to permanently
redirect their feed URL for your podcast to your new feed URL,
and this must be a 3 0 1 permanent redirect.
Ideally, it should remain redirecting forever and ever, forever,
and ever. Hallelujah. Yes. Hallelujah.
If they redirect it forever, at least they should redirect it for
a year, but really forever.
And you can learn more about redirects and how to use redirects
in podcasting in my episode 280.
I've got the link to that in the notes.
Tap or swipe away or at the audacitytopodcast.com/hostingsins.
In short, they're like a change of address when you use a 3 0 1
redirect or any kind of redirect.
Kind of like you would use with your local postal provider.
When you do that at the local post office, for example, you're
asking for everything to forward to your new address.
And sometimes you even have a special service that notifies
everyone sending mail to your old address so they know that
you've permanently moved and where they should send the mail from
now on. 3 0 1 permanent redirects work that same way.
And by permanent, that doesn't mean forever in this case.
Even though the redirect should stay there forever, the meaning
isn't necessarily forever.
But it means it's never going to use that old URL again.
A 3 0 1 redirect will then immediately forward any request for
your RSS feed to the new feed URL without even loading any
content from that old feed.
There doesn't even have to be content there.
It can simply be a URL that's redirecting.
So whatever is in that old RSS feed doesn't matter if it's
redirecting through any kind of standard redirect.
But a 3 0 2 and a 3 0 7 redirect are both temporary redirects
that can do the same thing, but the main difference is that 3 0 1
part and the 3 0 2 and the 3 0 7.
Those are technical computer codes that send that code back to
the apps, telling them, in the case of a 3 0 1, that the feed URL
has permanently changed.
It will never be at that old URL again, and thus, the app should
stop looking at that old URL and look only at the new URL.
At least, that's how smartly developed apps are supposed to
handle it.
I think there are some apps out there that don't do that.
When they see a 3 0 1 redirect, they'll just check it every time
and forward to the new feed.
But what they should do is they check it once and they see, oh,
it's a 3 0 1 redirect. I should never check this ever again.
And instead, I should get the feed from whatever this redirect is
pointing me to. That's the way the app should work.
And shame on those apps that don't work that way.
If you can't forward your old feed URL to your new 1, then you
effectively lose almost your entire audience when you switch
hosting providers.
That's why it's so important to have this control.
Even if you don't own the actual URL, and whatever brand is in
the feed URL doesn't actually matter, whether that's Libsyn or
Captivate or even FeedBurn or anything like that.
Whatever brand is in that URL, whatever it says does not matter.
Whatever the slug is does not matter.
What matters is that you have the control to point that URL where
you want it to go if you ever need it to go somewhere else.
But it's a good thing that most hosting providers, and certainly
all the ones that I recommend, do offer feed redirects as an
option.
Years ago, Libsyn used to charge a 1 time fee to create that
permanent redirect for your feed, but they stopped charging for
that several years ago.
If you absolutely must use a hosting provider that does not offer
feed redirects, then use a third party service like Blubrry's
Podcast Mirror or even FeedBurner in its very raw vanilla state
to protect your feed URL so that if you ever need to change, you
can just switch that in that third party service.
But ideally, you shouldn't have to use that because you should
just be using whatever feed performs the best from your feed
hosting provider, and that would redirect if you ever need to
move from that.
Whether that's a feed hosting provider, a podcast hosting
provider, your own website, your own domain, whatever it is, you
need to be able to redirect that.
And ideally, that redirect should remain in place for forever and
ever. Hallelujah. Hallelujah.
Send number 2, using unpredictable media URLs.
Each episode of your podcast has its own unique URL for the media
file.
For example, my episode URLs on Libsyn are structured like this,
httpscolon//traffic.libsyn.com/noodlemx. Yes.
My old network name is still in there, but that doesn't matter.
Did you even know that was in my URL for my media?
So it's /noodlemx/tap411.mpthree.
And that tap 411DotMP3, that's the filename of my episode.
That's how I save it on my computer.
That's how I upload it to Libsyn, and it's still there in the
URL.
And that is the actual m p3 URL for this very episode, and I knew
it would be that exact URL before publishing this episode because
it's completely predictable.
I know that for each episode, the only thing that will change is
the filename, and that will be the same filename as what I
upload.
So for episode 4 12, it will be that exact same URL, but the
filename will be tap 4 12 dot m p 3.
Blubrry and a few other providers also work this way too, and
that's fantastic that they do.
But some hosting providers use seemingly random characters in the
media URLs.
For example, 1 provider would make my episode URL look like
httpscolon//provider.com, whatever that provider is, /mediaslash,
and then a string of completely random characters
/tap411.mpthree.
That would be okay if that string of random characters was unique
to your podcast and repeated across all your episodes so that,
like Libsyn and Blueberry, the only part that changes per episode
would be the filename for each episode.
And you would know that filename because you made it and you
uploaded it. But that's not how those other providers work.
In fact, some that I really like don't work this way.
Those random characters are different for every episode.
So that URL for the m p 3 file is completely unpredictable
because that string of random characters changes every time.
This is bad because it makes it extremely cumbersome to migrate
to that hosting provider.
You'd think they'd make this easier for people to migrate to
them.
It's hard when you have embedded episodes on your website,
whether you've embedded a built in player through a WordPress
plugin or something like that that your provider for your website
offers you, or if you're using your hosting provider's player,
like from Captivate or Libsyn or whoever.
So when you're doing that and you're trying to migrate to 1 of
these hosting providers that does not use a predictable URL, you
can't run any kind of find and replace operation on your website
database to replace all them old media URLs or embed codes with
the new ones because the new URLs contain a string of characters
that's different for each episode.
Not even regular expressions would help here if you're familiar
with how to do regular expressions, wildcards, and all kinds of
fancy things like that.
However, regular expressions could help you migrate away from
such a hosting provider because you could use a wildcard for that
random string.
So you're searching for hostingprovider.com/media/wildcard/ and
replacing that with whatever your new URL is, leaving the
filename the same.
That is as long as your episode filenames stay the same between
your hosting providers.
And that's the other way some providers commit this sin.
I was trying to help my friend Jessica Rhodes from Interview
Connections facing this even worse version of this issue, and
thanks to Jessica for inspiring this episode.
She was working with a provider that did actually keep the same
path for the media URLs.
That's everything except the file name, but they replaced the
filenames with something random and completely unpredictable.
So absolutely no systematic find and replace operation could
migrate to or from that, even with regular expressions. Shame.
Shame on you.
The only way to change all the past embedded episodes then is to
update them all manually. And ain't nobody got time for that.
If you're looking at a new hosting provider, check the media URLs
for multiple episodes of another show hosted with that same
provider and see if those URLs follow predictable patterns.
Don't just see random characters and think, oh, no. That's bad.
Look for if those random characters change for every episode.
Too many providers do it this way, and they don't have to.
Frankly, I think they do it because either they're ignorant of
the problems they're creating or worse, they're apathetic and
lazy.
And an aside to this, this is something I knew I wanted to avoid
with a feature that I built into PodChapters that helps you
create chapters for your podcast and can even host your chapters
and your transcript by giving you URLs for those things.
So that's where this comes into play.
Although the URLs from PodChapters look random, the randomized
part of each URL is actually an account wide string that never
changes.
So for each episode, the only thing that changes is the name of
that episode file, which is based on whatever you upload.
So if you know the name of the file you're uploading, you can
predict what the URL will be.
For example, I already know that the transcript URL for this very
episode will be
httpscolon//storage.podchapters.com/j973bkwgxk3jpd4j3mw02g6b717p8s52/tap411/transcript.vtt.
With only that tap 4 1 1 part being unique but predictable for
each of my episodes, that whole random string of characters that
I read off to you, and that is exactly what it would be.
I think I got all of those right.
It is the same for every episode because that is an account wide
stream.
So that this is I kind of called this the Adam Curry feature in
my planning for this because something that Adam does when he
publishes an episode of any of his podcasts is he publishes the
episode first because he wants to get it out there to his
audience as quickly as possible.
He goes back and adds the chapters later or someone does that for
him.
So he wants to be able to link to the chapters and the transcript
right away.
So he needs a predictable URL even if there's nothing at that URL
yet or it's empty.
That's something that you can do with a predictable URL like
that.
And that's why I built that into PodChapters that way, because I
I wanted it to be predictable so that podcasters could put that
in and simply replace that 1 little part with what they already
know it should contain.
But if your media URLs with your hosting provider change and have
random characters that change for each episode, you have no
predictable pattern that makes it very difficult to migrate to
them and also migrate from them.
You would think that if it made it harder to migrate away from
them, that that would at least justify why they might be not so
interested in enabling that, but they're also might making it
even harder to migrate to them because of this problem.
And if you're facing the same problem, please let the new hosting
provider know because some of them think this is not a problem.
If it is a problem for you, please let them know that it's a
problem so that they can fix it.
Send number 3, changing your GUIDs.
GUID stands for globally unique identifier, and there are 2 types
in podcasting. 1 for each episode and 1 for your whole podcast.
The podcast GUID was born from podcasting 2.
Even though it will be generated based on your feed URL when the
GUID is first generated, that GUID should never change after
that, even if your feed URL changes.
Because you can't reverse decode the GUID to figure out the feed
URL.
It's just we're giving you this ID at this moment, and no matter
what your feed URL is after this, that GUID should never change.
Any good hosting provider should automatically inherit the same
podcast GUID when you migrate your feed.
Blubrry, Buzzsprout, and I think Captivate, several other
providers do this properly for you when you're migrating your
feed to them.
Your episode GUIDs are actually even more important.
What is in the episode GUID doesn't actually matter.
For example, any feed generated with WordPress usually uses your
WordPress post ID number in a URL so that doesn't change even if
you change the friendly or SEO friendly URL, but it's using a
post ID that is hard coded into the database and you can't change
that post ID number.
But that's being used inside of your WordPress site.
So for example, for The Audacity to Podcast, 1 of the GUIDs might
be h t t p colon slash / the audacitytopodcast.com/ question mark
p equals 7 3 7.
I I don't know what's a 7 3 7, but that's an example of a GUID.
Now even though it looks like a URL, it's not treated like a URL.
Some publishing tools make it a completely random string of
characters, and either of these are perfectly acceptable because
what's in the GUID is not what's important.
What is important is that they never change.
So the SYN is when those GUIDs or some people pronounce them
GUIDs are changed either when you migrate to that provider or
publishing tool or if they have to change something in their back
end and that might change your GUIDs.
This might be a problem that you run into if you do some kind of
find and replace on your own WordPress database, and your
WordPress site is creating your RSS feed.
Make sure that any kind of find and replace operation does not
affect the post GUIDs.
And you can run into this also, for example, if you're changing
from HTTP to HTTPS. The GUIDs should not change.
And what's in them, again, does not actually matter.
What matters that is that they not change because they are
treated as IDs, identifiers, not as actual URLs.
Although there is a technical thing that can treat them like
URLs, but generally, they're not considered to be URLs.
Nearly all podcast apps use the GUIDs to track which episodes
have been played, which have been downloaded, which have been
ignored and such. That's why the GUIDs are so important.
That's how the apps know which episode is which and what you've
done with those episodes.
If an episode's GUID is changed, like, everything else could
remain exactly the same about the episode in your RSS feed, even
the media file and its URL don't change at all.
But if the GUID is changed, nearly all podcast apps will think
it's a new episode and redownload it.
And that will then mess up your stats and probably confuse and
maybe even frustrate your audience. Just don't do that.
Don't let that be done to your podcast either.
Most podcast hosting providers properly migrate the episode GUIDs
on migration to them, but some might not.
So if you're migrating your podcast to a lesser known, less
popular hosting provider, then definitely ask them.
Check with them. Even check your own RSS feed.
Look at your old RSS feed.
Look at the new 1 after they've completed their migration, and
look for the GUID tag.
It will be all lowercase, GUID, and check it for a few episodes
and make sure they are exactly the same.
Same capitalization even might matter in some cases.
They should be exactly the same, not a single character or
capitalization off, not 1 jot or tittle off.
Sin number 4, improperly constructing your RSS feed.
We're finally moving away from some of these migration related
sins.
Some hosting providers and publishing tools do bad things inside
your RSS feed.
Sometimes it's for some concern for compatibility, maybe, but it
seems to usually be from ignorance or oversight.
Here are some examples.
And again, I am not going to name who makes these mistakes
because they might fix these problems, especially if they get a
hold of this episode.
And if you know who those hosting providers are, feel free to
send them this episode, but I am not going to throw anyone under
the bus, at least not yet. Here are some examples for this.
A popular podcast hosting provider puts the same text in 3
separate RSS tags on the same episode, and those tags are content
encoded, description, and even the deprecated iTunes summary.
So it's the same exact text in 3 places for that episode.
And then multiply that by how many episodes are in your feed, and
that's a lot of wasted space.
And it's really not even necessary to have all of those
populated.
I think all podcast apps will fall back to the description tag if
nothing else is populated there for your show notes or the
description of the episode.
So it's really not necessary to have all 3 of them there,
especially not necessary for all 3 of them to contain the exact
same text.
That same hosting provider is guilty of another example here, and
a few others make this mistake, and that is the enclosure tag.
This is what turns an RSS feed into a podcast feed, is the
enclosure.
That's where your m p 3 file or other media file is linked.
It's supposed to have an attribute to it called length, and that
is supposed to be set to the size of the file, the actual file
size in bytes, not kilobytes, megabytes, or anything like that.
And some of these hosting providers, the same 1 that I just gave
an example from, put the number 0 in there. So link equals 0. No.
You should not do that.
You should put in there the file size in bytes.
A different problem is that a few popular hosting providers
incorrectly populate your episodes iTunes title and normal title
tags with the exact same text.
That's unnecessary for them to be the same, and it's redundant.
But it's even worse if your podcast needs episode numbers because
some of these places that do this where they're putting the same
title text in both title fields, which is unnecessary to do, they
let you put in an episode number, and they put that episode
number in the iTunes episode tag, and that is the right place for
the episode number, but they don't do anything else with that
episode number.
And that's the whole reason the iTunes title tag exists is so
that you can put a title in there without an episode number in
it.
So you can split the episode number into that iTunes episode tag.
But then the regular title tag should still contain the episode
number.
And this is if episode numbers are important for your podcast.
And I'm going to do an episode coming up soon about episode
numbers again because I've changed my mind on when it is
important for your episode to have and use episode numbers.
But if you're using episode numbers and if you want your audience
to see those episode numbers, then for full compatibility, they
need to be in the normal title tag, and they should not be in the
iTunes title tag.
There's some misunderstanding and misinformation out there about
how these tags are supposed to be used, but this is the way it's
supposed to be, is that the title tag is what nearly all podcast
apps support.
Only a few podcast apps support iTunes title and iTunes episode.
So they would then display the episode numbers separately.
I think Fireside is the only hosting provider that does this in a
smart way.
And rss.com might be changing to this similar because they asked
me a whole lot of questions about this.
I got to demonstrate to them this is how this is working.
These are some ways that you could work with this to make this
better.
But Captivate, PowerPress, Libsyn, and some others do allow you
to manually edit these separate title tags separately so that 1
can contain an episode number in it.
That would be your normal title.
And the iTunes or Apple title would not contain the episode
number because you would put that episode number in the episode
field.
But the smartest way to do this is, I think, what Fireside does,
and I've built this into a plug in for PowerPress that I hope to
release to the public someday, where you can populate that
episode number field, and then it automatically adds that to the
normal title field at the beginning.
So it'd be, like, 5 period space and then the rest of your
episode title, but it excludes it from the iTunes title tag.
And someday when there's a podcast colon title tag, it would
exclude it from there too. That's the smart way to do it.
The next best way to do it is what some of these other providers
do, that is they let you have an additional field where you can
enter these titles separately.
That's not exactly the best way to do it, but it at least it does
give you full control to do it exactly the way you want it to be.
Moving on, some providers and publishing tools ignore the iTunes
colon duration tag.
It is optional, but it's very helpful for podcast apps.
Unfortunately, Apple says different duration formats are
accepted.
However, it is recommended to convert the length of the episode
into seconds. Okay. Yeah.
But they're also saying that something like minutes colon seconds
could work if you're putting that format in there.
I wish they would just say, this is the way it should be done and
only this way.
But some publishing tools don't put that in there at all.
And so if your feed doesn't have that, then some podcast apps
might not be able to display to the user how long the episode
actually is unless those podcast apps start downloading the file
and then pull information from the file itself.
Another example of something that these publishing tools and
providers do is that some providers incorrectly format the
episode's pub date tag.
That's supposed to be, as you could probably guess, the date of
publication, and it's supposed to follow a very specific date
format, which unfortunately not all providers respect.
Surprisingly, Hubbell makes this tag only recommended instead of
required.
Moving on, some providers don't let you change the link URL for
your episodes.
This is crucial when your episode web page is somewhere other
than on the website your podcast hosting provider gives you.
Libsyn, Captivate, and Buzzsprout all let you edit this link.
PowerPress doesn't really need to let you edit it because the
primary usage of PowerPress is making a podcast feed from your
own site.
So the episode links are already pointing to your own web page
for that episode.
That's why you don't need to edit it if you're using PowerPress.
But if you're using some other publishing tool and you're using
that separate from your website, you need to be able to set that
link to the web page for your episode because many podcast apps
will let the audience member tap on a link to visit the web page
for the episode.
And you don't want them going to some ugly looking website that
you haven't done any branding on.
You want them to go to your website.
So you need to be able to set that link, and some providers don't
let you set that.
Some of these examples I've given, you might uncover by looking
at the raw XML code for a podcast RSS feed from each provider.
Now that's a lot of letters I just said, so that might scare you
a bit.
But for example, you might see enclosure with length equals
quotation 0 quotation.
If you see that in the feed, then you can know they're doing it
wrong.
Some of these other things, like how they're handling the link
tag or description or content encoded and some of this other
stuff might be an oversight on the podcaster's part and not the
fault of the hosting provider.
Unfortunately, some of these things you might just not discover
until you actually start using that podcast hosting provider.
That's what I ran into a few months ago when I was considering
moving my hosting provider and how I was generating my RSS feed.
There are several hosting providers I really like.
But for myself, not for you necessarily that I would recommend
that you do some of these things, but for myself, there were some
very, very specific things that I wanted to do with my podcast
RSS feed and certain ways I wanted it to behave.
And it wasn't until I actually started using some of these
providers that I discovered, oh, they don't do this right.
Or at least how I create my podcast.
They're not handling this particular thing in the right way.
Like, the iTunes title thing is 1 of those things that couple of
hosting providers that I tried didn't handle that properly.
Or there were a couple of other things where I didn't have the
control that I wanted, and so I ended up just deciding to stick
with PowerPress and making an extension to PowerPress that would
make certain things behave exactly how I want them to behave, as
well as some other cool things too to support some cutting edge
features.
I'd love to release that plug in for free in the future.
We'll see if I can do that.
There are just some legal issues I need to work through.
Not that I'm in trouble.
I want to make sure I respect certain trademarks and such.
So I'm talking to the trademark owners to make sure that I do
this respectfully in a way that they're okay with.
You can watch for that. I'll let you know when I release that.
Moving on to sin number 5, stripping important data from your
episodes.
M p threes can hold a lot of important pieces of data that are
good for compatibility and sometimes vital for certain
functionality and workflows in your podcasting.
For example, you can add your episode artwork to the m p 3, and
your hosting provider might automatically read that image and
save it to the RSS feed for the iTunes image and maybe even the
podcast image for podcasting 2, and maybe embed it on the web
page for that episode.
Captivate, Buzzsprout, Blubrry, and many other providers either
use that image conveniently or in the least, they keep the image
in the m p 3, and they don't strip it out or do anything bad to
it.
Before you think it's unnecessary for that image to be in the m p
3, regardless of the workflow aspects of this, there are some
podcast apps that actually use that image for the episode image.
So if episode specific images are important to you, then you need
to make sure that your hosting provider is not committing this
sin.
Overcast, for example, still gets its image for your episode from
the m p 3 file.
And if there isn't an image in your m p 3 file, then Overcast
will fall back to your top level podcast cover art to display for
that episode. And there's nothing wrong with that.
But if you want episode specific artwork, then you have to put it
in your m p 3 file, and your hosting provider has to keep that
image there in the m p 3 file, as well as put it in other places
for optimal compatibility.
The other important data in your episode could be legacy chapters
embedded in the m p 3.
Pod chapters exports chapters in your m p 3 and as JSON code for
podcasting 2 and as XML code for PodLove simple chapters as well
as some other formats that exports that you can use in different
ways. So try it out.
Try PodChapters free for 7 days over at podchapters.com.
But even if your hosting provider doesn't support modern chapters
like Podcasting 2 or even PodLove simple chapters, which aren't
the most modern, but they're still more modern than the legacy m
3 chapters.
Or even if they don't give you the option to paste in a URL for
your Podcasting 2 chapters, like what PodChapters can host for
you, they should at least still read the chapters from the m p 3
file and keep them there.
What would be better is that they read those chapters from the m
p 3 data and then copy them to the other formats.
This is why PodChapters is still useful and likely much better
than the tools that you get with your podcast hosting provider
for making chapters.
Because you can create your chapters with PodChapters, embed them
in the m p 3, and then upload them to some of these publishing
tools and hosting providers, and they will read those chapters
and copy them to the other places.
For example, Buzzsprout does this really well, where when you
upload your m p 3 that already has chapters in it, even though
you can't give Buzzsprout your podcasting 2 chapters, if your m p
3 file has chapters in it, Buzzsprout will copy those chapters to
podcasting 2 format and Podlove simple chapters.
So, again, it's about the workflow in this case, not just the
compatibility, but the workflow is there to go from 1 format to
the other because your hosting provider is doing that for you.
Captivate, Buzzsprout, Blubrry, and Libsyn all keep your m p
threes embedded chapters untouched, unless you use their chapter
tools to change those chapters.
Then, of course, they're going to edit the chapters.
But if you upload chapters just the way you want them, then those
providers will not change those chapters.
But some providers won't copy all the chapter data, or they
actually completely remove your chapters.
For example, 1 popular provider will properly read your chapter
titles and time stamps, and that might be enough for you.
But chapters can also contain links and images.
But this provider that I'm referring to doesn't copy those links
and images into the other chapters.
Even though they'll copy your titles and the correct time stamps
into your podcasting 2 chapters, they won't copy any links you
have or any images you have.
You'll have to re add those in their system.
That's something they're aware of, this particular provider I'm
thinking of, and it's something I would love to see them fix.
So if you're using PodChapters and you're using this other
provider and you know who they are and you know the shortcoming
that they have, please kindly request that they fix it.
Sin number 6, not optimizing your media.
There are, unfortunately, still several technical standards
podcasters need to know about.
But I would love to see these be unnecessary for you to ever
think about because your hosting provider and publishing tools
optimize those things appropriately for you.
For example, Buzzsprout's base plan will re encode your podcast
audio down to 96 kilobits per second mono only if you upload
something higher than that.
This ensures you're publishing the right format of media and at
an optimal quality level.
You could also upgrade your Buzzsprout account to include what
they call magic mastering, so they fix your loudness levels
automatically and even let you publish in stereo.
Those are both really smart features that they support. Yeah.
At an additional cost, but that might be worth it to you if you
don't want to do that stuff like the magic mastering and the
loudness levels and stuff.
If you don't want to manage that before you upload, they can fix
that for you after you upload.
Or do it yourself, and you don't have to pay for that upgrade.
But they do a really good job at it.
But some hosting providers will let you upload anything, even an
uncompressed WAV file that could be a 100 times bigger than it
should be, or another audio file format that most podcast apps
don't support.
And they'll just let you publish your episode like that.
And you might never realize it's broken until your audience says,
hey, your episode doesn't play, and you're trying to figure out
why is it broken, why isn't it working.
You're going back and forth. I uploaded this audio file.
The audio file plays perfectly on my computer. I upload it again.
It still plays perfectly. Why isn't it working in my RSS feed?
And you might realize then or maybe the hosting provider points
out to you, oh, hey, you uploaded an uncompressed WAV file and
yet filled up your account, and don't do that.
You shouldn't publish WAV files.
You need to publish an m p 3 or another popular audio or video
format depending on what you're publishing.
Their system should do that for you automatically.
It should convert it from WAV to m p 3 in the correct format for
you if you're uploading the wrong format.
But if you upload the right format, they shouldn't convert it.
That you shouldn't have to worry about it.
Either way, you should just be able to upload your audio and know
that it will publish in the correct format.
Images are another thing related to this.
Some providers let you upload any kind of image, even Photoshop
files.
But they might let you upload an image that's too big or too
small, that's in file size or pixel dimensions, or maybe it's the
wrong shape, like it's rectangular instead of square, or its
other technical specs are incorrect.
Ideally, the publishing tool should warn you when you're
uploading something with the wrong specs and potentially and
optimally provide the tools to fix that.
Like if it's too big, file size or dimensions, it could pop up a
little warning that says, hey, this file is too big.
Click here and we'll optimize it. Or hey, this is too big.
We've automatically optimized it for you without compromising the
visual quality of it. Anything like that would be really cool.
On Pod chapters, I'm working to make it do some of this
optimization automatically or with a simple press of a button.
For example, although some of these chapter images can be in your
MP 3 file, they really shouldn't be big images by pixel size and
especially by file size.
So what could happen is that when you upload an image that's too
big for a chapter, Pod chapters could automatically downscale
that image for the embedded chapters, where a small size is
really important, and then do different optimizations for the
Podcasting 2 and PodLove chapters.
That way, you don't have to think about it.
It just does it automatically for you and does it the correct way
so that you don't have to worry at all.
The same could go for text data too.
Publishing tools should strip out unnecessary HTML code or weird
formatting like you might frequently get, and maybe you've even
run into this in the past when you're pasting from a document
editing app like Microsoft Word or Google Docs or even sometimes
Notepad or a Notes app can have certain hidden formatting in it
that starts to just make stuff look weird or function weirdly
inside your podcast app or it breaks something weird.
And speaking of breaking things, they should also automatically
validate your RSS feed.
Now if they're not doing these optimizations, this isn't
necessarily the worst sin.
That's why this is farther down the list. Not necessarily.
It's probably the lowest priority, but I've got this in this
particular order because of the flow.
And of course, many of these things shouldn't really matter if
you do things right on your side.
Like the whole uploading a WAV file and having the hosting
provider convert it to an m p 3 file for you.
That shouldn't matter if you're giving an m p 3 file that is
already in the correct format.
But I believe that podcasters shouldn't have to know these
technical things like bit rates and loudness levels and image
compression and image formats and dimensions and file sizes and
all of that stuff.
I want podcasting to just work so you can focus more on your
content and your audience.
And that's why many of the tools that I create now, especially
the 2 biggest tools I have, Podgagement and PodChapters, there
are a lot of things that I've put into this with deep love and
passion for podcasting.
Certain things that I want it to just work so you don't have to
think about it. Just throwing out another example here.
In Podgagement, you get multiple landing pages, like a
followthepodcast.com and lovethepodcast.com that can display
links to your podcast in different apps.
Those pages automatically, smartly show and hide certain apps
based on what kind of device is visiting the page.
So if someone is on Android, for example, they won't see an Apple
Podcast link or an Overcast link because those are for Apple
products generally.
If someone is on Windows, they will see an iTunes link because it
is still iTunes on Windows, and they'll see that instead of Apple
Podcasts.
And if someone is on an Apple device, they won't see, for
example, a Podcast Addict link because Podcast Addict is only for
Android. So they shouldn't see Android apps.
That kind of thing, the landing pages just do that automatically.
You shouldn't have to think about it.
You should just know, I send people to this page.
They'll see links that can work on their devices, so you don't
have to think about it.
And so, certainly, you don't have to try and code that
information yourself.
So right after saying sin number 6 is not optimizing your media,
sin number 7 is unnecessarily optimizing your media. Yes.
Sometimes your media should not be optimized.
Years ago, I stumbled into running multiple performance tests on
podcast hosting providers, and I made some interesting additional
discoveries in that process.
1 of those discoveries was that some hosting providers would
forcefully re encode your m p threes even if you had already
encoded them to the spec perfectly.
1 provider actually re encoded up to a higher level.
So if you uploaded a 64 kilobit per second mono file, they might
re encode it up to, we'll just say, 128 kilobits per second
stereo. There was no need for them to do that.
Or if they were even going up to 96 or 1 20 or 1 60 or any higher
number, there's no need for them to do that.
It's not improving the audio quality.
It's only wasting space and bandwidth and processing time.
Some providers don't re encode your media no matter what and see
SIN number 6 for that.
But I like the way Buzzsprout handles this.
They will only re encode down if your media file is above their
spec.
But if you upload an m p 3 file that's already at or below their
spec, they won't re encode it.
So if you upload 96 kilobits per second mono, Buzzsprout does not
re encode it.
If you upload 64 kilobits per second mono, Buzzsprout does not re
encode it.
Similarly, with Captivate and Blubrry and Libsyn and several
other podcast hosting providers, they will not unnecessarily re
encode your media.
And that's good that they don't re encode it when it shouldn't be
re encoded Because some of these platforms are just trusting that
you know what you're doing and that you encoded it properly or
whatever publishing tool you're using to create the m p 3 file
did it correctly for you.
But hosting providers should not re encode it if it doesn't have
to be re encoded.
There's 1 particular provider that's been on multiple of these
naughty lists and things I've mentioned in here.
They're committing multiple sins.
And what they do is they forcefully re encode the file even at
the exact same encoding specs.
But for some reason, their re encoded version ends up bigger than
what the podcaster uploaded, and they stripped the chapters
completely from it.
And 1 of my listeners knows exactly what I'm talking about
because they signed up for PodChapters.
They were so excited to use PodChapters to create chapters for
their podcast. They added all these great chapters.
They loved how PodChapters work.
They uploaded it to their podcast hosting provider that their
podcast network uses, and they couldn't figure out why their
chapters weren't working.
And the reason is their hosting provider stripped the chapters
and metadata from the file, reencoded it unnecessarily, and
that's probably why all the metadata was stripped from it, losing
all of those chapters.
And they served that reencoded version even though their
reencoded version was at the exact same encoding specs as what
the podcaster uploaded, but the hosting provider's version was a
bigger file. Make it make sense.
They're certainly not doing it correctly. Shame on them. Shame.
Shame. A similar thing can happen with images.
Maybe you upload a perfectly compressed image that is optimized
to whatever pixel level degree that you want.
And it maybe it's only 20 kilobytes in size.
But the publishing tool then automatically converts that image to
a different format, possibly making the file size 10 times larger
than it needs to be, or maybe even making the image look worse
depending on the compression method that they're using for that
image.
Just for example here, PNG is really good for images that contain
a lot of solid color, Like The Audacity to Podcast cover art is
great in PNG.
And most of the episode images that I make work really well in
PNG.
And that's why I save them as PNG because they have a lot of
solid colors, and they're not very varied in colors.
They're not photographs or anything. They're illustrations.
They look like vector while they're made from vector art, which
is scalable. So they work really well as PNGs.
Convert the same image to a JPEG, and it's going to be a much
bigger file if you try to maintain the same crispness.
If you try to get its file size down to the same size as the PNG,
then it starts getting blocky and blurry.
I don't want any system that does that, that unnecessarily tries
to optimize my file by converting it to JPEG when I wanted it to
stay as PNG because the PNG I gave is the proper format.
So these 7 deadly sins that podcast hosting providers might be
committing are number 1, not redirecting your RSS feed.
Number 2, using unpredictable media URLs.
Number 3, changing your GUIDs.
Number 4, improperly constructing your RSS feed.
Number 5, stripping important data from your episodes.
Number 6, not optimizing your media.
And number 7, unnecessarily optimizing your media.
If you catch your hosting provider committing 1 of these sins,
feel free to send them this episode.
And know that I have not put anyone under the bus here.
Although, some providers, I think, kinda deserve it, but I'm not
going to do that because I want to give them the chance to
improve things.
And you can send them this episode to point out to them, this is
why this matters. Here's more information about this.
This is really important to me, and I think maybe some other
podcasters, please change this.
So if you send anything to your podcast hosting provider, if you
complain, please do it kindly and give them the chance to make
things right.
And if they won't, then you could consider switching.
And if you need help, let me know who you're looking at and what
particular features are most important to you, and I can help you
pick the right hosting provider for you.
Because I don't recommend just 1 particular provider.
And by the way, if you look at the notes for this episode, some
of my links will be affiliate links.
And that's because many of these providers, I do recommend in
certain context for certain uses.
So depending on what you need, I'll recommend the hosting
provider for you.
The links for all of this that I shared, some of these past
episodes and other references are at the audacity to
podcast.com/hostingsends.
Special thanks to Lindsay Phillips who had me on her podcast as a
guest.
Her podcast is leverage your podcast, and she had me on to talk
about engaging your podcast audience.
It was a really fun conversation.
We did talk a lot about Podgagement in that episode, but also
just about engaging your audience in general because that's what
Podgagement was designed to help you do.
So please go listen to that episode from Lindsay Phillips.
I've got the link to that in the notes.
And thanks to Podfest Multimedia Expo for accepting my session
proposal for Podfest 20 26.
I'm thrilled to be sharing what you need to know about podcasting
2 at Podfest, so I would love to have you there in the audience.
Please join me at Podfest January in Orlando, Florida.
I've got the link to podfestexpo.com in the notes or, hey, I just
mentioned the URL for you.
And those notes are once again at the
audacitytopodcast.com/hostingsins.
Now that I've given you some of the guts and taught you some of
the tools, it's time for you to go start and grow your own
podcast for passion and profit.
Please check out my new product, podchapters.com, now available
with a free 7 day trial over at podchapters.com. I'm Daniel J.
Lewis from theaudacitytopodcast.com. Thanks for listening.