Hello AntennaPod Team
Is there any documentation available on how Chapter Marks must look like in mp3 files so that AntennaPod displays them correctly. I’m always struggeling with it; sometimes they are shown, sometimes not. Here are two example:
This mp3 shows chapter marks in AntennaPod:
This one not:
Here is the RSS-feed for the podcast:
I’d really appreciate getting an advice or documentation about the correct way to do it.
The mp3 file of episode 13 contains an id3 extended header. These are not supported by AntennaPod currently. I just fixed that - the extended header (and therefore the chapters in your podcast) will be supported in AntennaPod 2.4.0
Would it be possible that you export a 10-second silent mp3 file with the same method that you used for episode 13, containing 2-3 chapters with generic titles (“Chapter 1”, …)? Then we could add that mp3 to AntennaPod’s test suite and could therefore ensure that it will not break in future updates. The file would be added to the open-source code and therefore be publicly available.
Thank you for fixing it. Meanwhile I found a better method to provide chapter marks. Instead of embedding them in the mp3-file (probably it was never meant to be), I put the chapter marks in the RSS-file like this:
<enclosure url="https://gnulinux.ch/podcast/GLN_013.mp3" length="102384956" type="audio/mpeg" />
<psc:chapter start="00:00:00" title="Willkommen beim GnuLinuxNews-Podcast"/>
<psc:chapter start="00:06:00" title="Wie wird der GLN-Podcast erstellt?"/>
<psc:chapter start="00:27:22" title="In der Nische liegt die Kraft"/>
<psc:chapter start="00:44:05" title="Debian 11"/>
<psc:chapter start="01:05:17" title="Interview RadioTux"/>
I think this is the cleaner approach because it avoids one step in the toolchain, e.g.: mp3chaps.py, and is easier to implement programmatically.
Yeah, I like those more, too. The podlove chapter specification above even supports chapter images by using the
If you’re thinking about adding/updating podcast chapters after releasing the podcast itself, you might also be interested in the dedicated Podcast RSS namespace tag for chapters. (Though AntennaPod doesn’t support this at this point.)
I would propose to setup the rule that Antennapod should priorize the XML. If both Data are available. If information like a Picture is missing in XML but available in the file, take it from the file.
Sorry, took a while. Here is the requested test file: chapter_mark_test.mp3
(Please download it soon, because it will not stay forever.)
The file was produced with Audacity 3.0.2 with these MP3 tags:
Track title: Chapter mark test file for AntennaPod
Album title: GnuLinuxNews
Track number: 1
Chapter marks were injected with mp3chaps.py with this content:
00:00:07 Chapter 1
00:00:09 Chapter 2
00:00:11 Chapter 3
I hope it helps.
Here is a comment from GNU/Linux.ch regarding this issue, which may be of interest:
“It may be easier to store the information in rss at the beginning. But the undeniable advantage of metadata in MP3 is the possibility to always archive the information together. I also like to share MP3 files from Antennapot directly with Kodi. If they should ever be able to display this information on the TV, you could also create added value. In my opinion, there should be a tool for podcasters that not only generates the rss information but also supplements the meta information. Or mp3chaps should also be able to create the rss information.”
Source: Kapitelmarken im Podcast (translated from German)
On the one hand, I think that he has a valid point, because of the integration of information (all in the mp3 file), on the other hand, a single mp3 file is not a podcast. A podcast is a series of mp3 files plus an RSS-feed containing the metadata.
Thanks a lot for the file! Added it to the AntennaPod tests here: Added chapter marks test file with extended header by ByteHamster · Pull Request #5345 · AntennaPod/AntennaPod · GitHub
The problem I see with chapter marks is that there are too many competing standards. Each media file format has its own specification with support for different attributes (ogg/vorbis, IDv3 in mp3, m4a). In the feed, there are the podlove simple chapters and there is now the podcast namespace chapters tag. The problem with competing standards is that basically everyone (both podcasters and player apps) now needs to support all of these standards to make sure it works everywhere
Thanks for that feedback. It’s interesting as an user to see behind the sceens and your valuable job.