Creates invalid VTT files
Closed this issue · 8 comments
The timestamp format is supposed to use decimal points instead of commas. This program does not make that change.
I just tested both of the current executable files on the platforms I have available to me at the moment (OS X Mavericks and Windows 7 SP1 64-bit) and I was not able to reproduce your issue (since this line in the program is where commas get replaced by decimal points in the timestamp).
If you could please tell me what operating system you are using and the command you are using to run the application (if are using a command instead of just double-clicking the program to run it) that would help me in resolving this issue.
Thanks for the prompt reply! I am running from the command line on OSX 10.9.3. I am chmod'ing the file and running it as ./srt-vtt - with or without arguments I just tested again and got the same result: the commas are not replaced. A diff on the two files reveals only the WEBVTT header; the rest of the file is unchanged. My only guess is that it might have to do with the end-of-line? The files I'm using include a "\r\n" I think - they are from amara.org. I'd attach one for you to try but I don't see how to do that here. Hope that is helpful.
I used amara.org to produce a SubRip subtitles file, and upon trying to convert it I was able to reproduce the issue. It seems the files produced by amara.org use a character set the program does not recognize. If it is just plain UTF-8 (which I suspect it is), this should be fixable.
In the mean time, I was able to have the file convert successfully after copying and pasting the text into a new file (I used Sublime Text to do this since Mac's TextEdit won't standardize the characters copied over).
I'm all set now - thanks for your response!
@needlestack turns out you were right. The problem was that files with "\r\n" line endings weren't being handled correctly on OS X. This has been fixed in the latest version.
Great, thanks :)
On Sun, Jan 25, 2015 at 9:11 AM, Nathan Woltman notifications@github.com
wrote:
@needlestack https://github.com/needlestack turns out you were right.
The problem was that files with "\r\n" line endings weren't being handled
correctly on OS X. This has been fixed in the latest version
https://github.com/woollybogger/srt-to-vtt-cl/tree/master/bin/Mac-OSX.—
Reply to this email directly or view it on GitHub
#1 (comment)
.
I've encountered same problem (in 2021!).
Using the command line version for Windows 7 64b.
I made the srt file myself in NotePad2, using ANSI (ASCII) encoding.
Only the WEBVTT header was placed in the file, the commas were unchanged.
@hoemaco Sounds like the cause for your issue might be slightly different since you're on Windows (and the original issue was on OS X). Please open a new issue using this template so I can better understand what's going wrong: https://github.com/nwoltman/srt-to-vtt-cl/issues/new?assignees=&labels=&template=conversion-bug-report.md&title=