4 ms·

>Why would mobile devices need to do this themselves? Couldn't Google do this with a podcast/audiobook service To answer your question, what's the baseline pr

by jasode 4y ago

>Why would mobile devices need to do this themselves? Couldn't Google do this with a podcast/audiobook service To answer your question, what's the baseline premise of how podcasts should work on a mobile phone? - Should podcasts/audiobooks continue to be local files such as mp3/m4b that's copied to the mobile phone? If so, the companion technology to enable "captions" would also require a local transcript file that's copied to the phone. (Like srt files for mkv.) In that case, a Google podcast transcript service that created such text files would require the whole podcast ecosystem and app players to change and recognize timestamped transcript files. E.g. even if you embed transcript into mp3/m4b container files, Apple's Podcast player app isn't going to know about it. So would it require everyone to download 3rd-party podcast players? So this scenario -- while not impossible -- has a lot of barriers to adoption. Too few consumers probably care about it. - Or should podcasts/audio be streamed from the cloud -- like Youtube videos -- to more easily enable your captions feature request? In this scenario, Google's podcast transcription wouldn't require embedding the text in new audio file formats for distribution. But you still have the mobile apps incompatibility issue of displaying the captions for podcasts. Again, Apple's Podcast app doesn't know about streamed captions. You also have content creators locked into Google's hypothetical podcast-with-captions-streaming cloud ecosystem which many wouldn't want to do.

mattmaroon 4y ago
Could be both right? Your podcast app could generate captions on the server (assuming, as mentioned above, that on-device hardware limitations prevent doing so on the phone itself) as a file that you download along with the mp3. They'd only have to generate one file for every episode of every podcast that anyone subscribes to, which doesn't seem like it'd take much hardware. There arent' THAT many. Could even be one third party service they all use, like how all the audio players used to use CDDB for cover art, track names, etc. Apple's podcast app is probably the biggest impediment to podcast technology, but no reason 3rd party apps couldn't all do this.
- Tagbert 4y ago
  Other than economics. It would be a large expensive in terms of bandwidth, processing, and maintenance of the TTS service. It can be difficult to get users to pay for the core content, let alone optional secondary content like this.

by jasode 4y ago

mattmaroon 4y ago

Could be both right? Your podcast app could generate captions on the server (assuming, as mentioned above, that on-device hardware limitations prevent doing so on the phone itself) as a file that you download along with the mp3. They'd only have to generate one file for every episode of every podcast that anyone subscribes to, which doesn't seem like it'd take much hardware. There arent' THAT many. Could even be one third party service they all use, like how all the audio players used to use CDDB for cover art, track names, etc. Apple's podcast app is probably the biggest impediment to podcast technology, but no reason 3rd party apps couldn't all do this.

Tagbert 4y ago
Other than economics. It would be a large expensive in terms of bandwidth, processing, and maintenance of the TTS service. It can be difficult to get users to pay for the core content, let alone optional secondary content like this.