Note: the new export options are available as of Beta 22.6 Build 13.
Annika,
This is a good addition. The csv is VERY useful. For example, users asked for timecode in the .txt export from captions and transcript. When it was added, all the users who did NOT want timecode had a problem. But it was easy to get the text only from the csv. Users have diverse workflows, and at least two exports are desireable: one that is ready to use for a novice (.txt) and one that is very flexible for users with the skills to reformat and output as they need (.csv).
As Neil suggests, the roadmap forward needs to include more. And the types and details of exports can help or hinder use of the main caption workflow.
Captioning/subtiling, closed or otherwise, is complicated, comes in an extraordinary variety of formats, and will probably always require users to have third party tools. PR should have very flexible import and export options that recognize this. For example, my belief at this moment is that the .srt sidecar export, even with "styling" selected will only include font color. (I last tested for 4 style elements: Font color, Font family, Caption Position, and Background - yes/no and color.) That was not so bad when you could export .stl from a Subtitle stream, but that was removed. Really? Tell me I'm missing something. Closed caption exports carry more style, but they are, of course, severely limited on styles.
Caption Blocks are complicated, and I think need attention going forward. How they are set up in exports is important.
With no blocks, the current and revised Caption .csv are the same, except for the renaming of the "transcription" column to "text" (which I agree is logical).
With blocks, in the current method, for srt and txt, the block texts are simple multiple lines in a single segment. For those formats, we have no way of knowing whether these are blocks or just multiline captions. For .csv, a vertical line character (space, vertical line, space) is used to separate one block from another within the same segment.
In the new method, each block is a separate line in the .csv, and the only indication that there are blocks is that the timecode repeats. Note that in the old and new exports, for .csv, unlike .srt and .txt, caption number is omitted. As long as there is only one segment (i.e. one occurence of that timecode), it is not a big problem to generate the number. But when there are blocks and the timecode now repeats, it becomes a problem. In the new Graphics Text exports, there are assignments that identify them (Video Track and Layer ID). Something like that is needed for caption blocks.
This points to the "big picture" problem with blocks; I think they are only partially implemented. And they are still undocumented in the user guide. A major use of blocks would be to differentiate speakers, which cries out for: 1) having an OPTION to use speaker information from the transcript in the captions, 2) identifying different sub-streams of blocks per speaker and providing methods for working with the streams, and 3) including as one of those methods different Caption Styles per speaker. Currently, 1) speaker designation is limited to the transcript, 2) you must edit blocks one by one, and 3) if a style is applied AFTER changing style in individual or multiple blocks, it will override any differences.
A frequent topic of conversation on the release forum is how to convert captions to graphic text and, less often, vice versa. Because the captions/transcript are coded in hashed hex, a third party is unlikely to create a tool to do this. Third parties do provide options once the text is accessible. For example, you can convert .srt to .xml that will import to PR as graphics text, such as Subtitle2xml by Bas Tempelman:
https://www.microsoft.com/en-us/p/subtitle2xml/9n78158bn7xm?activetab=pivot:overviewtab
PR should have an option for converting captions to graphic text and, while potentially more complicated, graphics text to captions.
The other big picture issue is users who want to export the captions, edit outside PR (because the editors are not PR users and PR is not an efficient text editing program), and then reimport the edited transcript of captions without losing or breaking timecode. Some users want to do that with transcripts. Either process is complicated by timecode issues. As you say, "This can be handy for quality control of text in a sequence or for handoff to translation." But those purposes are very limited if you cannot reimport with changes.
Stan
17
Replies
AdChoices