Problems with the addition of new lines in the srt files

[eduo]

This debate reminds me of my cchool Days, my father's car is better
Personally I don't like special characters (♫ etc) in subtitles

Some languages are *made* of "special characters". It's not a matter of personal preference whether they're needed, since chinese, greek or russian subtitles are entirely made of them. The discussion was more about whether ANSI encoding with codepages (still the most common one) is enough (it isn't) or whether we should do our part enforcing UTF for character sets (which need no guessing and cover more characters (and language variants) than all ANSI, ISO and codepages combined.

[SimplyTheBOSS]

This debate reminds me of my cchool Days, my father's car is better
Personally I don't like special characters (♫ etc) in subtitles

Some languages are *made* of "special characters". It's not a matter of personal preference whether they're needed, since chinese, greek or russian subtitles are entirely made of them. The discussion was more about whether ANSI encoding with codepages (still the most common one) is enough (it isn't) or whether we should do our part enforcing UTF for character sets (which need no guessing and cover more characters (and language variants) than all ANSI, ISO and codepages combined.

Yes, I know that. I use only Finnish subtitles, that's what i meant "personal". I think both ANSI and UTF should stay.

[srtpal]

This debate reminds me of my cchool Days, my father's car is better :)
Personally I don't like special characters (♫ etc) in subtitles

When I went to school, we didn’t have cars because it was near impossible to buy one in Communist Czechoslovakia.

Anyway, how do you let the hearing impaired know that someone is singing the text if not with a ♫? I prefer it over italics, since not all players support them and since they can mean the text is spoken off screen, so they are confusing. And I certainly prefer the ♫ over typing out something like (sings), for two reasons: One, ♫ is just one character while (sings) is seven characters and (spieva) (in my language) takes up eight characters; and two, ♫ does not require reading, which requires thinking and analyzing the text, so ♫ speeds up reading and comprehension. Those who hear just fine can ignore it altogether, while it greatly helps the hearing impaired.

I actually use the ♫ for singing and the ♪ for humming and for parlando (singing without a melody, i.e., talking the text of a song). Now, if only I could find a Unicode symbol to indicate the voice is coming from the phone (since I am currently working on the Czech subtitles for Knight Moves where the phone conversations are an essential part of the plot).

[SimplyTheBOSS]

This debate reminds me of my cchool Days, my father's car is better
Personally I don't like special characters (♫ etc) in subtitles

When I went to school, we didn’t have cars because it was near impossible to buy one in Communist Czechoslovakia.

Anyway, how do you let the hearing impaired know that someone is singing the text if not with a ♫? I prefer it over italics, since not all players support them and since they can mean the text is spoken off screen, so they are confusing. And I certainly prefer the ♫ over typing out something like (sings), for two reasons: One, ♫ is just one character while (sings) is seven characters and (spieva) (in my language) takes up eight characters; and two, ♫ does not require reading, which requires thinking and analyzing the text, so ♫ speeds up reading and comprehension. Those who hear just fine can ignore it altogether, while it greatly helps the hearing impaired.

I actually use the ♫ for singing and the ♪ for humming and for parlando (singing without a melody, i.e., talking the text of a song). Now, if only I could find a Unicode symbol to indicate the voice is coming from the phone (since I am currently working on the Czech subtitles for Knight Moves where the phone conversations are an essential part of the plot).

Not even Trabants

I understand what you mean, but song lyrics are not usually translated in finnish subtitles, thts why i said personal.
If they are translated it will be showing like this [LAULAA] (singing), or something like that.

[eduo]

This debate reminds me of my cchool Days, my father's car is better
Personally I don't like special characters (♫ etc) in subtitles

When I went to school, we didn’t have cars because it was near impossible to buy one in Communist Czechoslovakia.

Anyway, how do you let the hearing impaired know that someone is singing the text if not with a ♫? I prefer it over italics, since not all players support them and since they can mean the text is spoken off screen, so they are confusing. And I certainly prefer the ♫ over typing out something like (sings), for two reasons: One, ♫ is just one character while (sings) is seven characters and (spieva) (in my language) takes up eight characters; and two, ♫ does not require reading, which requires thinking and analyzing the text, so ♫ speeds up reading and comprehension. Those who hear just fine can ignore it altogether, while it greatly helps the hearing impaired.

I actually use the ♫ for singing and the ♪ for humming and for parlando (singing without a melody, i.e., talking the text of a song). Now, if only I could find a Unicode symbol to indicate the voice is coming from the phone (since I am currently working on the Czech subtitles for Knight Moves where the phone conversations are an essential part of the plot).

Not even Trabants

I understand what you mean, but song lyrics are not usually translated in finnish subtitles, thts why i said personal.
If they are translated it will be showing like this [LAULAA] (singing), or something like that.

Same here. I use #for music#, [for voices off scene], like heard on a phone or a narrator and (for whispering). When I do hearing-impaired subtitles (for Deaf) I wrap sound effects or actions in asterisks, *sigh*, *phone clicks*, etc. I don't use tags (BB or HTML) because they require the player interpreting and displaying them properly.

Yes, I advocate UTF on one side but text hints instead of special tags for context hints. I know.

[srtpal]

Not even Trabants :roll:

Not when I went to school. Trabants came later. I mean, they did exist, but they were still rare, at least in Bratislava, where I am from.

A few people owned a Škoda, we even owned a Volga for a few years, but the point is, cars were rare. We did not brag about them.

[NomadaPT]

Now, if only I could find a Unicode symbol to indicate the voice is coming from the phone (since I am currently working on the Czech subtitles for Knight Moves where the phone conversations are an essential part of the plot).

Arial Unicode MS cover the following symbols
✆ U+2706 TELEPHONE LOCATION SIGN (Dingbat range)
☎ U+260E BLACK TELEPHONE (Miscellaneous symbols)
☏ U+260F WHITE TELEPHONE (Miscellaneous symbols)

I think there's other but not covered i the main TrueType or OpenType fonts around. What I'm not sure is if the symbols are rendered if you have another font as default in the Vobsub.

[srtpal]

Code: Select all

1 00:00:01,000 --> 00:00:04,074 Subtitles downloaded from www.OpenSubtitles.org 2 00:01:48,480 --> 00:01:52,520 "Salmos de Recuperação Espiritual" 3 00:02:08,320 --> 00:02:12,040 Um salmo de David. "Bem-aventurado é aquele que atende ao pobre,

Wait a minute. It actually replaces the first subtitle? If so, that is BAD! I don’t mind too much if it inserts the message BEFORE the first subtitle and renumbers the rest, but replacing the first subtitle would make me think twice about my continuous contribution to OS.

I work hard on my subtitles. They contain nothing that does not belong there. And I do not appreciate when someone else takes credit for my hard work and actually messes up my work. No way! This must stop!

Again, I can live with inserting it before the first subtitle and after the last one, but not replacing anything. Those are my subtitles. Changing them is not cool, and in countries that have copyright laws outright illegal.

It is OS that is pushing automatic downloaders, not us authors. If they are losing advertising revenue, they should not be pushing automatic downloads and only allow people to download them directly from the web site. Either that, or place an ad in a separate file within the .zip file, but not delete lines from the subtitles submitted by independent volunteers. We do not get paid for our efforts, why should someone else? This is serious!

[srtpal]

Arial Unicode MS cover the following symbols
✆ U+2706 TELEPHONE LOCATION SIGN (Dingbat range)
☎ U+260E BLACK TELEPHONE (Miscellaneous symbols)
☏ U+260F WHITE TELEPHONE (Miscellaneous symbols)

Thanks. On my Windows 7, Arial does not support them, only MS Gothic does. And since Arial seems to be the font most players use, this prevents me from using them.

[NomadaPT]

Wait a minute. It actually replaces the first subtitle? If so, that is BAD! I don’t mind too much if it inserts the message BEFORE the first subtitle and renumbers the rest, but replacing the first subtitle would make me think twice about my continuous contribution to OS.

Like I said in the beginning, it only happens when the subtitle have a really early line, before the first minute, and that isn't so common at all.

----------------------------------------------------------

@oss:

I REALLY don't know how or why, but since I've started this subject the changing of the encoding never happen again, and I've tried several computers and operating systems. The first thought that occurred was any kind of glimpse in my PC, however, the problem wasn't initially detected by me but from a non-member friend and tested my myself, reason why I've created this topic. Normally, when I download any subtitle I do through the Media Player Classic and the ads never appear (logged or not) so, until recently, I never notice any kind of change in the subtitles or in the encoding.

Since that part of the problem don't occur again, I ask you tho forget that part and focus in the replacement of the first line.

------------------------------------------------------

About the encoding in general, I firmly believe that Unicode, particularly UTF-8, is the only way to go, and I'm gonna keep encoding all my subs that way, BUT... is a personal choice, a personal believe that the former ANSI code pages are obsolete, I don't criticize no one that rather use them, especially the one's with english as native tongue. There's no reason to almost transform that issue in a war about text encoding, at the present time choosing between ANSI or Unicode (when subtitles are the subject) still is a personal choice, in a non far future I only see one way and that's Unicode.

[srtpal]

Well, I just tested it. I downloaded one of my subs using SubDownloader, another from the web without logging in, and in both cases the subs came exactly as I had uploaded them. No ads.

So, I’m happy and will continue to contribute.

[jcdr]

Oss, I too agree 200% on the need to accept UTF-16 for OpenSubtitles. After all, it is a variable length code so it should not take a lot more space, if this is the reason for not accepting it ?

More than 50% of Windows softwares have moved from ANSI to Unicode. Including subtitle and video softwares, and internet (xtml, java, PHP...). Privileging the ANSI for a subtitle website in 2012 is indeed OK for English language users, but will keep on putting off many Asiatic people which are the main potential users.

[oss]

OS accepts UTF-8, I got some problems with UTF-16 while parsing the files and so on. Is there really need to have UTF-16 support, is not UTF8 enough?

[NomadaPT]

OS accepts UTF-8, I got some problems with UTF-16 while parsing the files and so on. Is there really need to have UTF-16 support, is not UTF8 enough?

Well... personally, at least in a near future, I believe so, UTF-8 is the common encoding system through the net, however, Windows, Java and other programs they all use UTF-16, srtpal, proved that when reported that TotalMedia Theatre 5 only supports 16-bit Unicode.

More info: http://unicode.org/faq/utf_bom.html

[scooby007]

Thanks for the laugh, guys! So much to cover, I'll try my best. I don't agree with eduo on the part that UTF should be the only way to go, I'd have to agree with STB that both should be available. When I used to edit subtitles, I always used ANSI and changed ♫ to # to represent music or songs. It's not difficult using "Edit -> replace all". In regards to what srtpal said, it's not that easy to get all standalone player manufactures to support UTF. Even if they did, it would be still difficult since most programs that incorporate subtitles into the avi file for you to burn to disc don't recognize UTF, and even refuse to do the job. You not only have to change the DVD players to accept them, but also the programs that I just mentioned. Until all these changes are made systematically, ANSI should be made avilable and supported. I see where you guys are coming from, but both should be available to accommodate many users who need ANSI to burn discs for the standalone player. The most famous programs available that infuse a subtitle/avi file together for disc don't support UTF. If I'm watching a movie on my PC, I have no problems with UTF format, but to watch it on the box, I will definitely need to convert the srt to ANSI.

If certain languages aren't supported by ANSI, then by-all-means use whatever format accommodates your preferences, but don't subject/force your way of thinking onto others who still benefit from the old format (and many do). I think current world affairs dictates that this doesn't work. I also agree with subshare that the advertisement should appear at the end of the subtitle (if it has to stay), otherwise I did warn the loss of many users, and more importantly, many contributors of good subtitles. Without them, the site won't work nor will it be able to compete with other sites.

@ oss I think UTF-8 is enough for now, but as NomadaPT points out, we should be able to accept UTF-16 in the future as many programs are beginning to use this format. As the owner of this site, I would be making my way to gradually bringing it in and making it a part of opensubtitles.