Legendas burn-in vs sidecar: que export, e quando
Devias queimar as legendas no vídeo ou exportar um ficheiro de legendas à parte? Um guia prático para editores de vídeo e criadores de conteúdo — incluindo assets de legendas transparentes, com canal alpha, para o Premiere e o DaVinci.
Assim que as legendas estão sincronizadas e limpas, chegas a uma bifurcação que baralha mais editores do que devia: queimá-las no vídeo, ou mantê-las como ficheiro à parte? Ambas estão certas — para trabalhos diferentes. Escolhe mal e ficas a re-exportar à meia-noite, ou pior, a mandar ao cliente a versão que ele não consegue desligar quando precisava daquela que conseguia.
Vamos tornar a decisão fácil.
Burn-in (queimado nos pixels)
As legendas queimadas (ou “hardcoded”) fazem parte do próprio fotograma do vídeo. Não podem ser desligadas, não podem ser reestilizadas por uma plataforma, e ficam sempre exatamente como as desenhaste.
Usa burn-in quando:
- Estás a publicar em redes sociais — TikTok, Reels, Shorts — onde as legendas têm de aparecer sempre e combinar com o estilo da tua marca.
- Queres controlo total de tipo de letra, tamanho, posição, peso e animação.
- A plataforma não renderiza de forma fiável os ficheiros de legendas carregados (muitas não o fazem, ou renderizam-nos feios).
- Queres um único ficheiro autossuficiente que fica idêntico em todo o lado.
O compromisso: a permanência. As legendas são agora pixels. Uma gralha significa re-render, e não podes oferecer ao espectador um alternador de idioma nem desligá-las para o público ouvinte que preferia não as ter.
Sidecar / asset (uma camada à parte)
Um “sidecar” é um ficheiro de legendas à parte (como um SRT) — ou, melhor para editores, um asset de legendas renderizado com um canal alpha a sério que cai na sua própria faixa no Premiere, no DaVinci Resolve ou no Final Cut.
Usa um sidecar ou asset quando:
- As legendas vão para um editor que as quer na sua própria camada, por cima da imagem.
- Precisas de legendas selecionáveis e acessíveis — YouTube, broadcast, ou conformidade de acessibilidade (muitos contextos exigem legalmente legendas que se possam ligar e desligar).
- Queres reutilizar as mesmas legendas com estilo em vários cortes ou proporções.
- Estás a entregar vários idiomas e queres uma base limpa a partir da qual traduzir.
A jogada profissional: um asset de legendas transparente, com canal alpha, dá aos editores estilo com qualidade de burn-in mais a flexibilidade de uma camada à parte. Podem deslizá-lo, esbatê-lo, ou trocar de versões de idioma sem nunca tocar na tua tipografia. É o melhor dos dois mundos, e é o que separa um “legendador” de um fluxo de legendas.
A tabela de decisão rápida
| Situação | Melhor export |
|---|---|
| Redes sociais, legendas sempre visíveis | Burn-in |
| Entrega a um editor | Asset com canal alpha |
| Acessibilidade / selecionável | Sidecar SRT |
| Várias versões de idioma | Sidecar/asset + re-traduzir |
| Broadcast / conformidade | SRT ou asset (ligável) |
| Um ficheiro autossuficiente | Burn-in |
Um fluxo do mundo real
Digamos que cortas um vídeo de marca que vive em três sítios: um corte vertical de 60 segundos para Reels, uma versão 16:9 para o YouTube, e um master entregue ao editor interno do cliente. A entrega inteligente é: burn-in para o Reel (sempre visível, com estilo, autossuficiente), um SRT para o YouTube (selecionável, acessível, bom para SEO — o YouTube lê o texto das legendas), e um asset transparente para o editor do cliente colocar na sua própria timeline. Três destinos, três formatos corretos, um conjunto de legendas.
Porque isto deve sair de um só projeto
O erro é sincronizar e quebrar as legendas uma vez, e depois reconstruí-las por formato. Todo o propósito de uma ferramenta de legendas a sério é que acertas nas legendas uma vez e as exportas conforme cada destino precisa. O SubSlap faz exatamente isso — burn-in para a publicação, um asset com canal alpha para o editor, um SRT para a plataforma, tudo a partir do mesmo projeto sincronizado, quebrado e traduzido. Sincroniza uma vez. Entrega em todo o lado.