On 9 March 2013 20:13, Mark Barker <mark.bar...@shaw.ca> wrote: > Hi Jon,
please write to the get-iplayer list, not to me directly. > I was just updating all things get_iplayer on my Win7 x64 setup today. One > thing I noticed is that your git repo commit:- >... modifies the character encoding used in the .srt files generated by > get_iplayer - my Notepad++ identifies the encoding of these files as "ANSI > as UTF-8" (I believe this is Notepad++'s nomenclature for a UTF-8 encoding > without a BOM). > > This actually BREAKS the default behaviour when subsequently muxing these > .srt files into .mkv containers using mkvtoolnix (mkvmerge GUI) > i.e. if I mux the .mp4 and .srt (with its new "ANSI as UTF-8" .srt output > format) into an .mkv, I have to take an extra step to manually override the > character encoding type (charset) for the .srt file in the mkvmerge GUI (to > UTF-8), else the resultant .mkv will end up have corrupted subs for some of > the special characters, e.g. £ > > I would actually prefer it if this 'new' format change was an option and not > the default behaviour of get_iplayer, since this has been working without > incident for me since forever previously! Failing that, a get_iplayer > cmdline fallback option to the non-UTF-8 original encoding would be much > appreciated. seems a reasonable view. I'll have a think about what makes a sensible option, and think again what constitutes sensible default behaviour, and propose a patch. But I note that mkvmerge converts the subtitles to UTF-8 if they're not already that. Unless someone else gets there before me. Jon _______________________________________________ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
