WEBVTT 00:00:00.480 --> 00:00:04.879 Beware these 7 deadly sins in podcast hosting providers. 00:00:11.119 --> 00:00:13.919 Thank you for joining me for The Audacity to Podcast. 00:00:13.919 --> 00:00:14.880 I'm Daniel J. Lewis. 00:00:15.144 --> 00:00:19.144 There are plenty of great podcast hosting providers, but some of 00:00:19.144 --> 00:00:23.464 them are committing podcasting sins that could make it harder for 00:00:23.464 --> 00:00:27.384 you to use those providers or impair your podcast performance. 00:00:27.910 --> 00:00:31.510 I won't shame any hosting providers in this episode because 00:00:31.510 --> 00:00:35.670 although some of them are doing things wrongly at the time of 00:00:35.670 --> 00:00:39.350 publishing this episode, they might fix these problems later, 00:00:39.350 --> 00:00:41.429 maybe even by the time you're hearing this episode. 00:00:41.954 --> 00:00:45.715 But I will praise some companies that do things correctly. 00:00:45.715 --> 00:00:48.594 And keep in mind that just because I don't praise a particular 00:00:48.594 --> 00:00:52.754 company doesn't necessarily mean they're doing it wrong. 00:00:52.914 --> 00:00:55.820 If you'd like to follow along in the notes for this episode, they 00:00:55.820 --> 00:00:58.939 are a simple tap or swipe away or at the idacityto 00:00:58.939 --> 00:01:02.460 podcast.com/hostingsins. 00:01:02.780 --> 00:01:07.180 Sin number 1, not redirecting your podcast RSS feed. 00:01:07.674 --> 00:01:10.954 If you use your podcast hosting provider's RSS feed for 00:01:10.954 --> 00:01:14.954 publishing your podcast, what happens if you ever want to leave 00:01:14.954 --> 00:01:15.915 that provider? 00:01:15.994 --> 00:01:19.594 You need to take your audience with you and not cause any 00:01:19.594 --> 00:01:21.674 interruption in their consumption of your podcast. 00:01:22.010 --> 00:01:26.409 What hosting providers should do is allow you to permanently 00:01:26.409 --> 00:01:31.769 redirect their feed URL for your podcast to your new feed URL, 00:01:31.930 --> 00:01:36.329 and this must be a 3 0 1 permanent redirect. 00:01:36.924 --> 00:01:42.844 Ideally, it should remain redirecting forever and ever, forever, 00:01:42.844 --> 00:01:45.405 and ever. Hallelujah. Yes. Hallelujah. 00:01:45.405 --> 00:01:49.564 If they redirect it forever, at least they should redirect it for 00:01:49.564 --> 00:01:51.724 a year, but really forever. 00:01:52.069 --> 00:01:55.109 And you can learn more about redirects and how to use redirects 00:01:55.109 --> 00:01:57.670 in podcasting in my episode 280. 00:01:57.670 --> 00:01:59.349 I've got the link to that in the notes. 00:01:59.349 --> 00:02:03.750 Tap or swipe away or at the audacitytopodcast.com/hostingsins. 00:02:04.165 --> 00:02:09.604 In short, they're like a change of address when you use a 3 0 1 00:02:09.604 --> 00:02:11.525 redirect or any kind of redirect. 00:02:11.604 --> 00:02:14.965 Kind of like you would use with your local postal provider. 00:02:15.125 --> 00:02:18.069 When you do that at the local post office, for example, you're 00:02:18.069 --> 00:02:21.189 asking for everything to forward to your new address. 00:02:21.189 --> 00:02:25.590 And sometimes you even have a special service that notifies 00:02:25.590 --> 00:02:29.909 everyone sending mail to your old address so they know that 00:02:29.909 --> 00:02:34.074 you've permanently moved and where they should send the mail from 00:02:34.074 --> 00:02:38.314 now on. 3 0 1 permanent redirects work that same way. 00:02:38.395 --> 00:02:42.555 And by permanent, that doesn't mean forever in this case. 00:02:42.875 --> 00:02:46.379 Even though the redirect should stay there forever, the meaning 00:02:46.379 --> 00:02:48.460 isn't necessarily forever. 00:02:48.539 --> 00:02:53.020 But it means it's never going to use that old URL again. 00:02:53.259 --> 00:02:57.819 A 3 0 1 redirect will then immediately forward any request for 00:02:57.819 --> 00:03:02.135 your RSS feed to the new feed URL without even loading any 00:03:02.135 --> 00:03:03.974 content from that old feed. 00:03:04.055 --> 00:03:06.135 There doesn't even have to be content there. 00:03:06.135 --> 00:03:09.495 It can simply be a URL that's redirecting. 00:03:09.495 --> 00:03:13.655 So whatever is in that old RSS feed doesn't matter if it's 00:03:13.655 --> 00:03:15.974 redirecting through any kind of standard redirect. 00:03:16.280 --> 00:03:21.000 But a 3 0 2 and a 3 0 7 redirect are both temporary redirects 00:03:21.000 --> 00:03:27.080 that can do the same thing, but the main difference is that 3 0 1 00:03:27.080 --> 00:03:29.719 part and the 3 0 2 and the 3 0 7. 00:03:29.719 --> 00:03:34.145 Those are technical computer codes that send that code back to 00:03:34.145 --> 00:03:39.104 the apps, telling them, in the case of a 3 0 1, that the feed URL 00:03:39.104 --> 00:03:40.944 has permanently changed. 00:03:41.185 --> 00:03:45.270 It will never be at that old URL again, and thus, the app should 00:03:45.270 --> 00:03:50.150 stop looking at that old URL and look only at the new URL. 00:03:50.150 --> 00:03:54.310 At least, that's how smartly developed apps are supposed to 00:03:54.310 --> 00:03:55.030 handle it. 00:03:55.030 --> 00:03:58.925 I think there are some apps out there that don't do that. 00:03:58.925 --> 00:04:02.685 When they see a 3 0 1 redirect, they'll just check it every time 00:04:02.844 --> 00:04:05.004 and forward to the new feed. 00:04:05.004 --> 00:04:07.884 But what they should do is they check it once and they see, oh, 00:04:07.884 --> 00:04:11.245 it's a 3 0 1 redirect. I should never check this ever again. 00:04:11.245 --> 00:04:15.699 And instead, I should get the feed from whatever this redirect is 00:04:15.699 --> 00:04:19.459 pointing me to. That's the way the app should work. 00:04:19.459 --> 00:04:21.540 And shame on those apps that don't work that way. 00:04:21.620 --> 00:04:26.845 If you can't forward your old feed URL to your new 1, then you 00:04:26.845 --> 00:04:30.605 effectively lose almost your entire audience when you switch 00:04:30.605 --> 00:04:31.805 hosting providers. 00:04:31.884 --> 00:04:35.324 That's why it's so important to have this control. 00:04:35.485 --> 00:04:40.540 Even if you don't own the actual URL, and whatever brand is in 00:04:40.540 --> 00:04:43.740 the feed URL doesn't actually matter, whether that's Libsyn or 00:04:43.740 --> 00:04:46.460 Captivate or even FeedBurn or anything like that. 00:04:46.460 --> 00:04:50.620 Whatever brand is in that URL, whatever it says does not matter. 00:04:50.620 --> 00:04:53.564 Whatever the slug is does not matter. 00:04:53.645 --> 00:04:58.605 What matters is that you have the control to point that URL where 00:04:58.605 --> 00:05:01.805 you want it to go if you ever need it to go somewhere else. 00:05:02.125 --> 00:05:04.925 But it's a good thing that most hosting providers, and certainly 00:05:04.925 --> 00:05:08.829 all the ones that I recommend, do offer feed redirects as an 00:05:08.829 --> 00:05:09.389 option. 00:05:09.790 --> 00:05:15.069 Years ago, Libsyn used to charge a 1 time fee to create that 00:05:15.069 --> 00:05:19.230 permanent redirect for your feed, but they stopped charging for 00:05:19.230 --> 00:05:20.845 that several years ago. 00:05:20.925 --> 00:05:25.164 If you absolutely must use a hosting provider that does not offer 00:05:25.164 --> 00:05:29.004 feed redirects, then use a third party service like Blubrry's 00:05:29.004 --> 00:05:33.644 Podcast Mirror or even FeedBurner in its very raw vanilla state 00:05:33.689 --> 00:05:38.410 to protect your feed URL so that if you ever need to change, you 00:05:38.410 --> 00:05:42.009 can just switch that in that third party service. 00:05:42.170 --> 00:05:45.449 But ideally, you shouldn't have to use that because you should 00:05:45.449 --> 00:05:48.555 just be using whatever feed performs the best from your feed 00:05:48.555 --> 00:05:52.394 hosting provider, and that would redirect if you ever need to 00:05:52.394 --> 00:05:53.274 move from that. 00:05:53.274 --> 00:05:56.074 Whether that's a feed hosting provider, a podcast hosting 00:05:56.074 --> 00:05:59.589 provider, your own website, your own domain, whatever it is, you 00:05:59.589 --> 00:06:00.949 need to be able to redirect that. 00:06:00.949 --> 00:06:05.509 And ideally, that redirect should remain in place for forever and 00:06:05.509 --> 00:06:07.670 ever. Hallelujah. Hallelujah. 00:06:07.990 --> 00:06:11.910 Send number 2, using unpredictable media URLs. 00:06:12.245 --> 00:06:16.165 Each episode of your podcast has its own unique URL for the media 00:06:16.165 --> 00:06:16.564 file. 00:06:16.564 --> 00:06:21.045 For example, my episode URLs on Libsyn are structured like this, 00:06:21.205 --> 00:06:27.649 httpscolon//traffic.libsyn.com/noodlemx. Yes. 00:06:27.649 --> 00:06:30.370 My old network name is still in there, but that doesn't matter. 00:06:30.370 --> 00:06:33.330 Did you even know that was in my URL for my media? 00:06:33.410 --> 00:06:38.209 So it's /noodlemx/tap411.mpthree. 00:06:38.290 --> 00:06:42.125 And that tap 411DotMP3, that's the filename of my episode. 00:06:42.125 --> 00:06:43.884 That's how I save it on my computer. 00:06:43.884 --> 00:06:47.245 That's how I upload it to Libsyn, and it's still there in the 00:06:47.245 --> 00:06:47.964 URL. 00:06:48.044 --> 00:06:54.019 And that is the actual m p3 URL for this very episode, and I knew 00:06:54.019 --> 00:06:58.579 it would be that exact URL before publishing this episode because 00:06:58.579 --> 00:07:01.060 it's completely predictable. 00:07:01.300 --> 00:07:04.819 I know that for each episode, the only thing that will change is 00:07:04.819 --> 00:07:08.584 the filename, and that will be the same filename as what I 00:07:08.584 --> 00:07:09.384 upload. 00:07:09.545 --> 00:07:13.144 So for episode 4 12, it will be that exact same URL, but the 00:07:13.144 --> 00:07:16.024 filename will be tap 4 12 dot m p 3. 00:07:16.024 --> 00:07:19.785 Blubrry and a few other providers also work this way too, and 00:07:19.785 --> 00:07:21.144 that's fantastic that they do. 00:07:21.729 --> 00:07:26.769 But some hosting providers use seemingly random characters in the 00:07:26.769 --> 00:07:27.970 media URLs. 00:07:28.050 --> 00:07:31.649 For example, 1 provider would make my episode URL look like 00:07:31.649 --> 00:07:38.204 httpscolon//provider.com, whatever that provider is, /mediaslash, 00:07:38.285 --> 00:07:41.245 and then a string of completely random characters 00:07:41.324 --> 00:07:44.125 /tap411.mpthree. 00:07:44.285 --> 00:07:49.485 That would be okay if that string of random characters was unique 00:07:49.485 --> 00:07:54.350 to your podcast and repeated across all your episodes so that, 00:07:54.350 --> 00:07:57.949 like Libsyn and Blueberry, the only part that changes per episode 00:07:57.949 --> 00:08:00.430 would be the filename for each episode. 00:08:00.509 --> 00:08:03.310 And you would know that filename because you made it and you 00:08:03.310 --> 00:08:07.944 uploaded it. But that's not how those other providers work. 00:08:07.944 --> 00:08:11.704 In fact, some that I really like don't work this way. 00:08:11.865 --> 00:08:16.665 Those random characters are different for every episode. 00:08:16.985 --> 00:08:21.310 So that URL for the m p 3 file is completely unpredictable 00:08:21.310 --> 00:08:25.550 because that string of random characters changes every time. 00:08:25.790 --> 00:08:29.550 This is bad because it makes it extremely cumbersome to migrate 00:08:29.629 --> 00:08:31.745 to that hosting provider. 00:08:31.745 --> 00:08:34.144 You'd think they'd make this easier for people to migrate to 00:08:34.144 --> 00:08:34.625 them. 00:08:34.625 --> 00:08:38.945 It's hard when you have embedded episodes on your website, 00:08:39.024 --> 00:08:42.625 whether you've embedded a built in player through a WordPress 00:08:42.625 --> 00:08:45.585 plugin or something like that that your provider for your website 00:08:46.089 --> 00:08:49.529 offers you, or if you're using your hosting provider's player, 00:08:49.529 --> 00:08:52.009 like from Captivate or Libsyn or whoever. 00:08:52.250 --> 00:08:55.370 So when you're doing that and you're trying to migrate to 1 of 00:08:55.370 --> 00:08:59.054 these hosting providers that does not use a predictable URL, you 00:08:59.054 --> 00:09:02.495 can't run any kind of find and replace operation on your website 00:09:02.495 --> 00:09:07.455 database to replace all them old media URLs or embed codes with 00:09:07.455 --> 00:09:12.415 the new ones because the new URLs contain a string of characters 00:09:12.415 --> 00:09:15.220 that's different for each episode. 00:09:15.540 --> 00:09:18.820 Not even regular expressions would help here if you're familiar 00:09:18.820 --> 00:09:22.100 with how to do regular expressions, wildcards, and all kinds of 00:09:22.100 --> 00:09:23.460 fancy things like that. 00:09:23.700 --> 00:09:27.540 However, regular expressions could help you migrate away from 00:09:27.540 --> 00:09:31.434 such a hosting provider because you could use a wildcard for that 00:09:31.434 --> 00:09:32.554 random string. 00:09:32.634 --> 00:09:38.475 So you're searching for hostingprovider.com/media/wildcard/ and 00:09:38.554 --> 00:09:42.554 replacing that with whatever your new URL is, leaving the 00:09:42.554 --> 00:09:43.355 filename the same. 00:09:43.759 --> 00:09:48.480 That is as long as your episode filenames stay the same between 00:09:48.480 --> 00:09:49.759 your hosting providers. 00:09:49.919 --> 00:09:53.200 And that's the other way some providers commit this sin. 00:09:53.279 --> 00:09:55.839 I was trying to help my friend Jessica Rhodes from Interview 00:09:55.839 --> 00:10:00.214 Connections facing this even worse version of this issue, and 00:10:00.214 --> 00:10:02.934 thanks to Jessica for inspiring this episode. 00:10:03.095 --> 00:10:06.774 She was working with a provider that did actually keep the same 00:10:06.774 --> 00:10:08.694 path for the media URLs. 00:10:08.694 --> 00:10:12.090 That's everything except the file name, but they replaced the 00:10:12.090 --> 00:10:16.330 filenames with something random and completely unpredictable. 00:10:16.649 --> 00:10:21.210 So absolutely no systematic find and replace operation could 00:10:21.210 --> 00:10:27.004 migrate to or from that, even with regular expressions. Shame. 00:10:27.004 --> 00:10:27.884 Shame on you. 00:10:27.965 --> 00:10:32.764 The only way to change all the past embedded episodes then is to 00:10:32.764 --> 00:10:37.004 update them all manually. And ain't nobody got time for that. 00:10:37.245 --> 00:10:41.279 If you're looking at a new hosting provider, check the media URLs 00:10:41.279 --> 00:10:45.360 for multiple episodes of another show hosted with that same 00:10:45.360 --> 00:10:49.200 provider and see if those URLs follow predictable patterns. 00:10:49.279 --> 00:10:52.240 Don't just see random characters and think, oh, no. That's bad. 00:10:52.504 --> 00:10:56.664 Look for if those random characters change for every episode. 00:10:56.985 --> 00:11:01.544 Too many providers do it this way, and they don't have to. 00:11:01.625 --> 00:11:05.544 Frankly, I think they do it because either they're ignorant of 00:11:05.544 --> 00:11:09.840 the problems they're creating or worse, they're apathetic and 00:11:09.840 --> 00:11:10.480 lazy. 00:11:10.559 --> 00:11:14.240 And an aside to this, this is something I knew I wanted to avoid 00:11:14.240 --> 00:11:17.600 with a feature that I built into PodChapters that helps you 00:11:17.600 --> 00:11:21.924 create chapters for your podcast and can even host your chapters 00:11:21.924 --> 00:11:25.044 and your transcript by giving you URLs for those things. 00:11:25.204 --> 00:11:26.884 So that's where this comes into play. 00:11:26.964 --> 00:11:31.445 Although the URLs from PodChapters look random, the randomized 00:11:31.445 --> 00:11:36.639 part of each URL is actually an account wide string that never 00:11:36.639 --> 00:11:37.360 changes. 00:11:37.759 --> 00:11:42.320 So for each episode, the only thing that changes is the name of 00:11:42.320 --> 00:11:45.440 that episode file, which is based on whatever you upload. 00:11:45.440 --> 00:11:47.919 So if you know the name of the file you're uploading, you can 00:11:47.919 --> 00:11:50.000 predict what the URL will be. 00:11:50.000 --> 00:11:54.725 For example, I already know that the transcript URL for this very 00:11:54.725 --> 00:11:56.004 episode will be 00:11:56.004 --> 00:12:16.639 httpscolon//storage.podchapters.com/j973bkwgxk3jpd4j3mw02g6b717p8s52/tap411/transcript.vtt. 00:12:17.865 --> 00:12:22.504 With only that tap 4 1 1 part being unique but predictable for 00:12:22.504 --> 00:12:26.024 each of my episodes, that whole random string of characters that 00:12:26.024 --> 00:12:29.465 I read off to you, and that is exactly what it would be. 00:12:29.465 --> 00:12:30.585 I think I got all of those right. 00:12:30.769 --> 00:12:34.769 It is the same for every episode because that is an account wide 00:12:34.769 --> 00:12:35.330 stream. 00:12:35.570 --> 00:12:39.649 So that this is I kind of called this the Adam Curry feature in 00:12:39.649 --> 00:12:42.850 my planning for this because something that Adam does when he 00:12:42.850 --> 00:12:46.095 publishes an episode of any of his podcasts is he publishes the 00:12:46.095 --> 00:12:48.654 episode first because he wants to get it out there to his 00:12:48.654 --> 00:12:50.415 audience as quickly as possible. 00:12:50.575 --> 00:12:53.615 He goes back and adds the chapters later or someone does that for 00:12:53.615 --> 00:12:54.095 him. 00:12:54.254 --> 00:12:58.014 So he wants to be able to link to the chapters and the transcript 00:12:58.174 --> 00:12:58.815 right away. 00:12:59.269 --> 00:13:04.470 So he needs a predictable URL even if there's nothing at that URL 00:13:04.470 --> 00:13:07.029 yet or it's empty. 00:13:07.190 --> 00:13:10.070 That's something that you can do with a predictable URL like 00:13:10.070 --> 00:13:10.549 that. 00:13:10.629 --> 00:13:13.574 And that's why I built that into PodChapters that way, because I 00:13:13.574 --> 00:13:17.814 I wanted it to be predictable so that podcasters could put that 00:13:17.814 --> 00:13:22.214 in and simply replace that 1 little part with what they already 00:13:22.214 --> 00:13:23.654 know it should contain. 00:13:23.814 --> 00:13:28.029 But if your media URLs with your hosting provider change and have 00:13:28.029 --> 00:13:32.110 random characters that change for each episode, you have no 00:13:32.110 --> 00:13:35.549 predictable pattern that makes it very difficult to migrate to 00:13:35.549 --> 00:13:38.190 them and also migrate from them. 00:13:38.190 --> 00:13:41.950 You would think that if it made it harder to migrate away from 00:13:41.950 --> 00:13:47.125 them, that that would at least justify why they might be not so 00:13:47.125 --> 00:13:50.485 interested in enabling that, but they're also might making it 00:13:50.485 --> 00:13:54.404 even harder to migrate to them because of this problem. 00:13:54.804 --> 00:13:58.829 And if you're facing the same problem, please let the new hosting 00:13:58.829 --> 00:14:02.350 provider know because some of them think this is not a problem. 00:14:02.429 --> 00:14:06.429 If it is a problem for you, please let them know that it's a 00:14:06.429 --> 00:14:08.269 problem so that they can fix it. 00:14:08.509 --> 00:14:11.855 Send number 3, changing your GUIDs. 00:14:11.934 --> 00:14:17.134 GUID stands for globally unique identifier, and there are 2 types 00:14:17.134 --> 00:14:21.855 in podcasting. 1 for each episode and 1 for your whole podcast. 00:14:21.934 --> 00:14:25.134 The podcast GUID was born from podcasting 2. 00:14:25.220 --> 00:14:28.580 Even though it will be generated based on your feed URL when the 00:14:28.580 --> 00:14:33.460 GUID is first generated, that GUID should never change after 00:14:33.460 --> 00:14:35.779 that, even if your feed URL changes. 00:14:35.940 --> 00:14:40.179 Because you can't reverse decode the GUID to figure out the feed 00:14:40.179 --> 00:14:40.580 URL. 00:14:40.580 --> 00:14:44.154 It's just we're giving you this ID at this moment, and no matter 00:14:44.154 --> 00:14:48.475 what your feed URL is after this, that GUID should never change. 00:14:48.714 --> 00:14:52.634 Any good hosting provider should automatically inherit the same 00:14:52.634 --> 00:14:55.595 podcast GUID when you migrate your feed. 00:14:55.940 --> 00:14:58.659 Blubrry, Buzzsprout, and I think Captivate, several other 00:14:58.659 --> 00:15:01.700 providers do this properly for you when you're migrating your 00:15:01.700 --> 00:15:02.820 feed to them. 00:15:02.980 --> 00:15:07.220 Your episode GUIDs are actually even more important. 00:15:07.620 --> 00:15:12.264 What is in the episode GUID doesn't actually matter. 00:15:12.424 --> 00:15:16.105 For example, any feed generated with WordPress usually uses your 00:15:16.105 --> 00:15:20.825 WordPress post ID number in a URL so that doesn't change even if 00:15:20.825 --> 00:15:24.509 you change the friendly or SEO friendly URL, but it's using a 00:15:24.509 --> 00:15:28.350 post ID that is hard coded into the database and you can't change 00:15:28.350 --> 00:15:29.629 that post ID number. 00:15:29.629 --> 00:15:32.509 But that's being used inside of your WordPress site. 00:15:32.509 --> 00:15:36.110 So for example, for The Audacity to Podcast, 1 of the GUIDs might 00:15:36.105 --> 00:15:41.945 be h t t p colon slash / the audacitytopodcast.com/ question mark 00:15:41.945 --> 00:15:44.664 p equals 7 3 7. 00:15:44.664 --> 00:15:48.424 I I don't know what's a 7 3 7, but that's an example of a GUID. 00:15:48.584 --> 00:15:53.930 Now even though it looks like a URL, it's not treated like a URL. 00:15:54.009 --> 00:15:57.370 Some publishing tools make it a completely random string of 00:15:57.370 --> 00:16:00.730 characters, and either of these are perfectly acceptable because 00:16:00.730 --> 00:16:04.170 what's in the GUID is not what's important. 00:16:04.410 --> 00:16:07.774 What is important is that they never change. 00:16:08.254 --> 00:16:11.454 So the SYN is when those GUIDs or some people pronounce them 00:16:11.454 --> 00:16:15.615 GUIDs are changed either when you migrate to that provider or 00:16:15.615 --> 00:16:19.054 publishing tool or if they have to change something in their back 00:16:19.054 --> 00:16:22.009 end and that might change your GUIDs. 00:16:22.250 --> 00:16:25.450 This might be a problem that you run into if you do some kind of 00:16:25.450 --> 00:16:28.889 find and replace on your own WordPress database, and your 00:16:28.889 --> 00:16:31.129 WordPress site is creating your RSS feed. 00:16:31.129 --> 00:16:34.730 Make sure that any kind of find and replace operation does not 00:16:35.184 --> 00:16:37.585 affect the post GUIDs. 00:16:37.825 --> 00:16:40.465 And you can run into this also, for example, if you're changing 00:16:40.465 --> 00:16:46.545 from HTTP to HTTPS. The GUIDs should not change. 00:16:46.865 --> 00:16:49.990 And what's in them, again, does not actually matter. 00:16:49.990 --> 00:16:52.710 What matters that is that they not change because they are 00:16:52.710 --> 00:16:58.389 treated as IDs, identifiers, not as actual URLs. 00:16:58.389 --> 00:17:00.710 Although there is a technical thing that can treat them like 00:17:00.710 --> 00:17:03.269 URLs, but generally, they're not considered to be URLs. 00:17:03.654 --> 00:17:07.575 Nearly all podcast apps use the GUIDs to track which episodes 00:17:07.575 --> 00:17:09.894 have been played, which have been downloaded, which have been 00:17:09.894 --> 00:17:13.894 ignored and such. That's why the GUIDs are so important. 00:17:13.974 --> 00:17:18.259 That's how the apps know which episode is which and what you've 00:17:18.259 --> 00:17:19.539 done with those episodes. 00:17:19.859 --> 00:17:23.220 If an episode's GUID is changed, like, everything else could 00:17:23.220 --> 00:17:27.299 remain exactly the same about the episode in your RSS feed, even 00:17:27.299 --> 00:17:30.259 the media file and its URL don't change at all. 00:17:30.375 --> 00:17:34.934 But if the GUID is changed, nearly all podcast apps will think 00:17:34.934 --> 00:17:38.054 it's a new episode and redownload it. 00:17:38.134 --> 00:17:41.734 And that will then mess up your stats and probably confuse and 00:17:41.734 --> 00:17:45.329 maybe even frustrate your audience. Just don't do that. 00:17:45.329 --> 00:17:48.289 Don't let that be done to your podcast either. 00:17:48.289 --> 00:17:52.289 Most podcast hosting providers properly migrate the episode GUIDs 00:17:52.289 --> 00:17:56.450 on migration to them, but some might not. 00:17:57.034 --> 00:18:01.914 So if you're migrating your podcast to a lesser known, less 00:18:01.914 --> 00:18:05.595 popular hosting provider, then definitely ask them. 00:18:05.595 --> 00:18:08.474 Check with them. Even check your own RSS feed. 00:18:08.474 --> 00:18:09.914 Look at your old RSS feed. 00:18:10.130 --> 00:18:13.009 Look at the new 1 after they've completed their migration, and 00:18:13.009 --> 00:18:15.250 look for the GUID tag. 00:18:15.250 --> 00:18:20.049 It will be all lowercase, GUID, and check it for a few episodes 00:18:20.049 --> 00:18:23.115 and make sure they are exactly the same. 00:18:23.115 --> 00:18:26.394 Same capitalization even might matter in some cases. 00:18:26.474 --> 00:18:30.555 They should be exactly the same, not a single character or 00:18:30.555 --> 00:18:34.234 capitalization off, not 1 jot or tittle off. 00:18:35.240 --> 00:18:39.799 Sin number 4, improperly constructing your RSS feed. 00:18:39.799 --> 00:18:43.720 We're finally moving away from some of these migration related 00:18:43.720 --> 00:18:44.359 sins. 00:18:44.759 --> 00:18:48.919 Some hosting providers and publishing tools do bad things inside 00:18:48.919 --> 00:18:50.039 your RSS feed. 00:18:50.284 --> 00:18:54.284 Sometimes it's for some concern for compatibility, maybe, but it 00:18:54.284 --> 00:18:57.724 seems to usually be from ignorance or oversight. 00:18:57.804 --> 00:18:59.004 Here are some examples. 00:18:59.005 --> 00:19:02.845 And again, I am not going to name who makes these mistakes 00:19:02.845 --> 00:19:07.580 because they might fix these problems, especially if they get a 00:19:07.580 --> 00:19:08.460 hold of this episode. 00:19:08.460 --> 00:19:11.100 And if you know who those hosting providers are, feel free to 00:19:11.100 --> 00:19:13.980 send them this episode, but I am not going to throw anyone under 00:19:13.980 --> 00:19:17.204 the bus, at least not yet. Here are some examples for this. 00:19:17.205 --> 00:19:21.684 A popular podcast hosting provider puts the same text in 3 00:19:21.684 --> 00:19:25.924 separate RSS tags on the same episode, and those tags are content 00:19:25.924 --> 00:19:29.765 encoded, description, and even the deprecated iTunes summary. 00:19:30.000 --> 00:19:34.799 So it's the same exact text in 3 places for that episode. 00:19:34.799 --> 00:19:37.839 And then multiply that by how many episodes are in your feed, and 00:19:37.839 --> 00:19:39.839 that's a lot of wasted space. 00:19:40.000 --> 00:19:42.640 And it's really not even necessary to have all of those 00:19:42.640 --> 00:19:43.440 populated. 00:19:43.519 --> 00:19:47.775 I think all podcast apps will fall back to the description tag if 00:19:47.775 --> 00:19:50.974 nothing else is populated there for your show notes or the 00:19:50.974 --> 00:19:52.494 description of the episode. 00:19:52.734 --> 00:19:55.855 So it's really not necessary to have all 3 of them there, 00:19:56.015 --> 00:19:59.615 especially not necessary for all 3 of them to contain the exact 00:19:59.615 --> 00:20:00.494 same text. 00:20:01.319 --> 00:20:05.720 That same hosting provider is guilty of another example here, and 00:20:05.720 --> 00:20:09.000 a few others make this mistake, and that is the enclosure tag. 00:20:09.000 --> 00:20:13.000 This is what turns an RSS feed into a podcast feed, is the 00:20:13.000 --> 00:20:13.559 enclosure. 00:20:13.559 --> 00:20:16.599 That's where your m p 3 file or other media file is linked. 00:20:16.894 --> 00:20:20.974 It's supposed to have an attribute to it called length, and that 00:20:20.974 --> 00:20:25.934 is supposed to be set to the size of the file, the actual file 00:20:25.934 --> 00:20:29.694 size in bytes, not kilobytes, megabytes, or anything like that. 00:20:29.880 --> 00:20:32.759 And some of these hosting providers, the same 1 that I just gave 00:20:32.759 --> 00:20:39.799 an example from, put the number 0 in there. So link equals 0. No. 00:20:39.799 --> 00:20:41.079 You should not do that. 00:20:41.079 --> 00:20:44.359 You should put in there the file size in bytes. 00:20:44.974 --> 00:20:47.615 A different problem is that a few popular hosting providers 00:20:47.615 --> 00:20:52.494 incorrectly populate your episodes iTunes title and normal title 00:20:52.494 --> 00:20:55.054 tags with the exact same text. 00:20:55.214 --> 00:20:59.134 That's unnecessary for them to be the same, and it's redundant. 00:20:59.509 --> 00:21:04.710 But it's even worse if your podcast needs episode numbers because 00:21:04.710 --> 00:21:07.509 some of these places that do this where they're putting the same 00:21:07.509 --> 00:21:11.509 title text in both title fields, which is unnecessary to do, they 00:21:11.509 --> 00:21:14.470 let you put in an episode number, and they put that episode 00:21:14.470 --> 00:21:18.365 number in the iTunes episode tag, and that is the right place for 00:21:18.365 --> 00:21:22.125 the episode number, but they don't do anything else with that 00:21:22.125 --> 00:21:23.085 episode number. 00:21:23.244 --> 00:21:27.644 And that's the whole reason the iTunes title tag exists is so 00:21:27.644 --> 00:21:32.019 that you can put a title in there without an episode number in 00:21:32.019 --> 00:21:32.499 it. 00:21:32.500 --> 00:21:36.899 So you can split the episode number into that iTunes episode tag. 00:21:37.139 --> 00:21:42.019 But then the regular title tag should still contain the episode 00:21:42.019 --> 00:21:42.419 number. 00:21:42.419 --> 00:21:45.059 And this is if episode numbers are important for your podcast. 00:21:45.164 --> 00:21:49.404 And I'm going to do an episode coming up soon about episode 00:21:49.404 --> 00:21:52.525 numbers again because I've changed my mind on when it is 00:21:52.525 --> 00:21:55.644 important for your episode to have and use episode numbers. 00:21:55.884 --> 00:21:59.404 But if you're using episode numbers and if you want your audience 00:21:59.404 --> 00:22:04.099 to see those episode numbers, then for full compatibility, they 00:22:04.099 --> 00:22:08.099 need to be in the normal title tag, and they should not be in the 00:22:08.099 --> 00:22:09.220 iTunes title tag. 00:22:09.220 --> 00:22:12.019 There's some misunderstanding and misinformation out there about 00:22:12.019 --> 00:22:14.660 how these tags are supposed to be used, but this is the way it's 00:22:14.660 --> 00:22:18.875 supposed to be, is that the title tag is what nearly all podcast 00:22:18.875 --> 00:22:19.755 apps support. 00:22:19.755 --> 00:22:24.554 Only a few podcast apps support iTunes title and iTunes episode. 00:22:24.634 --> 00:22:27.514 So they would then display the episode numbers separately. 00:22:27.755 --> 00:22:32.420 I think Fireside is the only hosting provider that does this in a 00:22:32.420 --> 00:22:33.220 smart way. 00:22:33.220 --> 00:22:37.539 And rss.com might be changing to this similar because they asked 00:22:37.539 --> 00:22:39.619 me a whole lot of questions about this. 00:22:39.619 --> 00:22:42.500 I got to demonstrate to them this is how this is working. 00:22:42.500 --> 00:22:44.580 These are some ways that you could work with this to make this 00:22:44.580 --> 00:22:44.820 better. 00:22:45.085 --> 00:22:49.884 But Captivate, PowerPress, Libsyn, and some others do allow you 00:22:49.884 --> 00:22:55.965 to manually edit these separate title tags separately so that 1 00:22:55.965 --> 00:22:58.125 can contain an episode number in it. 00:22:58.125 --> 00:22:59.404 That would be your normal title. 00:22:59.599 --> 00:23:04.240 And the iTunes or Apple title would not contain the episode 00:23:04.240 --> 00:23:07.359 number because you would put that episode number in the episode 00:23:07.359 --> 00:23:08.159 field. 00:23:08.320 --> 00:23:11.680 But the smartest way to do this is, I think, what Fireside does, 00:23:11.680 --> 00:23:14.640 and I've built this into a plug in for PowerPress that I hope to 00:23:14.640 --> 00:23:18.055 release to the public someday, where you can populate that 00:23:18.055 --> 00:23:22.375 episode number field, and then it automatically adds that to the 00:23:22.375 --> 00:23:24.694 normal title field at the beginning. 00:23:24.855 --> 00:23:28.214 So it'd be, like, 5 period space and then the rest of your 00:23:28.214 --> 00:23:32.329 episode title, but it excludes it from the iTunes title tag. 00:23:32.490 --> 00:23:35.609 And someday when there's a podcast colon title tag, it would 00:23:35.609 --> 00:23:38.569 exclude it from there too. That's the smart way to do it. 00:23:38.730 --> 00:23:41.769 The next best way to do it is what some of these other providers 00:23:41.769 --> 00:23:46.724 do, that is they let you have an additional field where you can 00:23:46.724 --> 00:23:48.325 enter these titles separately. 00:23:48.484 --> 00:23:51.845 That's not exactly the best way to do it, but it at least it does 00:23:51.845 --> 00:23:55.605 give you full control to do it exactly the way you want it to be. 00:23:56.089 --> 00:24:00.089 Moving on, some providers and publishing tools ignore the iTunes 00:24:00.089 --> 00:24:02.009 colon duration tag. 00:24:02.170 --> 00:24:05.609 It is optional, but it's very helpful for podcast apps. 00:24:05.769 --> 00:24:08.890 Unfortunately, Apple says different duration formats are 00:24:08.890 --> 00:24:09.289 accepted. 00:24:09.484 --> 00:24:12.365 However, it is recommended to convert the length of the episode 00:24:12.365 --> 00:24:14.205 into seconds. Okay. Yeah. 00:24:14.205 --> 00:24:17.965 But they're also saying that something like minutes colon seconds 00:24:17.965 --> 00:24:20.525 could work if you're putting that format in there. 00:24:20.525 --> 00:24:23.164 I wish they would just say, this is the way it should be done and 00:24:23.164 --> 00:24:23.884 only this way. 00:24:24.390 --> 00:24:28.470 But some publishing tools don't put that in there at all. 00:24:28.470 --> 00:24:31.589 And so if your feed doesn't have that, then some podcast apps 00:24:31.589 --> 00:24:35.109 might not be able to display to the user how long the episode 00:24:35.109 --> 00:24:39.125 actually is unless those podcast apps start downloading the file 00:24:39.125 --> 00:24:41.924 and then pull information from the file itself. 00:24:42.085 --> 00:24:45.365 Another example of something that these publishing tools and 00:24:45.365 --> 00:24:48.805 providers do is that some providers incorrectly format the 00:24:48.805 --> 00:24:50.404 episode's pub date tag. 00:24:50.720 --> 00:24:53.920 That's supposed to be, as you could probably guess, the date of 00:24:53.920 --> 00:24:58.880 publication, and it's supposed to follow a very specific date 00:24:58.880 --> 00:25:03.200 format, which unfortunately not all providers respect. 00:25:03.654 --> 00:25:07.815 Surprisingly, Hubbell makes this tag only recommended instead of 00:25:07.815 --> 00:25:08.615 required. 00:25:09.015 --> 00:25:13.174 Moving on, some providers don't let you change the link URL for 00:25:13.174 --> 00:25:13.974 your episodes. 00:25:13.974 --> 00:25:17.429 This is crucial when your episode web page is somewhere other 00:25:17.429 --> 00:25:20.549 than on the website your podcast hosting provider gives you. 00:25:20.549 --> 00:25:24.469 Libsyn, Captivate, and Buzzsprout all let you edit this link. 00:25:24.789 --> 00:25:28.230 PowerPress doesn't really need to let you edit it because the 00:25:28.230 --> 00:25:32.054 primary usage of PowerPress is making a podcast feed from your 00:25:32.054 --> 00:25:33.174 own site. 00:25:33.575 --> 00:25:37.734 So the episode links are already pointing to your own web page 00:25:37.734 --> 00:25:39.094 for that episode. 00:25:39.095 --> 00:25:42.534 That's why you don't need to edit it if you're using PowerPress. 00:25:42.694 --> 00:25:46.730 But if you're using some other publishing tool and you're using 00:25:46.730 --> 00:25:50.409 that separate from your website, you need to be able to set that 00:25:50.409 --> 00:25:55.929 link to the web page for your episode because many podcast apps 00:25:55.929 --> 00:26:01.115 will let the audience member tap on a link to visit the web page 00:26:01.115 --> 00:26:02.154 for the episode. 00:26:02.315 --> 00:26:05.755 And you don't want them going to some ugly looking website that 00:26:05.755 --> 00:26:07.914 you haven't done any branding on. 00:26:08.075 --> 00:26:09.994 You want them to go to your website. 00:26:10.234 --> 00:26:15.070 So you need to be able to set that link, and some providers don't 00:26:15.070 --> 00:26:16.269 let you set that. 00:26:16.509 --> 00:26:20.109 Some of these examples I've given, you might uncover by looking 00:26:20.109 --> 00:26:24.750 at the raw XML code for a podcast RSS feed from each provider. 00:26:24.750 --> 00:26:27.630 Now that's a lot of letters I just said, so that might scare you 00:26:27.630 --> 00:26:27.869 a bit. 00:26:28.065 --> 00:26:32.784 But for example, you might see enclosure with length equals 00:26:32.784 --> 00:26:35.344 quotation 0 quotation. 00:26:35.504 --> 00:26:38.384 If you see that in the feed, then you can know they're doing it 00:26:38.384 --> 00:26:38.944 wrong. 00:26:39.105 --> 00:26:42.009 Some of these other things, like how they're handling the link 00:26:42.009 --> 00:26:45.049 tag or description or content encoded and some of this other 00:26:45.049 --> 00:26:49.450 stuff might be an oversight on the podcaster's part and not the 00:26:49.450 --> 00:26:51.210 fault of the hosting provider. 00:26:51.289 --> 00:26:54.809 Unfortunately, some of these things you might just not discover 00:26:54.964 --> 00:26:59.204 until you actually start using that podcast hosting provider. 00:26:59.365 --> 00:27:02.404 That's what I ran into a few months ago when I was considering 00:27:02.404 --> 00:27:06.085 moving my hosting provider and how I was generating my RSS feed. 00:27:06.085 --> 00:27:09.044 There are several hosting providers I really like. 00:27:09.045 --> 00:27:12.420 But for myself, not for you necessarily that I would recommend 00:27:12.420 --> 00:27:15.779 that you do some of these things, but for myself, there were some 00:27:15.779 --> 00:27:19.859 very, very specific things that I wanted to do with my podcast 00:27:19.859 --> 00:27:22.579 RSS feed and certain ways I wanted it to behave. 00:27:22.945 --> 00:27:25.984 And it wasn't until I actually started using some of these 00:27:25.984 --> 00:27:29.984 providers that I discovered, oh, they don't do this right. 00:27:30.144 --> 00:27:32.305 Or at least how I create my podcast. 00:27:32.305 --> 00:27:35.184 They're not handling this particular thing in the right way. 00:27:35.184 --> 00:27:38.829 Like, the iTunes title thing is 1 of those things that couple of 00:27:38.829 --> 00:27:42.029 hosting providers that I tried didn't handle that properly. 00:27:42.190 --> 00:27:44.670 Or there were a couple of other things where I didn't have the 00:27:44.670 --> 00:27:47.470 control that I wanted, and so I ended up just deciding to stick 00:27:47.470 --> 00:27:51.734 with PowerPress and making an extension to PowerPress that would 00:27:51.734 --> 00:27:55.494 make certain things behave exactly how I want them to behave, as 00:27:55.494 --> 00:27:58.454 well as some other cool things too to support some cutting edge 00:27:58.454 --> 00:27:59.095 features. 00:27:59.095 --> 00:28:02.294 I'd love to release that plug in for free in the future. 00:28:02.295 --> 00:28:03.734 We'll see if I can do that. 00:28:03.734 --> 00:28:05.734 There are just some legal issues I need to work through. 00:28:05.990 --> 00:28:07.589 Not that I'm in trouble. 00:28:07.590 --> 00:28:10.789 I want to make sure I respect certain trademarks and such. 00:28:10.789 --> 00:28:14.630 So I'm talking to the trademark owners to make sure that I do 00:28:14.630 --> 00:28:17.109 this respectfully in a way that they're okay with. 00:28:17.109 --> 00:28:19.349 You can watch for that. I'll let you know when I release that. 00:28:19.774 --> 00:28:25.214 Moving on to sin number 5, stripping important data from your 00:28:25.214 --> 00:28:26.014 episodes. 00:28:26.174 --> 00:28:29.294 M p threes can hold a lot of important pieces of data that are 00:28:29.294 --> 00:28:33.110 good for compatibility and sometimes vital for certain 00:28:33.110 --> 00:28:36.230 functionality and workflows in your podcasting. 00:28:36.390 --> 00:28:39.990 For example, you can add your episode artwork to the m p 3, and 00:28:39.990 --> 00:28:43.509 your hosting provider might automatically read that image and 00:28:43.509 --> 00:28:47.325 save it to the RSS feed for the iTunes image and maybe even the 00:28:47.325 --> 00:28:50.924 podcast image for podcasting 2, and maybe embed it on the web 00:28:50.924 --> 00:28:52.284 page for that episode. 00:28:52.365 --> 00:28:55.724 Captivate, Buzzsprout, Blubrry, and many other providers either 00:28:55.724 --> 00:29:00.759 use that image conveniently or in the least, they keep the image 00:29:00.759 --> 00:29:05.160 in the m p 3, and they don't strip it out or do anything bad to 00:29:05.160 --> 00:29:05.559 it. 00:29:05.799 --> 00:29:08.759 Before you think it's unnecessary for that image to be in the m p 00:29:08.759 --> 00:29:12.775 3, regardless of the workflow aspects of this, there are some 00:29:12.775 --> 00:29:17.255 podcast apps that actually use that image for the episode image. 00:29:17.255 --> 00:29:21.174 So if episode specific images are important to you, then you need 00:29:21.174 --> 00:29:24.455 to make sure that your hosting provider is not committing this 00:29:24.455 --> 00:29:24.695 sin. 00:29:24.980 --> 00:29:30.259 Overcast, for example, still gets its image for your episode from 00:29:30.259 --> 00:29:31.700 the m p 3 file. 00:29:31.779 --> 00:29:34.900 And if there isn't an image in your m p 3 file, then Overcast 00:29:34.900 --> 00:29:38.099 will fall back to your top level podcast cover art to display for 00:29:38.099 --> 00:29:39.779 that episode. And there's nothing wrong with that. 00:29:39.994 --> 00:29:43.914 But if you want episode specific artwork, then you have to put it 00:29:43.914 --> 00:29:48.154 in your m p 3 file, and your hosting provider has to keep that 00:29:48.154 --> 00:29:52.154 image there in the m p 3 file, as well as put it in other places 00:29:52.154 --> 00:29:54.234 for optimal compatibility. 00:29:54.649 --> 00:29:58.329 The other important data in your episode could be legacy chapters 00:29:58.329 --> 00:30:00.329 embedded in the m p 3. 00:30:00.409 --> 00:30:04.889 Pod chapters exports chapters in your m p 3 and as JSON code for 00:30:04.889 --> 00:30:09.210 podcasting 2 and as XML code for PodLove simple chapters as well 00:30:09.210 --> 00:30:11.694 as some other formats that exports that you can use in different 00:30:11.694 --> 00:30:13.054 ways. So try it out. 00:30:13.054 --> 00:30:16.654 Try PodChapters free for 7 days over at podchapters.com. 00:30:16.734 --> 00:30:19.774 But even if your hosting provider doesn't support modern chapters 00:30:19.774 --> 00:30:23.640 like Podcasting 2 or even PodLove simple chapters, which aren't 00:30:23.640 --> 00:30:26.679 the most modern, but they're still more modern than the legacy m 00:30:26.519 --> 00:30:27.319 3 chapters. 00:30:27.400 --> 00:30:30.680 Or even if they don't give you the option to paste in a URL for 00:30:30.680 --> 00:30:34.599 your Podcasting 2 chapters, like what PodChapters can host for 00:30:34.599 --> 00:30:39.585 you, they should at least still read the chapters from the m p 3 00:30:39.585 --> 00:30:41.904 file and keep them there. 00:30:42.305 --> 00:30:45.825 What would be better is that they read those chapters from the m 00:30:45.825 --> 00:30:49.184 p 3 data and then copy them to the other formats. 00:30:49.519 --> 00:30:53.759 This is why PodChapters is still useful and likely much better 00:30:53.919 --> 00:30:56.720 than the tools that you get with your podcast hosting provider 00:30:56.720 --> 00:30:57.839 for making chapters. 00:30:57.919 --> 00:31:01.839 Because you can create your chapters with PodChapters, embed them 00:31:01.839 --> 00:31:05.464 in the m p 3, and then upload them to some of these publishing 00:31:05.464 --> 00:31:08.505 tools and hosting providers, and they will read those chapters 00:31:08.505 --> 00:31:10.585 and copy them to the other places. 00:31:10.825 --> 00:31:14.904 For example, Buzzsprout does this really well, where when you 00:31:14.904 --> 00:31:18.210 upload your m p 3 that already has chapters in it, even though 00:31:18.210 --> 00:31:22.289 you can't give Buzzsprout your podcasting 2 chapters, if your m p 00:31:22.289 --> 00:31:28.049 3 file has chapters in it, Buzzsprout will copy those chapters to 00:31:28.130 --> 00:31:31.970 podcasting 2 format and Podlove simple chapters. 00:31:32.345 --> 00:31:36.265 So, again, it's about the workflow in this case, not just the 00:31:36.265 --> 00:31:39.865 compatibility, but the workflow is there to go from 1 format to 00:31:39.865 --> 00:31:43.144 the other because your hosting provider is doing that for you. 00:31:43.144 --> 00:31:46.744 Captivate, Buzzsprout, Blubrry, and Libsyn all keep your m p 00:31:46.744 --> 00:31:51.679 threes embedded chapters untouched, unless you use their chapter 00:31:51.679 --> 00:31:53.279 tools to change those chapters. 00:31:53.279 --> 00:31:55.599 Then, of course, they're going to edit the chapters. 00:31:55.679 --> 00:31:58.799 But if you upload chapters just the way you want them, then those 00:31:58.799 --> 00:32:00.720 providers will not change those chapters. 00:32:01.195 --> 00:32:06.474 But some providers won't copy all the chapter data, or they 00:32:06.474 --> 00:32:09.275 actually completely remove your chapters. 00:32:09.355 --> 00:32:13.434 For example, 1 popular provider will properly read your chapter 00:32:13.434 --> 00:32:16.315 titles and time stamps, and that might be enough for you. 00:32:16.769 --> 00:32:20.690 But chapters can also contain links and images. 00:32:21.009 --> 00:32:25.570 But this provider that I'm referring to doesn't copy those links 00:32:25.570 --> 00:32:27.650 and images into the other chapters. 00:32:27.650 --> 00:32:30.865 Even though they'll copy your titles and the correct time stamps 00:32:30.865 --> 00:32:34.545 into your podcasting 2 chapters, they won't copy any links you 00:32:34.545 --> 00:32:36.625 have or any images you have. 00:32:36.625 --> 00:32:39.424 You'll have to re add those in their system. 00:32:39.505 --> 00:32:42.065 That's something they're aware of, this particular provider I'm 00:32:42.065 --> 00:32:44.545 thinking of, and it's something I would love to see them fix. 00:32:44.599 --> 00:32:47.799 So if you're using PodChapters and you're using this other 00:32:47.799 --> 00:32:50.200 provider and you know who they are and you know the shortcoming 00:32:50.200 --> 00:32:53.079 that they have, please kindly request that they fix it. 00:32:53.559 --> 00:32:56.920 Sin number 6, not optimizing your media. 00:32:57.404 --> 00:33:00.924 There are, unfortunately, still several technical standards 00:33:00.924 --> 00:33:02.525 podcasters need to know about. 00:33:02.525 --> 00:33:07.404 But I would love to see these be unnecessary for you to ever 00:33:07.404 --> 00:33:11.644 think about because your hosting provider and publishing tools 00:33:10.960 --> 00:33:13.759 optimize those things appropriately for you. 00:33:13.759 --> 00:33:17.680 For example, Buzzsprout's base plan will re encode your podcast 00:33:17.680 --> 00:33:23.200 audio down to 96 kilobits per second mono only if you upload 00:33:23.200 --> 00:33:24.720 something higher than that. 00:33:25.234 --> 00:33:28.994 This ensures you're publishing the right format of media and at 00:33:28.994 --> 00:33:30.755 an optimal quality level. 00:33:30.914 --> 00:33:34.115 You could also upgrade your Buzzsprout account to include what 00:33:34.115 --> 00:33:37.075 they call magic mastering, so they fix your loudness levels 00:33:37.075 --> 00:33:40.115 automatically and even let you publish in stereo. 00:33:40.130 --> 00:33:43.250 Those are both really smart features that they support. Yeah. 00:33:43.250 --> 00:33:46.369 At an additional cost, but that might be worth it to you if you 00:33:46.369 --> 00:33:49.090 don't want to do that stuff like the magic mastering and the 00:33:49.090 --> 00:33:50.369 loudness levels and stuff. 00:33:50.369 --> 00:33:53.570 If you don't want to manage that before you upload, they can fix 00:33:53.570 --> 00:33:55.490 that for you after you upload. 00:33:55.570 --> 00:33:58.345 Or do it yourself, and you don't have to pay for that upgrade. 00:33:58.345 --> 00:34:00.025 But they do a really good job at it. 00:34:00.105 --> 00:34:06.105 But some hosting providers will let you upload anything, even an 00:34:06.105 --> 00:34:10.425 uncompressed WAV file that could be a 100 times bigger than it 00:34:10.425 --> 00:34:15.000 should be, or another audio file format that most podcast apps 00:34:15.000 --> 00:34:16.119 don't support. 00:34:16.519 --> 00:34:19.079 And they'll just let you publish your episode like that. 00:34:19.239 --> 00:34:22.679 And you might never realize it's broken until your audience says, 00:34:22.679 --> 00:34:25.000 hey, your episode doesn't play, and you're trying to figure out 00:34:25.000 --> 00:34:26.599 why is it broken, why isn't it working. 00:34:26.744 --> 00:34:29.065 You're going back and forth. I uploaded this audio file. 00:34:29.065 --> 00:34:32.505 The audio file plays perfectly on my computer. I upload it again. 00:34:32.505 --> 00:34:35.065 It still plays perfectly. Why isn't it working in my RSS feed? 00:34:35.065 --> 00:34:37.704 And you might realize then or maybe the hosting provider points 00:34:37.704 --> 00:34:40.905 out to you, oh, hey, you uploaded an uncompressed WAV file and 00:34:40.905 --> 00:34:43.180 yet filled up your account, and don't do that. 00:34:43.180 --> 00:34:44.619 You shouldn't publish WAV files. 00:34:44.619 --> 00:34:48.220 You need to publish an m p 3 or another popular audio or video 00:34:48.220 --> 00:34:49.980 format depending on what you're publishing. 00:34:50.059 --> 00:34:53.180 Their system should do that for you automatically. 00:34:53.180 --> 00:34:56.780 It should convert it from WAV to m p 3 in the correct format for 00:34:56.780 --> 00:34:59.474 you if you're uploading the wrong format. 00:34:59.474 --> 00:35:02.434 But if you upload the right format, they shouldn't convert it. 00:35:02.434 --> 00:35:04.114 That you shouldn't have to worry about it. 00:35:04.114 --> 00:35:07.474 Either way, you should just be able to upload your audio and know 00:35:07.474 --> 00:35:10.034 that it will publish in the correct format. 00:35:10.114 --> 00:35:11.795 Images are another thing related to this. 00:35:12.110 --> 00:35:16.590 Some providers let you upload any kind of image, even Photoshop 00:35:16.590 --> 00:35:17.470 files. 00:35:17.630 --> 00:35:20.829 But they might let you upload an image that's too big or too 00:35:20.829 --> 00:35:25.085 small, that's in file size or pixel dimensions, or maybe it's the 00:35:25.085 --> 00:35:28.045 wrong shape, like it's rectangular instead of square, or its 00:35:28.045 --> 00:35:30.364 other technical specs are incorrect. 00:35:30.684 --> 00:35:33.565 Ideally, the publishing tool should warn you when you're 00:35:33.565 --> 00:35:37.500 uploading something with the wrong specs and potentially and 00:35:37.500 --> 00:35:40.700 optimally provide the tools to fix that. 00:35:40.940 --> 00:35:44.619 Like if it's too big, file size or dimensions, it could pop up a 00:35:44.619 --> 00:35:47.340 little warning that says, hey, this file is too big. 00:35:47.340 --> 00:35:49.824 Click here and we'll optimize it. Or hey, this is too big. 00:35:49.824 --> 00:35:52.785 We've automatically optimized it for you without compromising the 00:35:52.785 --> 00:35:55.985 visual quality of it. Anything like that would be really cool. 00:35:55.985 --> 00:35:58.704 On Pod chapters, I'm working to make it do some of this 00:35:58.704 --> 00:36:02.224 optimization automatically or with a simple press of a button. 00:36:02.224 --> 00:36:05.599 For example, although some of these chapter images can be in your 00:36:05.599 --> 00:36:10.239 MP 3 file, they really shouldn't be big images by pixel size and 00:36:10.239 --> 00:36:12.000 especially by file size. 00:36:12.159 --> 00:36:15.359 So what could happen is that when you upload an image that's too 00:36:15.359 --> 00:36:18.934 big for a chapter, Pod chapters could automatically downscale 00:36:18.934 --> 00:36:22.934 that image for the embedded chapters, where a small size is 00:36:22.934 --> 00:36:26.775 really important, and then do different optimizations for the 00:36:26.775 --> 00:36:29.015 Podcasting 2 and PodLove chapters. 00:36:29.329 --> 00:36:32.210 That way, you don't have to think about it. 00:36:32.369 --> 00:36:36.050 It just does it automatically for you and does it the correct way 00:36:36.130 --> 00:36:38.210 so that you don't have to worry at all. 00:36:38.289 --> 00:36:40.769 The same could go for text data too. 00:36:40.849 --> 00:36:45.094 Publishing tools should strip out unnecessary HTML code or weird 00:36:45.094 --> 00:36:47.894 formatting like you might frequently get, and maybe you've even 00:36:47.894 --> 00:36:51.255 run into this in the past when you're pasting from a document 00:36:51.255 --> 00:36:55.335 editing app like Microsoft Word or Google Docs or even sometimes 00:36:55.335 --> 00:36:59.494 Notepad or a Notes app can have certain hidden formatting in it 00:36:59.494 --> 00:37:03.389 that starts to just make stuff look weird or function weirdly 00:37:03.389 --> 00:37:06.670 inside your podcast app or it breaks something weird. 00:37:06.750 --> 00:37:09.949 And speaking of breaking things, they should also automatically 00:37:09.949 --> 00:37:11.710 validate your RSS feed. 00:37:11.710 --> 00:37:14.750 Now if they're not doing these optimizations, this isn't 00:37:14.750 --> 00:37:17.755 necessarily the worst sin. 00:37:17.755 --> 00:37:20.554 That's why this is farther down the list. Not necessarily. 00:37:20.554 --> 00:37:23.755 It's probably the lowest priority, but I've got this in this 00:37:23.755 --> 00:37:25.595 particular order because of the flow. 00:37:25.755 --> 00:37:29.849 And of course, many of these things shouldn't really matter if 00:37:29.849 --> 00:37:31.929 you do things right on your side. 00:37:31.929 --> 00:37:34.809 Like the whole uploading a WAV file and having the hosting 00:37:34.809 --> 00:37:37.449 provider convert it to an m p 3 file for you. 00:37:37.449 --> 00:37:40.650 That shouldn't matter if you're giving an m p 3 file that is 00:37:40.650 --> 00:37:42.170 already in the correct format. 00:37:42.444 --> 00:37:45.804 But I believe that podcasters shouldn't have to know these 00:37:45.804 --> 00:37:49.405 technical things like bit rates and loudness levels and image 00:37:49.405 --> 00:37:52.924 compression and image formats and dimensions and file sizes and 00:37:52.924 --> 00:37:54.125 all of that stuff. 00:37:54.204 --> 00:37:59.440 I want podcasting to just work so you can focus more on your 00:37:59.440 --> 00:38:01.200 content and your audience. 00:38:01.360 --> 00:38:04.720 And that's why many of the tools that I create now, especially 00:38:04.720 --> 00:38:07.760 the 2 biggest tools I have, Podgagement and PodChapters, there 00:38:07.760 --> 00:38:11.264 are a lot of things that I've put into this with deep love and 00:38:11.264 --> 00:38:12.625 passion for podcasting. 00:38:12.704 --> 00:38:16.704 Certain things that I want it to just work so you don't have to 00:38:16.704 --> 00:38:19.505 think about it. Just throwing out another example here. 00:38:19.505 --> 00:38:22.065 In Podgagement, you get multiple landing pages, like a 00:38:22.065 --> 00:38:25.585 followthepodcast.com and lovethepodcast.com that can display 00:38:25.910 --> 00:38:28.789 links to your podcast in different apps. 00:38:28.950 --> 00:38:34.789 Those pages automatically, smartly show and hide certain apps 00:38:34.789 --> 00:38:37.670 based on what kind of device is visiting the page. 00:38:37.925 --> 00:38:41.925 So if someone is on Android, for example, they won't see an Apple 00:38:41.925 --> 00:38:46.484 Podcast link or an Overcast link because those are for Apple 00:38:46.484 --> 00:38:47.525 products generally. 00:38:47.684 --> 00:38:51.284 If someone is on Windows, they will see an iTunes link because it 00:38:51.284 --> 00:38:54.910 is still iTunes on Windows, and they'll see that instead of Apple 00:38:54.910 --> 00:38:55.710 Podcasts. 00:38:55.710 --> 00:38:58.670 And if someone is on an Apple device, they won't see, for 00:38:58.670 --> 00:39:02.989 example, a Podcast Addict link because Podcast Addict is only for 00:39:02.989 --> 00:39:05.550 Android. So they shouldn't see Android apps. 00:39:05.550 --> 00:39:08.829 That kind of thing, the landing pages just do that automatically. 00:39:09.204 --> 00:39:10.565 You shouldn't have to think about it. 00:39:10.565 --> 00:39:13.204 You should just know, I send people to this page. 00:39:13.204 --> 00:39:17.204 They'll see links that can work on their devices, so you don't 00:39:17.204 --> 00:39:18.085 have to think about it. 00:39:18.085 --> 00:39:20.724 And so, certainly, you don't have to try and code that 00:39:20.724 --> 00:39:21.684 information yourself. 00:39:22.210 --> 00:39:26.369 So right after saying sin number 6 is not optimizing your media, 00:39:26.610 --> 00:39:32.449 sin number 7 is unnecessarily optimizing your media. Yes. 00:39:32.449 --> 00:39:35.489 Sometimes your media should not be optimized. 00:39:35.994 --> 00:39:40.074 Years ago, I stumbled into running multiple performance tests on 00:39:40.074 --> 00:39:43.914 podcast hosting providers, and I made some interesting additional 00:39:43.914 --> 00:39:45.515 discoveries in that process. 00:39:45.755 --> 00:39:49.690 1 of those discoveries was that some hosting providers would 00:39:49.690 --> 00:39:54.809 forcefully re encode your m p threes even if you had already 00:39:54.809 --> 00:39:58.010 encoded them to the spec perfectly. 00:39:58.090 --> 00:40:02.010 1 provider actually re encoded up to a higher level. 00:40:02.514 --> 00:40:07.074 So if you uploaded a 64 kilobit per second mono file, they might 00:40:07.074 --> 00:40:11.315 re encode it up to, we'll just say, 128 kilobits per second 00:40:11.315 --> 00:40:14.114 stereo. There was no need for them to do that. 00:40:14.114 --> 00:40:18.800 Or if they were even going up to 96 or 1 20 or 1 60 or any higher 00:40:18.800 --> 00:40:20.960 number, there's no need for them to do that. 00:40:20.960 --> 00:40:22.960 It's not improving the audio quality. 00:40:23.119 --> 00:40:27.039 It's only wasting space and bandwidth and processing time. 00:40:27.199 --> 00:40:32.244 Some providers don't re encode your media no matter what and see 00:40:32.244 --> 00:40:33.844 SIN number 6 for that. 00:40:34.005 --> 00:40:36.565 But I like the way Buzzsprout handles this. 00:40:36.804 --> 00:40:41.844 They will only re encode down if your media file is above their 00:40:41.844 --> 00:40:42.485 spec. 00:40:42.485 --> 00:40:47.130 But if you upload an m p 3 file that's already at or below their 00:40:47.130 --> 00:40:49.130 spec, they won't re encode it. 00:40:49.130 --> 00:40:52.889 So if you upload 96 kilobits per second mono, Buzzsprout does not 00:40:52.889 --> 00:40:53.690 re encode it. 00:40:53.690 --> 00:40:57.449 If you upload 64 kilobits per second mono, Buzzsprout does not re 00:40:57.449 --> 00:40:57.849 encode it. 00:40:58.244 --> 00:41:02.005 Similarly, with Captivate and Blubrry and Libsyn and several 00:41:02.005 --> 00:41:05.684 other podcast hosting providers, they will not unnecessarily re 00:41:05.684 --> 00:41:07.045 encode your media. 00:41:07.125 --> 00:41:11.045 And that's good that they don't re encode it when it shouldn't be 00:41:11.045 --> 00:41:14.119 re encoded Because some of these platforms are just trusting that 00:41:14.119 --> 00:41:16.839 you know what you're doing and that you encoded it properly or 00:41:16.839 --> 00:41:19.880 whatever publishing tool you're using to create the m p 3 file 00:41:19.880 --> 00:41:21.400 did it correctly for you. 00:41:21.559 --> 00:41:25.480 But hosting providers should not re encode it if it doesn't have 00:41:25.480 --> 00:41:26.440 to be re encoded. 00:41:26.594 --> 00:41:30.514 There's 1 particular provider that's been on multiple of these 00:41:30.514 --> 00:41:32.594 naughty lists and things I've mentioned in here. 00:41:32.594 --> 00:41:33.875 They're committing multiple sins. 00:41:33.875 --> 00:41:39.315 And what they do is they forcefully re encode the file even at 00:41:39.315 --> 00:41:42.275 the exact same encoding specs. 00:41:42.890 --> 00:41:48.410 But for some reason, their re encoded version ends up bigger than 00:41:48.410 --> 00:41:52.090 what the podcaster uploaded, and they stripped the chapters 00:41:52.090 --> 00:41:53.610 completely from it. 00:41:53.690 --> 00:41:57.930 And 1 of my listeners knows exactly what I'm talking about 00:41:57.485 --> 00:41:59.324 because they signed up for PodChapters. 00:41:59.324 --> 00:42:01.885 They were so excited to use PodChapters to create chapters for 00:42:01.885 --> 00:42:04.125 their podcast. They added all these great chapters. 00:42:04.125 --> 00:42:06.045 They loved how PodChapters work. 00:42:06.045 --> 00:42:08.765 They uploaded it to their podcast hosting provider that their 00:42:08.765 --> 00:42:11.324 podcast network uses, and they couldn't figure out why their 00:42:11.324 --> 00:42:12.125 chapters weren't working. 00:42:12.469 --> 00:42:16.469 And the reason is their hosting provider stripped the chapters 00:42:16.469 --> 00:42:20.309 and metadata from the file, reencoded it unnecessarily, and 00:42:20.309 --> 00:42:23.190 that's probably why all the metadata was stripped from it, losing 00:42:23.190 --> 00:42:24.389 all of those chapters. 00:42:24.549 --> 00:42:27.775 And they served that reencoded version even though their 00:42:27.775 --> 00:42:32.655 reencoded version was at the exact same encoding specs as what 00:42:32.655 --> 00:42:36.655 the podcaster uploaded, but the hosting provider's version was a 00:42:36.655 --> 00:42:38.735 bigger file. Make it make sense. 00:42:39.200 --> 00:42:43.039 They're certainly not doing it correctly. Shame on them. Shame. 00:42:43.039 --> 00:42:45.920 Shame. A similar thing can happen with images. 00:42:46.000 --> 00:42:50.720 Maybe you upload a perfectly compressed image that is optimized 00:42:50.880 --> 00:42:53.440 to whatever pixel level degree that you want. 00:42:53.784 --> 00:42:56.824 And it maybe it's only 20 kilobytes in size. 00:42:57.065 --> 00:43:00.505 But the publishing tool then automatically converts that image to 00:43:00.505 --> 00:43:04.505 a different format, possibly making the file size 10 times larger 00:43:04.505 --> 00:43:08.210 than it needs to be, or maybe even making the image look worse 00:43:08.210 --> 00:43:11.250 depending on the compression method that they're using for that 00:43:11.250 --> 00:43:11.809 image. 00:43:11.969 --> 00:43:17.010 Just for example here, PNG is really good for images that contain 00:43:17.010 --> 00:43:21.045 a lot of solid color, Like The Audacity to Podcast cover art is 00:43:21.045 --> 00:43:22.485 great in PNG. 00:43:22.485 --> 00:43:25.605 And most of the episode images that I make work really well in 00:43:25.605 --> 00:43:26.324 PNG. 00:43:26.324 --> 00:43:29.844 And that's why I save them as PNG because they have a lot of 00:43:29.844 --> 00:43:34.140 solid colors, and they're not very varied in colors. 00:43:34.140 --> 00:43:36.780 They're not photographs or anything. They're illustrations. 00:43:36.780 --> 00:43:39.820 They look like vector while they're made from vector art, which 00:43:39.820 --> 00:43:43.340 is scalable. So they work really well as PNGs. 00:43:43.734 --> 00:43:47.894 Convert the same image to a JPEG, and it's going to be a much 00:43:47.894 --> 00:43:51.815 bigger file if you try to maintain the same crispness. 00:43:51.815 --> 00:43:55.335 If you try to get its file size down to the same size as the PNG, 00:43:55.590 --> 00:43:58.550 then it starts getting blocky and blurry. 00:43:58.789 --> 00:44:03.269 I don't want any system that does that, that unnecessarily tries 00:44:03.269 --> 00:44:08.469 to optimize my file by converting it to JPEG when I wanted it to 00:44:08.469 --> 00:44:12.385 stay as PNG because the PNG I gave is the proper format. 00:44:12.464 --> 00:44:17.184 So these 7 deadly sins that podcast hosting providers might be 00:44:17.184 --> 00:44:21.264 committing are number 1, not redirecting your RSS feed. 00:44:21.264 --> 00:44:24.625 Number 2, using unpredictable media URLs. 00:44:24.909 --> 00:44:27.630 Number 3, changing your GUIDs. 00:44:27.630 --> 00:44:31.150 Number 4, improperly constructing your RSS feed. 00:44:31.389 --> 00:44:34.670 Number 5, stripping important data from your episodes. 00:44:34.670 --> 00:44:37.150 Number 6, not optimizing your media. 00:44:37.434 --> 00:44:41.355 And number 7, unnecessarily optimizing your media. 00:44:41.434 --> 00:44:44.715 If you catch your hosting provider committing 1 of these sins, 00:44:44.795 --> 00:44:46.474 feel free to send them this episode. 00:44:46.474 --> 00:44:50.440 And know that I have not put anyone under the bus here. 00:44:50.440 --> 00:44:53.400 Although, some providers, I think, kinda deserve it, but I'm not 00:44:53.400 --> 00:44:55.559 going to do that because I want to give them the chance to 00:44:55.559 --> 00:44:56.519 improve things. 00:44:56.599 --> 00:44:59.640 And you can send them this episode to point out to them, this is 00:44:59.640 --> 00:45:01.960 why this matters. Here's more information about this. 00:45:02.164 --> 00:45:04.964 This is really important to me, and I think maybe some other 00:45:04.964 --> 00:45:06.804 podcasters, please change this. 00:45:06.804 --> 00:45:09.605 So if you send anything to your podcast hosting provider, if you 00:45:09.605 --> 00:45:14.324 complain, please do it kindly and give them the chance to make 00:45:14.324 --> 00:45:14.804 things right. 00:45:15.219 --> 00:45:18.340 And if they won't, then you could consider switching. 00:45:18.420 --> 00:45:23.219 And if you need help, let me know who you're looking at and what 00:45:23.219 --> 00:45:26.099 particular features are most important to you, and I can help you 00:45:26.099 --> 00:45:27.860 pick the right hosting provider for you. 00:45:27.860 --> 00:45:30.644 Because I don't recommend just 1 particular provider. 00:45:30.644 --> 00:45:33.045 And by the way, if you look at the notes for this episode, some 00:45:33.045 --> 00:45:34.804 of my links will be affiliate links. 00:45:34.804 --> 00:45:38.005 And that's because many of these providers, I do recommend in 00:45:38.005 --> 00:45:40.005 certain context for certain uses. 00:45:40.309 --> 00:45:43.030 So depending on what you need, I'll recommend the hosting 00:45:43.030 --> 00:45:44.309 provider for you. 00:45:44.309 --> 00:45:47.030 The links for all of this that I shared, some of these past 00:45:47.030 --> 00:45:50.389 episodes and other references are at the audacity to 00:45:50.389 --> 00:45:53.349 podcast.com/hostingsends. 00:45:53.844 --> 00:45:57.844 Special thanks to Lindsay Phillips who had me on her podcast as a 00:45:57.844 --> 00:45:58.324 guest. 00:45:58.324 --> 00:46:02.324 Her podcast is leverage your podcast, and she had me on to talk 00:46:02.324 --> 00:46:04.724 about engaging your podcast audience. 00:46:04.724 --> 00:46:06.485 It was a really fun conversation. 00:46:06.485 --> 00:46:09.840 We did talk a lot about Podgagement in that episode, but also 00:46:09.840 --> 00:46:13.039 just about engaging your audience in general because that's what 00:46:13.039 --> 00:46:15.440 Podgagement was designed to help you do. 00:46:15.440 --> 00:46:18.640 So please go listen to that episode from Lindsay Phillips. 00:46:18.640 --> 00:46:20.320 I've got the link to that in the notes. 00:46:20.400 --> 00:46:23.840 And thanks to Podfest Multimedia Expo for accepting my session 00:46:23.840 --> 00:46:26.795 proposal for Podfest 20 26. 00:46:26.875 --> 00:46:30.234 I'm thrilled to be sharing what you need to know about podcasting 00:46:30.234 --> 00:46:34.074 2 at Podfest, so I would love to have you there in the audience. 00:46:34.155 --> 00:46:39.760 Please join me at Podfest January in Orlando, Florida. 00:46:39.760 --> 00:46:43.599 I've got the link to podfestexpo.com in the notes or, hey, I just 00:46:43.599 --> 00:46:45.440 mentioned the URL for you. 00:46:45.519 --> 00:46:47.440 And those notes are once again at the 00:46:47.440 --> 00:46:51.494 audacitytopodcast.com/hostingsins. 00:46:51.655 --> 00:46:54.214 Now that I've given you some of the guts and taught you some of 00:46:54.214 --> 00:46:57.494 the tools, it's time for you to go start and grow your own 00:46:57.494 --> 00:46:59.815 podcast for passion and profit. 00:46:59.974 --> 00:47:03.739 Please check out my new product, podchapters.com, now available 00:47:03.739 --> 00:47:08.619 with a free 7 day trial over at podchapters.com. I'm Daniel J. 00:47:08.619 --> 00:47:12.059 Lewis from theaudacitytopodcast.com. Thanks for listening.