Caps Cleaner Devlog 001 - Intro

 Caps Cleaner DEVLOG 001

By A.A. Lopez

    So I haven't really expounded on what Caps Cleaner is and why I am working on it. Let's step back and look at what I do for a paycheck: I do quality control, specifically in the field of media. Whenever people ask me to clarify it feels difficult to explain, not because it's a difficult gig, nor is it hard to parse, but because there is so much that goes into it. Usually my go to explanation is, "I watch TV for a living," because that is a major part of it, but the breakdown is a bit more.

    What I'm actually doing is reviewing content and assets delivered by several partners and labs that go through their media and package to our company's spec and ensuring that these are 1:1 and if not flag, fix, or reject them. So what do these rejections look like? Well they are:

• Poor video quality, which could range from 5 or more seconds of an empty black screen to damage that is similar to magnetic damage found on old VHS. And sometimes that will be best as-is.
• Poor audio quality. Ranging from the sync does not match the video to being the completely wrong audio.
• The metadata, like the title, description, release date, all the small things that are found when you read the blurbs when you pause or look into the episodes and more section. These might be small flubs like an e in than instead of a, or could be that they gave Jack Frost the kids movie and Jack Frost the horror movie got switched.
• And the biggest thing: Captions.

    These are the things that are in the craw of my whole team. Because they tend to be so innocuous and easy to point out, but it's due to that they are the most difficult little buggers. And the rules that the FCC has that are there for accessibility reasons, which are a good thing, I really want to stress that, but can make looking through all of these difficult. Here's a small list of the issues we will run into and need to fix:

• Short/Long Duration - Captions are outside of the safe limit of 1-7 seconds
• Italics - Due to how certain characters can look Italics can be offsetting or difficult to read
• 4+ lines - Captions can only be a maximum of 3 lines
• 32 Characters per line - A line can only have 32 characters, including spaces
• Stacking - When two timecodes share the same timecode and overlap on screen
• All Caps - Like italics can be offsetting and difficult to read
• Sync - 2+ second early/delays can make it difficult to follow the plot
• Missing Speaker IDs - Makes it difficult to know who is talking off screen
• Missing Speaker Dashes - Makes it difficult to know if the people are having a back and forth or if one person is talking
• Covering On Screen Text - Makes it difficult to read graphics on the screen from names of interviewees, to seeing scores of games, and other information presented

    Some of these are things a majority might roll their eyes at saying, "But it's easy to tell what/who said whatever," the thing is we're working off the idea that you can't hear them. And let me tell you trying to find these little buggers in a 30 minute TV show is harder than you think.

    Now is that to say we're out of our depth here? No. We have several tools and whatnot to help out. But some of these are difficult to fix, one of which is the oldest one that I've dealt with: AllCaps.

    There are several services online that can change AllCaps to mixed case, but the issue there is that what they do is just make the first letter uppercase and the following lowercase, and that's not how it should go, like in the following example:

Example (AllCaps): "QUICKLY JUMP OVER THE LAZY BROWN FOX, TED!"
Example (MixedCase Service fix): "Quickly jump over the lazy brown fox, ted!"

    Ted should be capitalized in that sentence, yet it isn't. So my goal with this custom script is to load a caption file, have it read it through and update the case structure by looking at text blocks, proper noun usage, and be able to change an AllCaps file to MixedCase. So far I've developed a bit of the code, and implemented some of the logic, as well as including some logic from coworkers who are interested in seeing this tool come to fruition. Next devlog will focus on the breakdown of the code and the flowchart I'm using to map this out.