Intro
여러분은 자막 파일에 대해 얼마나 알고 계신가요? AI를 사용한 자막 번역은 저희회사 XL8의 비즈니스 중 큰 부분을 차지하지만, 정작 회사의 개발자인 저도 흔히 보는 SRT 자막 외엔 아는 것이 거의 없었습니다. 그러다 다음과 같은 질문을 받게 되죠.
- 자막을 화면 하단이 아닌 상단에 표시할 수 없나요? 우측 정렬할 수 없나요?
- 자막에 색깔을 입힐 수 있나요?
- 우리 회사가 사용하는 자막 파일(e.g., TTML)을 XL8의 미디어캣에서 지원하나요?
개발자로서 위 질문에 대한 저의 답은 "여러분이 사용하시는 자막 파일에 따라 달라요 (it depends ...)" 입니다. 하지만 보다 자신있게 답하기 위해, XL8과 미디어, 번역 업계가 사용하는 자막 파일과 그 특성에 대한 정리의 필요성을 느꼈고 그에 따른 자막 파일에 대한 제 노력의 결과는 상당히 참혹했습니다.
개발자들은 사실상의 (de facto) 표준이 되기 위해 경쟁하는 서로 다른 스펙들이 파편화된 세상에 대해 상당히 익숙합니다. A 다음에 나온 A1은 무엇을 보완하고, 하지만 하위호환성이 없고, 그래서 현실적으로 여러 혼돈이 생기는 등의 문제를 미치지 않고 받아들일 수 있습니다. 하지만 자막 파일의 세계는 특별히 경쟁할 목적 없이 만들어진 포맷들이 파편화되어 있기 때문에, 각 포맷이 무엇을 개선하기 위해 만들어졌는지 쉽게 이해하기 힘들더군요. 심지어 많은 포맷들은 스펙을 찾기도 어려운 상황이었습니다. 대부분의 포맷은 그 포맷이 동작하는 어플리케이션을 위해 만들어진 것이지, 다른 스펙을 가진 포맷과 경쟁하기 위해 만들어진 것이 아니었기 때문에 이런 일이 생긴 것 같습니다.
그래서 이제부터 설명하는 내용은 이 척박한 세계에서 의미있는 정보들을 최대한 수집하려고 한 노력의 결과물이라고 보실 수 있습니다. 시작하기 전만 해도 위키피디아에 있는 내용을 잘 정리하면 되는것 아닐까? 생각했는데, 대부분의 포맷이 위키 페이지도 없었습니다.
SubRip (.srt)
SRT는 위키페이지가 존재하는 몇 안되는 포맷 중 하나입니다. 하지만 SRT 대신 SubRip
이라는 제목으로 기술되어 있습니다. 읽어보면 SRT 파일 포맷은 22년 전인 2000년도에 델파이로 개발된 윈도우용 프리 소프트웨어 SubRip을 위해 만들어진 것이고, SubRip Text의 줄임말로 명명된 것이라고 합니다.
SRT 파일의 내용은 많은 분들이 한번쯤은 보셨을거라 생각 합니다.
SRT 파일은 위와 같이 자막의 순서를 의미하는 숫자 값, 자막의 시작과 종료 시간 (중간의 --> 텍스트), 실제 자막 컨텐츠 텍스트, 다음 자막과 구분하기 위한 빈칸으로 구성 됩니다.
그럼 처음 언급한 자막에 색깔을 입히는 것이 SRT에서 가능할까요? SRT 포맷을 만든 SubRip은 이에 대한 스펙을 아예 정하지 않았기 때문에 이것은 결국 자막을 보여주는 영상 플레이어의 몫이 됩니다. 현재 대부분의 영상 플레이어는 HTML에서 사용하는 스타일링의 위한 태그 중 아주 제한적인 것들만을 SRT에서 지원합니다.
- 굵은 글씨(볼드체)를 위한
<b>...</b>
- 기울인 글씨(이탤릭체)를 위한
<i>...</i>
- 밑줄을 위한
<u>...</u>
- 글자 색깔을 위한
<font color="#code>...</font>
하지만 이는 비공식적인 지원이기 때문에 (문제는 '공식적인 것'이 아예 없습니다!), “자막에 색깔을 입힐 수 있나요?”의 답은 “<font>
태그를 사용한 글자에 원하는 색깔이 잘 보이는지 여러분이 원하는 송출환경(영상 플레이어)에서 테스트해보세요”가 됩니다. 최악의 경우 <font color="..."></font>
같은 태그 자체가 시청자에게 노출될 수 있습니다.
그럼 자막 텍스트가 표시되는 위치는 SRT에서 조정할 수 있을까요? 역시 비공식적으로 ASS라는 태그를 통해 가능하지만 역시 이를 정확히 지원하는 송출환경인지 확인해보아야 합니다. 저는 이 기능을 지원하지 않는 플레이어에서 {\an8}
같은 글자가 들어간 자막을 본 경험이 있습니다.
TTML (.dfxp, .ttml)
SRT를 비롯한 많은 자막 파일은 어플리케이션에서 파일을 구동하기 위해 만들어졌기 때문에 표준과 스펙이 존재하지 않습니다. 그래서 비공식적인 기능이라는 표현들도 약간 어색합니다. 이러한 척박함에서 조금 벗어나 스펙이 있는 자막 파일들을 알아 봅시다.
과거에 DFXP라는 이름이었던 TTML(Timed Text Markup Language) 포맷은 개발자들에게 익숙한 W3C 표준이 존재하는 몇 안되는 자막 포맷이고, 역시 개발자에게 친숙한 XML을 사용하는 포맷입니다.
스타일링과 정렬도 표준에 명시 되어 있어 아래와 같은 자막도 가능합니다.
XML로 된 표준답게 다소 장황한 단점이 있지만, TTML은 대부분의 미디어 플레이어가 지원하는 포맷이고 SRT 정도는 아니지만 미디어 업계에서 널리 사용되는 자막입니다. 일반 텍스트보다 고급적인 기능을 사용하고 싶다면 가장 좋은 대안이 될 수 있습니다.
WebVTT (.vtt)
HTML5에 대한 논의가 한창이던 2010년에는 HTML5의 <video>
태그와 함께 사용될 <track>
태그에서 사용하는 자막에 대한 표준을 정하려는 논의도 있었습니다. W3C는 널리 사용되던 SRT(SubRip)와 XML로 된 표준이 있는 TTML을 검토하였는데, 이 두 포맷을 모두 채택하지 않고 SRT를 기반으로 한 새로운 자막 포맷을 만들었고, 이것이 .vtt
확장자를 가진 WebVTT 포맷입니다. 12년이 지난 지금도 WebVTT 스펙은 초안(Draft) 단계에 있지만, 실제로는 대부분의 브라우저가 WebVTT 포맷을 지원합니다.
SRT를 기반으로 만들었기 때문에 위와 같이 포맷이 친숙하고, 스타일이나 정렬을 표준에서 지원합니다.
인코딩을 UTF8 포맷으로 정의한 몇 안되는 포맷이기도 합니다. 대부분의 자막 포맷은 인코딩에 대한 정의가 없기 때문에 만약 파싱을 한다면 charset detection을 수행해야 하는 경우가 많습니다.
SCC (.scc)
SCC는 Scenarist Closed Caption의 줄임말로 Adobe Premiere나 Final Cut Pro에서 널리 사용되고 있는 포맷입니다. 자막의 세계에 있다보면 Closed Caption이란 단어를 자주 보게 되는데 이것은 영상에 합쳐(burned-in)지지 않은 자막, 즉 우리가 아는 파일 포맷으로 된 자막을 뜻합니다. 영상에 글자가 합쳐지지 않았기 때문에 자막을 표시할지 여부를 선택할 수 있는, 우리가 흔히 생각하는 자막의 정의가 바로 Closed Caption입니다. 반대로 영상에 합쳐진 자막을 Open Caption, Burned-in Caption, Baked on Caption이라고 부르기도 합니다.
이 SCC 포맷은 스타일링이나 일부 정렬 기능을 지원하지만 텍스트 글자를 2바이트 16진수로 표현하며 사용되는 글자셋이 표준에 제한적으로 정의되어 있어 알파벳을 사용하지 않는 대부분의 언어(한글, 한자, 일본어 등)는 사용이 불가능합니다. 또한 프레임 수(29.97)와 한 줄 당 글자수 (37자)에 대한 제한이 있는 자막 포맷이기도 합니다.
Spruce STL (.stl)
Spruce Subtitle File의 줄임말인 STL은 Spruce Technologies사가 DVD Studio Pro 프로그램을 위해 만든 포맷입니다. 널리 사용되지 않지만 곧 설명할 다른 포맷으로 인해 주의를 기울여야 하는 자막 포맷이기도 합니다.
EBU STL (.stl)
European Broadcasting Union (EBU) 에서 만든 이 자막 포맷은 Spruce사가 만든 포맷과 동일한 확장자, STL을 사용하고 있어 STL 포맷을 말하면 Spruce STL인지 EBU STL인지 확인하도록 업계 종사자들을 고통 받게 하는 포맷입니다. 지금까지 설명한 포맷은 모두 플레인 텍스트 형태(SCC는 자막의 텍스트 영역이 16진수로 표현되지만 자막 파일 자체는 플레인 텍스트)이지만 EBU STL은 바이너리 포맷을 사용하는 자막이라서, 아예 일반 텍스트 에디터로는 읽을 수 없습니다.
PAC (.pac)
Screen Subtitling Systems가 개발한 또 다른 바이너리 형식의 자막 파일입니다. 자막의 스타일링이나 정렬을 지원하지만 스펙을 찾기 힘든 자막이기도 합니다.
XIF (.xif)
역시 스펙을 찾기 힘든 자막인데 XML 기반의 자막이라고 합니다.
SAMI (.smi)
HTML과 비슷한 형식을 가진 자막으로 Synchronized Accessible Media Interchange의 약자인 SAMI라고 부르는 자막입니다. 마이크로소프트사가 미디어 플레이어의 접근성을 위해 만든 포맷인데 한국 개발자가 만든 SASAMI 2K 영상 플레이어가 SAMI를 지원하였고, SASAMI 플레이어가 한국에서 높은 인기를 끌다보니 덩달아 한국에서 SMI 포맷이 거의 표준처럼 자리 잡기도 하였습니다.
SAMI, SMI가 SASAMI(Specially Advanced Synchronized Accessible Media Interchange)플레이어와 이니셜이 비슷하다보니 SMI가 사사미 플레이어에서 만든 포맷이라고 생각하는 경우도 많습니다. 공교롭게도 마이크로소프트사는 SMI 포맷에 대한 업데이트나 지원을 제대로 하지 않았고, 윈도우 10에 있는 Movies & TV앱은 SMI 포맷을 아예 지원하지 않습니다.
SMI가 스타일링이나 정렬을 지원하는 포맷이긴 하나, SMI를 지원하지 않는 플레이어들이 상당히 많으니 호환성을 생각한다면 다른 자막 포맷을 사용하는 것이 좋겠습니다.
Outro
지금까지 다양한 자막 포맷들을 살펴보면서 많은 포맷들이 스펙을 찾기 어렵거나 어떤 포맷을 어떤 목적으로 만들었는지 알기 어려웠습니다. WHATWG의 위키를 보면 가장 많이 볼 수 있는 문장이 "이 포맷에 대한 스펙을 찾을 수 없음(Couldn't find a specification for this format)." 입니다. TTML이나 VTT 같은 경우를 제외하면 대부분 특정 어플리케이션을 위해 파일 포맷을 만들어서 표준화하고자 하는 노력이 간과되었기 때문으로 생각하지만 이것 역시 추정에 불과합니다.
XL8의 미디어캣은 XIF와 SMI를 제외하고 위에 언급된 자막 전부를 지원하고 있습니다. 스펙을 찾기 힘든 포맷도 고객으로부터 정보를 받아 구현한 경우도 있지만, 대부분의 고객들은 SRT, TTML, VTT 자막 포맷을 사용하고 있는 것이 현실입니다. SRT의 기능이 빈약해 보인다면 TTML이나 VTT를 사용할 수 있습니다. 하지만 그 외의 포맷을 2022년에 굳이 사용할 이유는 없을 것 같습니다. 레거시를 지원해야하는 이 세상 모든 엔지니어들의 노고를 생각하며 글을 마칩니다.
작성자. 김영후, Senior Software Engineer, 이승연, Backend Engineer