3 ms·
I was going for "set up some code once and don't think about it again" to maximise the odds of the idea sounding tempting. Proofreading would set up an expecta
by mst 3y ago
I was going for "set up some code once and don't think about it again" to maximise the odds of the idea sounding tempting.
Proofreading would set up an expectation on the part of readers that it -had- been proofread and corrected and therefore a commitment to perform a repeated "boring but important" task going forwards for whoever's doing said proofreading.
That way would likely lie either delayed transcripts or never getting to initial activation energy to provide anything at all.
So I think "add a quick bit of code to your podcast publishing workflow and a CAVEAT IN BIG LETTERS" is better to do first.
If it turns out enough people care about the transcript, doing it a more labour intensive nicer way later is something they can decide, well, later.
Shipping is feature zero, as ever.
- actionfromafar 3y agoI hate bad transcripts.
- mst 3y agoThe automatic transcribers have (pretty recently) reached the point where I'd rather have their output than not. This came as something of a surprise to me - six months ago I'd likely have been enthusiastically agreeing with you. As an example, the transcript tab on https://www.thebulwark.com/podcast-episode/tom-nichols-jack-smith-is-not-screwing-around-2/ https://www.thebulwark.com/podcast-episode/tom-nichols-jack-... was pretty readable to me in spite of the errors. Whether you'll find it the same is, of course, a separate question.