0.
저는 과거 한동안 CCMP를 사용하다 현재는 SMISyncW로 정착을 했습니다. SMISyncW의 특징은 직관적인 인터페이스와 단축키의 편리함입니다. 게다가 SMISyncW 하나만 있으면 싱크 조절 및 포맷 변환이 가능해 별도의 다른 툴이 필요 없습니다. 거기다 싱크 오류 검사 기능(자막 검증)이 있어 자막에 오류가 있는지 없는지도 여부를 한 번에 확인할 수 있습니다.


1.
그런데 Subtitle Edit라는 툴은 SMISyncW보다도 기능이 많습니다. 다른 기능은 차치하고 싱크 검사의 측면에서 보면, SMISyncW는 싱크 검사 시 단순히 대사의 텍스트 길이 및 지속 시간만 확인하는 반면, Subtitle Edit는 대사별로 텍스트 길이/지속 시간까지 확인할 수 있습니다. 같은 10글자 대사라도 그게 4초에 지나간다면 문제가 없겠지만 1초에 지나간다면 문제가 있다고 할 수 있죠.


2.
또한 대사 사이의 최소 시간도 한 번에 조절할 수 있습니다(Tools>Minimum display time between subtitles). 어떤 자막을 보면 대사가 이어질 때 종료 태그(smi의 경우  )를 사용하지 않는 걸 볼 수 있습니다. 예를 들어보죠.

<SYNC Start=148775><P Class=KRCC>
근처에 괜찮은 레스토랑이 있나요?
<SYNC Start=150902><P Class=KRCC>
사람에게는 워싱턴에<br>
돌아가야 있을 테고

저는 이런 싱크 코딩 습관에 반대하는 입장입니다. 제 자막에서 태그 사용을 최대한 배제하는 것과 같은 이유로서, 바로 '호환성' 때문입니다(나이가 들자 TV를 장만하고 DLNA로 영화를 보는 일이 생기는데, TV 같은 기기는 대부분의 태그를 지원하지 않습니다). 위와 같은 싱크는 대부분의 PC용 프로그램에서는 재생에 문제가 없을지 몰라도, 종료 태그가 없다는 점에서 PC 외 기기에서의 재생 혹은 타 자막으로의 변환 시 문제가 될 소지가 '없다고 할 수 없습'니다.

혹은 오늘 어떤 영문 srt 자막을 보니 대사가 이어질 경우 종료 시각을 다음 대사 시작 시각과 똑같이 설정했더군요. smi 코드로 보면 다음과 같다는 얘기입니다.

<SYNC Start=148775><P Class=KRCC>
근처에 괜찮은 레스토랑이 있나요?
<SYNC Start=150902><P Class=KRCC>&nbsp;
<SYNC Start=150902><P Class=KRCC>
사람에게는 워싱턴에<br>
돌아가야 있을 테고

이런 작성법 역시 기기에 따라 자막 출력이 원활하지 못할 수 있습니다. 따라서

<SYNC Start=148775><P Class=KRCC>
근처에 괜찮은 레스토랑이 있나요?
<SYNC Start=150901><P Class=KRCC>&nbsp;
<SYNC Start=150902><P Class=KRCC>
사람에게는 워싱턴에<br>
돌아가야 있을 테고

이렇게 1ms라도 다음 대사와 간격을 두고 반드시 종료 태그를 넣는 것이 옳습니다. Subtitle Edit를 이용하면 일괄로 조절할 수 있습니다.


2.
그러나 Subtitle Edit는 외국산 툴로서 현존 최강 다양한 포맷을 자랑하지만 국내에서 사용되는 smi에 특화된 툴은 아닙니다. Subtitle Edit에서 작업한 뒤 smi 파일로 저장하면 그 smi 파일은 일반 텍스트 뷰어로는 내용을 알 수 없습니다. 위 자막의 경우 이렇게 저장됩니다.

<SYNC Start=148775><P Class=KRCC>&#44540;&#52376;&#50640;&#160;&#44316;&#52270;&#51008;&#160;&#47112;&#49828;&#53664;&#46993;&#51060;&#160;&#51080;&#45208;&#50836;?
<SYNC Start=150902><P Class=KRCC>&#49324;&#46988;&#50640;&#44172;&#45716;&#160;&#50892;&#49905;&#53556;&#50640;<br>&#46028;&#50500;&#44032;&#50556;&#160;&#51080;&#51012;&#160;&#53580;&#44256;

이것은 문자코드 인코딩 문제가 아닙니다. 추측컨대, smi 포맷이 html에 기반하므로, smi 파일 저장 시에는 html 문자(entites)로 저장하는 것이 smi 파일의 표준에 부합하기 때문인 듯합니다.

(그러나 국내 '현실'에서는 저런 smi 파일을 용납(?)할 수 없습니다. 저렇게 저장된 smi 파일의 경우 html 문자를 일반 텍스트로 디코딩하면 됩니다. 가령 http://htmlentities.net/ 이런 사이트에 가서 위 Input 폼에 smi 파일 전체 내용을 복사해서 붙여 넣고 [decode] 버튼을 누르면 아래 Result에 일반 텍스트로 디코딩된 내용이 나옵니다. 이를 다시 전체 복사해서 smi 파일에 붙여 넣으면 됩니다만... 물론 이는 번거로운 일입니다. 결론적으로 말해 이 방법을 쓸 필요는 없습니다. srt로 저장하고 다른 툴(가령 SMISyncW)에서 불러오면 그만입니다.)


3.
또한 저는 1에서 대사와 대사 사이 간격을 1ms라도 줘야 한다고 말했고, Subtitle Edit에서도 일괄로 그렇게 수정했습니다. 그럼에도 2의 코드를 보면 종료 태그가 사라진 것을 볼 수 있습니다. 대사 간 최소 간격을 100ms 정도로 여유 있게 설정해야 smi 저장 시에도 종료 태그가 사라지지 않는 걸 확인했습니다.

이렇게 Subtitle Edit에서 smi 파일로 저장할 때뿐만 아니라, smi 포맷 자체로 작업할 때에도 여러 문제가 있습니다. 특히 Text 우측의 칼럼(메인 화면에서는 Class 칼럼)에 잘못된 정보가 표시되는 버그가 있습니다.

결론적으로 Subtitle Edit에서 작업한다면 smi가 아니라 srt로 작업하고, 저장 역시 smi가 아니라 srt로 저장하는 것이 가장 낫다고 할 수 있습니다. 다만 저는 SMISyncW의 단축키가 손에 익어 여전히 SMISyncW를 이용해 번역을 합니다. Subtitle Edit는 보조적으로 자막 간 최소 시간 등 싱크 수정(및 검사) 용도로 사용하는 정도입니다.

[이 게시물은 再會님에 의해 2015-10-06 16:33:22 자막제작가이드에서 이동 됨]