search

nwoltman / srt-to-vtt-cl

A command line tool that converts subtitle files from SubRib (.srt) format to WebVTT (.vtt) format
MIT License
95 stars 11 forks source link

Creates invalid VTT files #1

Closed needlestack closed 10 years ago

needlestack commented 10 years ago

The timestamp format is supposed to use decimal points instead of commas. This program does not make that change.

nwoltman commented 10 years ago

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.

needlestack commented 10 years ago

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.

nwoltman commented 10 years ago

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).

needlestack commented 10 years ago

I'm all set now - thanks for your response!

nwoltman commented 9 years ago

@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.

needlestack commented 9 years ago

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 https://github.com/woollybogger/srt-to-vtt-cl/issues/1#issuecomment-71357305 .

hoemaco commented 3 years ago

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.

nwoltman commented 3 years ago

@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=