Does Resolve enable the creation of closed captions?
Yes it does. saw in the bm video. It appears to be a lot less cumbersome than adobes' caption
Close caption and subtitles ingo at 11:58 in video
Sorry wrong link. chk.11:59
Fantastic. Thanks Ricardo.
By "embedded" I assume that Blackmagic means closed caption?
On YouTube, when I click "CC" on BM's video, I get closed captions which must have been generated by some automatic program, perhaps by YouTube. They are pretty inaccurate. Does that mean that BM failed to provide a closed-caption video to YouTube? Or does YouTube provide its own automatic CC when you click on its CC button?
you can have a separate srt. file and/or you can have it cooked into the video both are captions
[Bob Cole] "I assume that Blackmagic means closed caption?"
All the way up the road to unintended consequences, I got involved with caption/subtitling several years ago and discovered a world of hurt.
Closed Captions are not subtitles, and Subtitles are not closed captions. Although "people" are not all that aware of the subtle differences.
"Standard" SRT files are SubRipText that, yes, look a lot like captions. But they are not EIA-708 closed captions.
You will also get better results (ie: Vimeo) if you use sidecar files like WebVTT.
The real problem here is that *closed captions* in their broadcast sense are intended for the hearing impaired, and function like described video for the visually impaired. That is, they not only convey the transcribed spoken dialogue, they also describe the aural environment -- [gunshot offscreen] or [Garbled telephone message] when the speech is intended to be unintelligible. Usually, "subtitles" are intended for an audience that is listening to the soundtrack and either sees the text as an assist in comprehension or a completely different language. Subtitles don't describe the sound ambience, offscreen sound, or identify speakers. That is just how it is.
BTW "Stay put. I'll get them." stands a chance of being flagged by DCMP as *non-conforming with suggested practices* and should be represented as "Stay put." "I'll get'em." (with a pause in between). The FCC is getting sticky with this kind of thing. Text shall be synchronized, and convey the manner in which it is spoken. That is a rule.
Yes, there are rules. A lot of them, and FCC started threatening fines for non-compliance a couple of years ago already.
I recently spent two DAYS fixing two short programs that had been "captioned" by the CBC (loose interpretation of the word, since it looked like an automatic, letter-counting algorithm had simply slotted whatever words fit into the box) and good enough. Not good enough. Two other broadcasters had already complained about the poor quality, so yes, it was a fixer job.
Her's the other thing, though... HDMI doesn't (can't) transmit closed captions to a display like we used to do (Line 21), because it just doesn't exist. Your digital cable box has to do it. Also, .scc now appears to be (finally) obsolete. I tried to author a DVD a few months ago -- the client insisted on federal compliance "CC" -- but the roadblock came when the rider-request was for 5 other languages to appear as subtitle streams. That's where the chickens came home to roost. Ultimately, they had to walk it back to "Authored for the Hard-of-Hearing" because they could not meet the
Federal Standard for the Hearing Impaired. The DVD authoring software and players could not distinguish between the .scc and .srt (subtitle-stream) metadata and would always mis-count which asset to access -- so you would get French when you wanted CC... Portuguese when you wanted German... and so on. The fix was to delete the .scc Captions and imbed Stream1 as the English "closed captions" (technically no longer legally qualified as such) and then ripple out the streams. After that it worked, but... you can't put a Prancing Horse logo on a Pontiac Fiero and sell it as a product of Ferrari.
"I always pass on free advice -- its never of any use to me" Oscar Wilde.
Thank you very much for helping with this confusing issue.
Now for the ibuprofren bottle.... I think Joseph is right about this "world of hurt."
I read the newest readme looking specifically for comments on captioning. They mix the terms captioning and subtitles pretty liberally when discussing their workflow. Finally at the end it does say the you can encode captions to cea 608 only into mxf and quicktime formats, but it also specifically says that 708 is not yet available.
It also can't import items like a .scc file. (hopefully that is a yet as well).
Of course with past Blackmagic hardware and software solutions, "yet" could be any amount of time.
If it can ever encode both 608 and 708 from an .scc file, that would be a game changer for me.
[ Joseph Owens]... discovered a world of hurt.
... that's understandable.
Closed Caption = subtitle text instructions embedded in video stream
US CEA-608 only allows one language and is limited in regards of languages (character sets). It's also somehow outdated cause it's thought for analog TV.
US CEA-708 is for the digital age and allows all UTF-8 character sets with multiple languages allowed.
Basic 32 characters per line (theory) less with colored text.
CEA supports NTSC, PAL M.
Teletext allows all UTF-8 character sets with multiple languages allowed.
Basic 42 characters per line (theory) less with colored text.
Teletext supports all.
Additional things like audio descriptions, reading speed, text formatting, subtitle length and other timing things do apply.
Differs by country and station.
A "technical correct" preview for the current implemented CEA-608 version can't be done yet with BMD hardware yet.
Another option for CC are side car files which are embedded in the "package" and might be a kind of "preliminary package", allowed Types are SCC, EBU-STL (EBU 37/Teletext), EBU-TTML.
Same broadcast rules as above apply.
With Apple's current version of MXF you can't embed CC into the video stream. This version allows AV content only and no meta data like CCs.
Other types like used by YouTube, Netflix, Vimeo etc use side car files by default - not a package. iTunes use a special package though.
For each of those services rules apply - similar to those above. Netflix probably has the most strict rules.
Finally there are Open Captions (burned in) - seems there are no real rules except "Title Safe" and even there a lot of people say: this doesn't apply in the digital age.
So it's kind of Wild West for low quality subtitles. BBC recommends a Title Safe Area of around 60% and I highly recommend.
"He who fights with monsters should be careful lest he thereby
become a monster. And if thou gaze long into an abyss, the abyss will
also gaze into thee." - Friedrich Nietzsche, Beyond Good and Evil
608 works, but the limitation seems to be that it only outputs a single subtitle track, so subtitles in one language only - specifically whichever is turned on on the edit page. So I can output separate files for English or French subtitles and that works ok, but hopefully they will adopt the 708 quickly.
If you choose to output as SRT, then you get to select more than one track, and it will output a separate file for each language. I only tested that locally with VLC Media Player, and you have to manually import the SBT files after loading the video. Kind of clunky.