Because of the way those captions are stored VLC has to use OCR to convert the .SRT file (which basically stores low resolution b/w images I assume to easier allow for different alphabets) to normal text. I don’t know why the open source solutions are so bad at this (especially considering how good the proprietary solutions seem to be) but I had similar problems ripping a DVD. I would assume that had he turned off the special font VLC uses for the subtitles and instead just seen the raw data there wouldn’t have been a problem. Why VLC doesn’t enable this by default (/ have this) I don’t know.
This is not about DVD subtitles, which are images as you say. This is about “Line 21” closed captioning. I.E. the text data that is embedded in an analog tv signal. There should be no OCR needed.
I’m surprised VLC fares that badly with CCs encoded this way. Usually it’s pretty good. I’m also now wondering if ffmpeg also shares the same problem
Because of the way those captions are stored VLC has to use OCR to convert the .SRT file (which basically stores low resolution b/w images I assume to easier allow for different alphabets) to normal text. I don’t know why the open source solutions are so bad at this (especially considering how good the proprietary solutions seem to be) but I had similar problems ripping a DVD. I would assume that had he turned off the special font VLC uses for the subtitles and instead just seen the raw data there wouldn’t have been a problem. Why VLC doesn’t enable this by default (/ have this) I don’t know.
This is not about DVD subtitles, which are images as you say. This is about “Line 21” closed captioning. I.E. the text data that is embedded in an analog tv signal. There should be no OCR needed.
There is no .srt in this case. This is also not about bitmap dvd vobsubs.