Discuss: Export text from titles and Mogrts as CSV or Text file

Exporting .CSV is a great feature, and with some tweaking it will become invaluable.  I agree that "importing" the .CSV is a critical step.  My biggest challenge is working with many sequences at once.  If I could batch export all project sequences text data to a single .CSV, or perhaps multiple .CSV's, then I could work more effectively.  As somone who works with localization, this would be a game changer for all the editors in my department. 

I have a need to export title text and text box text as VTT for a distribution platform I am working with.  It is to meet accessibility requirements so this feature would be great. Otherwise I have to pretend they are captions and use a caption tool and enter that same text again.

You need to be able to import raw txt files into Premiere, and then have Premiere slice and dice and set the time codes. This is necessary for everyone who works with a teleprompter, where the text that is used is already in digital form. Using the auto-transcription process is very labor intensive since there are so many mistakes that then have to be corrected manually. If the original text file was used, there would be no mistakes at all, and the transcription process would be very quick and easy.

This is a very useful feature but I don't see the option to "import" a CSV file of text once I made changes to it. Being able to batch edit text with a spreadsheet can save tons of time.

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

Annika,

While this is very useful ... getting the "return trip" accepted would be even more useful ... being able to import the text.

Neil