Program Database Requirements

Media Automation Help

Logout (Guest) Media Automation Menu Main Menu

Description revised: 2018-01-16 17:13

Contents Video Program Naming Conventions Naming Examples and Details Broadcast Schedule Workflow Broadcast Media Workflow Segment File Processing Workflow Database Fields

This web page provides help information for the Program Database Requirements, the Media Automation Workflow, and especially the Media Automation web pages. Media Automation Workflow encompasses the processing and tracking of all broadcast media files after they are released to broadcasting and related media files such as proxies, Closed Caption files, and Closed Caption transcript files. The Media Automation system manages playlists, creates proxies, embeds CC, embeds AFD, converts MPG files to MXF, and updates the Programs by Request website. The Media Automation Workflow is making ongoing changes to adapt to the new Omneon/Harmonic/Crispin broadcast/production system. Changes are also in process for DIVA, ProTrack, and the new Media Automation server.

Video Program Naming Conventions Everything that is broadcast is tracked by a name. Anything that is broadcast comes from a computer file which has a predefined naming convention which must be followed. Any file submitted to Master Control will be automatically forced to the proper naming. Failure to know this pattern, which has been published for years, creates confusion. Broadcasting automation software requires a clear definition of standard file names. These file names are based on the video program codes used in the Program DataBase (PDB). A video program code consists of two parts, the series code and the episode number. A series code has three parts. An optional leading language prefix indicated by an underline (example "RU_"). Optional leading digits, which are typically a year number. Letters which are usually an acronym (initials) for the series name. A series code can never end with numbers. All episode numbers are a 6 digit number, which is usually a sequence or a date code but it can be a broken sequence or completely arbitrary. In the input to some computer programs (software) the leading zeros can be left out when specifying the episode number. They will be automatically added by the software. Leading zeros can not be left out in the actual program file name and will be automatically inserted at the Dropbox. The ideal date code is of the form YYMMDD because it allows a natural sort order for simplicity of viewing in a directory list. This form is not required, just helpful. Multiple media files may contain segments for the same program. The program code is modified slightly with a trailing episode letter (A-G), which is used as the name to track these segments. These program segment names follow the standard format. The episode numbers in some older file names were shortened to five digits only when there is a segment letter. This is no longer allowed but has been done in the past. Segment letters are always included even for a single segmnet program in all newer programs but has been left out in the past. Crispin refers to the file name without the .MXF extension as a Material ID for tracking purposes.

Naming Examples and Details Consider the following example of a program which contains two segments: TDY11073A and TDY11073B The standard code for the entire episode always contains six digits and is listed in the PDB as TDY011073. The standard format of a program segment name in Automation software consists of a program code which always contains a six digit episode number and a segment code. For example: TDY011073A. The standard file name is always the same and contains six digits except in some older programs such as this example. It is important to be clear about the name for the different program segment pieces. Program code: TDY011073 (Maximum 22 characters) Series code: TDY (Maximum 16 characters) Episode number: 011073 or 11073 (Always 6 digits) Program segment: TDY11073A (Maximum 23 characters) Segment code: 011073A (Maximum 7 characters) Segment Letter: A, B, ... (Maximum 1 character A-G) In the file name there are some older programs with only five digits when there is a segment code. When there is a single segment episode the segment letter was optional in older file names. It is desirable, but not required, for the program segment names of a series to be consistent in the use of a segment code and the number of digits. Overlapping or duplicate program segment names will be flagged and forbidden where possible. There are only three possible file names, which are acceptable in this example for the first segment: TDY011073 (Only older programs) TDY11073A (Only older programs) TDY011073A There are only two possible file names, which are acceptable in this example for each additional segment letter: TDY11073B (Only older programs) TDY011073B These file names are also known as the Crispin Material ID.

The letters A-G are reserved for valid program segments. If you are doing anything temporary or testing do not use these letters in a series folder. All other letters are available for testing or temporary purposes. Testing or temporary files can also use extra letters after the segment letter. Example: EE000001F - A-G Reserved for valid program segments ready for broadcasting and immediate Media Automation processing. EE000001T - H-Z Available for testing and temporary purposes. It is recommended to use more than one letter to mark non-broadcast files.

Broadcast Schedule Workflow ScheduleMaker has been replaced by ProTrack! The Broadcast Schedule Workflow is defined in detail as part of the ScheduleMaker documentation. In summary, the skeleton schedule(playlist) of the primary programs is defined in the PDB and exported to the ScheduleMaker program. The filler program segments are added and the schedule is released to Master Control for playout.

Broadcast Media Workflow Broadcast files come to Master Control from the Control Rooms, Editing, FTP, and other sources. When broadcast files are ready and released for broadcasting, the Master Control Operator (MCO) places them in the Omneon Dropbox. At this point the Media Automation system takes over the processing and tracking of the files until they are on the MediaGrid storage system ready for broadcast. The files are QC checked to verify proper naming and file formats. You may view a Media Automation Work-flow diagram. You may also view a Media Automation diagram that emphasizes CC processing. All broadcast-ready files for final submit by the MCO to the Omneon Dropbox and Media Automation must be either SD-MPG/MXF (720x480) or HD-MXF (1920x1080). Some ministries provide SD-MPG (720x512) files with Line 21 CC already included. Any file may contain A/53 ATSC DTV CC for broadcast. All video/audio processing of MXF files must be completed before the file is submitted to the Omneon Dropbox. MPG files will receive video/audio processing during transcode to MXF All MXF files may contain AFD (Active Format Description) as needed. AFD tracks whether the SD-MPG conversion is the older 4x3 (720x480) or the newer 4x2 (720x360 centered in 720x480 known as letter-box). AFD also applies to HD-MXF that contains content that is 4x3 and already pillar-box (blank area left and right). You may view a diagram that illustrates different AFD Results. If an MXF 4x3 is not marked with AFD, it will be cropped top and bottom because broadcast is in HD and assumes HD then the satellite broadcast is resized to SD. HD-MXF (16x9) and SD-MXF (4x2) content appears letter-box in SD (blank area top and bottom). If an HD/SD-MXF containing 4x3 content is not marked with AFD, it will be cropped in HD and postage-stamp (blank area all around) in SD. The MediaGrid storage system is for use with the Omneon/Harmonic/Crispin HD broadcast/production system. The VTrak storage system is used to store supporting broadcast files such as the MXF backup files, streaming proxy WMV files, and closed caption (CC) SUB/BOT/SCC/HTML files. The information and use of all these files ties into the Program DataBase (PDB). The proxy files of regular series programs are also replicated to the Programs By Request (PBR) website. CC files are also converted to a transcript (HTML) format and copied to the PBR website. The VTrak storage system is accessed through the VideoSrv computer. The VideoSrv\Video share is usually mapped as the Y:\ folder. All VTrak segment files for a series are always stored together in a subdirectory with the name of the series. The MXF backup files series directories are stored in the ten various mount folders such as Y:\MXF7\MXFBackup. All WMV file series directories are stored under the Y:\Proxy directory. All CC (SUB/BOT/SCC/HTML) file series directories are stored under the Y:\CC_Archive directory. These folders are completely under the control of Media Automation. Valid program segments are tracked and processed automatically by Media Automation. All others are ignored. This does not apply to non-active series folders which are also ignored by Media Automation. Only specifically authorized Master Control personnel should ever make any changes in any MediaGrid or VideoSrv folder. The administrator password to VideoSrv should never be given to anyone. This is ony for VideoSrv console access. The "Write" user and password to VideoSrv, which allows write access, should not be given to anyone unless approved by Moses, Tim Lass, or Frank Clark. There is a read-only user and password access. All requests for access to files must be submitted to Tim Lass. MXF files can only be accessed from the backup copies on the VTrak. Access is through a link in the Y:\@MXF directory. You cannot access the MXF file as long as the old MPG file continues to exist on the VTrak. Anyone can monitor the activities of Media Automation using the Program Database. The Program Database is usually accessed through http://mail.3abn.org using Internet Explorer. Most people will use the default Guest login. There is a "Media Automation" entry on the Main Menu. There is a "Media Automation Help" entry, which points to this file that contains answers to almost every question you may have about the PDB and Media Automation.

Segment File Processing Workflow The following Media Automation computer programs perform processing steps that occur automatically in approximately this order. Any time estimates are assuming an hour program. Some processes can be significantly faster or slower for shorter or longer programs. Each step is identified by the program that performs the processing for that step. Example process steps and times for an hour MPG file placed in the Dropbox: DropboxStart 2015-07-08 19:06:56.0 DropboxFinish 2015-07-08 19:12:38.0 MXFTranscodeStart 2015-07-08 19:11:51.0 MXFAvailable 2015-07-08 19:50:11.0 ProxyStart 2015-07-08 19:42:58.0 ProxyFinish 2015-07-08 20:23:03.0 PBRProxy 2015-07-08 20:23:50.0 Example process steps and times for an MXF file placed in the Dropbox: DropboxStart 2015-08-04 09:19:20.0 DropboxFinish 2015-08-04 09:21:56.0 MXF2Crispin 2015-08-04 09:23:35.0 MXFAvailable 2015-08-04 09:34:40.0 ProxyStart 2015-08-04 09:22:00.0 ProxyFinish 2015-08-04 10:55:33.0 PBRProxy 2015-08-04 10:56:38.0 MXFCheckout AFDStart 2015-08-04 09:22:49.0 AFDFinish 2015-08-04 09:22:49.0 Example process steps and times for an hour MXF file when CC is available: CCModification 2015-07-14 08:48:20.0 MXFCCStart 2015-07-14 08:49:15.0 MXFCCFinish 2015-07-14 08:51:11.0 MXFAvailable 2015-07-14 09:01:07.0 ProxyCCStart 2015-07-14 09:02:55.0 ProxyCCFinish 2015-07-14 09:03:17.0 PBRCC 2015-07-14 09:04:18.0 Example process steps and times for a half hour MXF file when AFD is changed: AFD MPG-4-2 AFDStart 2015-07-07 07:28:19.0 AFDFinish 2015-07-07 07:31:31.0 MXFAvailable 2015-07-07 07:51:34.0 DropBox New or modified MXF or MPG files are submitted from ingest or file transfer by the Master Control Operator (MCO) to the (10.20.61.101) "\\Omneon-2\Dropbox" folder. Only the MCO should access the Dropbox. The Dropbox is going to be moved to the new Media Automation server. These are the types of files expected in the Dropbox. Any other types of files will be rejected. Any optional SCC file must be placed in the Dropbox before its companion MXF/MPG file. There is no provision for adding SCC to an existing MXF file. HD-MXF 1920x1080 (optional embedded CC) SD-MXF 720x480 (optional embedded CC) HD-MPG 1920x1080 (optional embedded CC) SD-MPG 720x480 (optional embedded CC) SD-MPG 720x512 (optional Line 21 CC) MPG files will be transcoded as MXF and resubmitted to the Dropbox as SD-MXF or HD-MXF files after MCO review. MXF files from outside ministries will also receive a final transcode. The DropBox program running in the "Dropbox\Program" folder performs the following functions for each file detected (once a minute) in the Dropbox folder. The DropBox program attempts to rename the file to the Dropbox\Stage folder until the file is finished copying and not busy. If the file does not pass tests for name integrity, send an email to MCO. Otherwise, set the DropboxStart date field. Status is Dropbox Processing. When the rename is successful, test the file for contents integrity. If the test fails, send an email to MCO. Move the file to the Dropbox\Error folder. Fill in the DropboxStart date field with a date of 9999-12-31 23:59:59. The details of the error are in the Dropbox\Program log. Example file name: Dropbox\Program\DropBox-2013-12-02.log Any file (HD/SD-MPG/MXF) with separate SCC file is copied to the "wfs\MXF2CC" transcode folder. The SCC file must be copied to the Dropbox before the file of the same name to be recognized properly! The "wfs\MXF2CC" transcode folder expects and forces HD-MXF. It has not been tested to determine what will happen with SD files. These files will go to a QC folder for review by the MCO before being submitted back to the Dropbox. Copy the MXF files to the "wfs\MXF2Proxy" folder. Since it may take about an hour to make a proxy, this step will be skipped if there is a backlog. Move the MXF files to the MXF2AFD folder for optional AFD embed. Copy the MPG files to the "wfs\MPG2MXF" folder for MXF Transcode. These files will go to a QC folder for review by the MCO before being submitted back to the Dropbox. Fill in the DropboxFinish date field. Status is Available Pending until the MXF file reaches MediaGrid (10 - 20 minutes) and the MXFAvailable field is filled in. Status is Proxy Pending. MXF2AFD The MXF2AFD program running on the Omneon server inserts the AFD flag when needed. Because our broadcasting environment mixes SD and HD programming, an AFD flag is needed to keep the top and bottom of a full-screen 4x3 video from being cut off. You may view a diagram that illustrates different AFD Results. The MXF2AFD program checks files from DropBox to determine whether they need an AFD flag inserted. Normally the MCO sets the flag in the PDB before it gets to the "MXF2AFD" folder. However the flag can be changed later. When the AFDStart field is null the appropriate flag is inserted. The file is removed from the MediaGrid while it is being changed and placed in the MXF2CC folder when finished. MXF2CC The MXF2CC program checks files from the MXF2AFD program to determine whether they need CC inserted. Often, the CC is created later. MXF files are automatically embedded with the CC as needed by the MXF2CC program running on the Omneon-2 server. Move the completed MXF files to the C:\MXF2Crispin folder. Fill in the MXF2CCStart date field and the MXF2CCFinish date field. Status is MXF2CC Processing then later Proxy2CC Pending. MXF2Crispin The MXF2Crispin program runs on the Omneon-2 server in the "C:\MXF2Crispin\Program" folder. Its primary task is to copy the MXF file to the MediaServer for Crispin import. MXF2Crispin will then make a backup copy of the MXF file to the VTrak. Crispin is not designed to allow a file to be easily replaced. MXF2Crisping has to go through a complicated process to force replacement including a ten minute wait. MXF2Crispin will also move the file to the "C:\MXF2BOT" folder to examine for possible embedded CC. MXF2BOT The MXF2BOT program running on the Omneon server extracts CC provided by outside ministries. If the CCSource is Unknown and CCAssigned date is blank, then the program copies the file to the \\Omneon-2\MXF2BOT\Extract folder for possible CC extraction in the SCC file format. CCSource is set to Outside_Provided assuming success. CCAssigned is initially assigned to the current date. When extract is finished but there is no SCC, CCSource is set to Series CCType. The CCAssigned date field is set to blank. If SCC is found it is saved in the CC_Archive and converted to SRT then BOT/HTML and also saved in the CC_Archive. CCCreate is set to the CCAssigned date and the CCAssigned date field is set to 9999-12-31 23:59:59. The CCModified date is set to the current time when finished. MXF2Proxy WMV files are automatically transcoded from the MXF files and stored in the appropriate directories on the VTrak by the MXF2Proxy program running on the Omneon-2 server. This process will begin within about 1 minute and take up to an hour. A skeleton CC SUB file is created, if needed. Status is Proxy Processing then FTP Pending unless there is already CC then it skips to MXF2CC Pending. FTP2PBR Copies of the WMV files are automatically transferred by FTP to the PBR website using the FTP2PBR program running on the new Media Automation server. This process will begin within about 1 minute and take about 1 minute. Status is CC Pending unless CC already exists then status is MXF2CC Pending. MPG2MXF The MPG2MXF program running on the Omneon-2 server creates MXF files from the MPG files. The MXFTranscodeStart field is set to the current time when the file is received. There are three types of MPG files expected in the MPG2MXF folder: HD-MPG 1920x1080 (optional embedded CC) copied to the "wfs\MCRIN" folder. SD-MPG 720x480 or any file with embedded CC is copied to the "wfs\MPG2MXF708in" watch folder. SD-MPG 720x512 (optional Line 21 CC) copied to the "wfs\MPG2MXF608in" watch folder. These files will go to a QC folder for review by the MCO before being submitted back to the Dropbox. ScheduleCC Programs needing CC are identified by the ScheduleCC program running on the workstation of the CC coordinator who records who is assigned to work on the CC. Status is CC Processing. Typical turnaround for CC is 1 - 2 weeks. MoveCC SUB files are entered when received or reviewed and stored as BOT files in the appropriate directories by the MoveCC program running on the workstation of the CC coordinator. Status is MXF2CC Pending. Proxy2CC WMV files are automatically embedded with the CC by the Proxy2CC program running on the new Media Automation server. HTML transcripts are also created for PBR upload. This process will begin within about 1 minute and take about 1 minute. Status is Proxy2CC Processing then FTPCC Pending. Copies of WMV files with embedded CC are automatically transferred by FTP to the PBR website running using the FTP2PBR program on the new Media Automation server. CC HTML transcripts are uploaded immediately afterward. This process will begin within about 1 minute and take about a minute. Status is UpToDate. PBR Schedules are automatically created and transferred nightly by FTP to the PBR website using the PBR program running on the new Media Automation server. A series index is also automatically created and uploaded. MediaCheck The MediaCheck program runs nightly on the Omneon-2 server. It updates the scheduled fields for CC purposes, checks for misnamed files, and other errors.

Database Fields This is the description of the various fields which are displayed.

Language / Status Field The Language / Status field of the Series table in the Program DataBase (PDB) contains the following values: Unknown English Television Latino Television English Radio Latino Radio English Television (inactive) Latino Television (inactive) English Radio (inactive) Latino Radio (inactive) When a Series is originally created the Language and status will be Unknown. The field will be updated by Programming as needed. Radio and inactive programs are ignored by Media Automation. English and Latino are processed separately in the PBR website.

CCType Field The CCType field of the Series table in the Program DataBase (PDB) contains an indicator for who is responsible for the CC. This field will be updated by the CC coordinator as needed. Unknown When a Series is originally created by Programming the CCType will be Unknown. The field needs to be updated by Frank or Cindy. It may refer to a program which does not get CC. Outside_Responsible An outside ministry is responsible for the program and the CC. It does not appear the CC has been embedded or provided. Outside_Provided An outside ministry is responsible for the program and the CC. We believe the CC is embedded in the user data or on Line 21 in the program file. TABN_Responsible 3ABN is responsible for the CC. Many of these programs are from outside ministries but were provided before 2010-06-01. This was the cutoff date after ministries were notified they must provide CC. 3ABN is required to provide the CC even when the outside ministry does not to comply with FCC requirements. Filler A filler/promo is not copied to the PBR website. 3ABN may choose to provide CC for this program. These programs are always recorded as series but each program is not normally recorded by description.

Program Status Detail The following fields are found in the Program Status Detail of the Program Database and other status screens. There is a record for every broadcast program segment or filler keyed by series and segment name. Any time estimates are assuming an hour program. Some processes can be faster or slower for shorter or longer programs.

Program Segment The Program Segment code is not a database field but is often shown in status displays. The Program Segment code is the combination of the Series field and the Segment field.

Series Field The series code, which is limited to 16 characters. A series code has optional leading digits, which are typically a year number and letters which are usually an acronym (initials) for the series name. The series code also has an optional language prefix such as RU_, RUP_, and FR_.

Segment Field The name of a segment consists of an episode number which is a 6 digit number, which may be a sequence or a date code and a segment letter A-G. In Media Automation tracking the episode number is always 6 digits and there is always a segment letter. The actual file name in older files may leave out the segment letter. When there is a segment letter in older files the episode number might be 5 digits. Some website pages display the series field as a prefix to the segment.

MaterialID Field The MaterialID is the Crispin reference for a segment. It is the actual name of the file without the file extension. The name in older files may not have a segment letter. The name in older files may have 5 digits in the segment with a segment letter. The MaterialID for newer files is forced to match the Program Segment.

Duration Field The duration of the segment as described in the MediaGrid Archive. The format of durations is always H:MM:SS. The value is rounded up to the next second, if there are more than two frames into the second. Otherwise, it is rounded down. Unlike other TV Broadcasters 3ABN prefers to have a short fade to black between every clip. This provides a calm transition rather than the abrupt transitions used by others. Tracking to the second is close enough for our purposes. Ideally every segment is created 2 frames short of a second to allow for drop frame timing.

AFD Field The AFD (Active Format Description) type indicates the display format of the MXF File. This is needed so 4x3 SD video will broadcast properly in 16x9 HD. These are the values: Unknown Undetermined: MXF format assumed to be 4x2/16x9 and broadcast with cropped top and bottom. SD 4x3 Verified: Older 4x3 (SD full-screen, HD pillar-box) format used until about 2010. This is AFD 9. SD 4x2 Verified: Newer 4x2 (SD letter-box, pseudo-HD full-screen) format used after about 2010 and broadcast with cropped top and bottom. This is AFD 0. HD 16x9 Verified: 16x9 HD format. This is AFD 0. HD 4x3 Verified: 16x9 HD format with pillar-box content. This is AFD 9. You may view a diagram that illustrates different AFD Results. There are about 15,000 older files in SD 4x3 format. Older files that don't get marked will be cropped top and bottom when broadcast with the new system. There was an automated method for identifying and marking the files but a file can be changed or corrected manually. Note that SD 4x2/HD 16x9 is not necessarily an AFD insert but can simply be a mark that it has been verified. This is recognized by an AFDStart and AFDStop that are equal. SD 4x2 is the default assumption for unknown files.

Updated Field The Updated field contains the last date that the record was modified for tracking purposes.

Status Field These are the possible status names which may be assigned to a segment based on the current processing status. The MA_Segments table Status Field contains a numeric index to a key for these status values in the MA_Status table which contains the identifier string or name for the status. Unknown A status has not yet been determined for this segment. Waiting Ingest This segment has been scheduled but there is not yet an MXF or MPG file available. There is a Scheduled date but no DropboxStart date. Dropbox Processing There is an MXF or MPG file entering the Dropbox to be processed. This will usually complete in about five minutes. There is a DropboxStart date. The MXF or MPG file is copying to the VTrak or MediaGrid. This will usually take about five minutes. If there was an error in the contents of the MXF or MPG file entering the Dropbox to be processed, there is a DropboxStart date of 9999-12-31 23:59:59. Available Pending There is an MXF file waiting to be placed on the MediaGrid. This will usually take about ten minutes. There is an MXFAvailable date when finished. Proxy Pending There is an MXF file available waiting to have a Proxy made. This will usually begin in a minute. There is an MXFAvailable date but no ProxyStart date. Proxy Processing The Proxy has been scheduled to be made. This should complete within an hour or so. FTP Pending The proxy is waiting to be uploaded to the PBR. This will usually begin in a minute and take about a minute. When there is already a CC file this step will be skipped. This status is skipped for CCType "Filler". CC Pending Waiting for this segment to be assigned for CC. CC Processing The segment has been assigned for CC and is in process. This will take a week or so. When the CC file is returned it may be reviewed or simply put in place and the next status will be MXF2CC Pending. CC Review The MXF has been modified and the CC needs to be reviewed for possible correction. Because of the large backlog and limited resources, segments are not being reviewed and immediately promoted to MXF2CC Pending. MXF2CC Pending The CC is available and is waiting to be embedded in the MXF file. This will usually begin in about a minute. MXF2CC Processing The MXF has been scheduled to have the CC embedded. This will usually take an hour or so. Proxy2CC Pending The CC is available and is waiting to be embedded in the Proxy file. This will usually begin in about a minute. Proxy2CC Processing The Proxy has been scheduled to have the CC embedded. This will usually take about a minute. FTP ProxyCC Pending The embedded Proxy and CC transcript is waiting to be uploaded to the Programs by Request (PBR) website. This will usually begin in about a minute and take a minute. This status is skipped for CCType "Filler". UpToDate All Media Automation processing has been completed.

Scheduled Field The "Scheduled" date is the most recent or future time a segment is/was scheduled to play for the purpose of prioritizing CC embedding. Only the main 3ABN schedule and Latino is indicated for recent and future dates in the primary Scheduled field.

Scheduled2 Field The "Scheduled2" date is like the Scheduled date except it is for identifying the secondary priority of CC for Proclaim and D2D.

DropboxStart Field The date when the MXF or MPG file began copying to the Dropbox. DropboxFinish Field The date when the MXF or MPG file is moved out of the Dropbox. MXFTranscodeStart Field The date when the MXF creation from MPG started transcoding. This field is blank when the MXF file is submitted to the Dropbox. If the transcode was not attempted for an MPG file with double audio, this field will be 9999-12-31 23:59:59. MXF2Crispin Field The date when the MXF began the process of being imported in Crispin for playback. This proces will take about ten minutes. MXFAvailable Field The date when the MXF finished the import in Crispin and was found in the MediaGrid Archive and deleted from the CRISPIN_DROP_MC1/2 folder. ProxyStart Field The date the Proxy creation from MXF started. This field may contain 9999-12-31 23:59:59 when the MXF has been flagged as creating a proxy error or for series such as "RU_" which do not get a proxy at this time. ProxyFinish Field The date the Proxy creation from MXF finished. PBRProxy Field The date the Proxy without CC was uploaded to the Programs by Request (PBR) website. This date may not mean anything if there is already CC for this segment. MXFCheckout Field The date a file was reserved for additional processing such as AFD and CC. AFDStart Field The AFDStart indicates the date the AFD began embedding in the MXF file. When changing the AFD this field must be cleared to indicate that a new embed is needed. AFDFinish Field The AFDFinish indicates the date the AFD was finished embedding in the MXF file. When this field matches the AFDStart it means that the status was only recorded and not changed. CCSource Field The first five are preserved specifically for the Series table to identify the primary responsibility. The rest identify the name of the person assigned to create the CC or who did create the CC. Unknown Series has not been assigned a primary responsibility File has not been tested for CC. DropBox and MediaCheck test for user data and MXF2BOT tests for Line 21. When it has been tested, it will be filled in with the series CCType, TABN Responsible or Outside Responsible instead of Outside Provided, if no CC is found. Outside Provided, if CC is found. Outside Responsible Outside Provided indicates pre-embedded CC. Outside_Provided is automatically added for MXF files found to contain CC without a CCCreate date (such as the TT series) and is also manually added for Line 21 embedded (such as early CR) to avoid accidently creating CC when the series is marked "TABN Responsible". TABN Responsible Filler Infoesearch is our primary CC supplier. CCAssigned Field The date the person was assigned to create the CC. This field will contain 9999-12-31 23:59:59, if Media Automation detects that we received the MXF or MPG file with User Data embedded CC or with Line 21. This field will also contain 9999-12-31 23:59:59 to manually identify Line 21 embedded such as in CR so it doesn't trigger making CC. We accidentally overwrote some of the CC. We fixed it by embedding a single space. CCCreate Field The date the original CC was received. This field will contain 9999-12-31 23:59:59 while it is waiting for embedded CC to be extracted from the MXF file by MXF2BOT. Then it will contain the date extraction began. CCModification Field The date of the last time the CC was modified. This field will contain 9999-12-31 23:59:59 while it is waiting for embedded CC to be extracted from the MXF file by MXF2BOT. Then it will contain the date extraction finished. MXFCCStart Field The date the MXF embedding of CC started. This date may match CCModification when we received the file with CC. The field may be blank if the CCAssigned contains 9999-12-31 23:59:59 MXFCCFinish Field The date the MXF embedding of CC finished. This date may match CCModification when we received the file with CC. The field may be blank if the CCAssigned contains 9999-12-31 23:59:59 CCLegal Field The date MXF2CC (or the CCLegal program) verified the CC Text embed fields were clean of any excess embed data. The CCLegal program will correct this problem. ProxyCCStart Field The date the Proxy embedding of CC started. This field will contain 9999-12-31 23:59:59 to prohibit a new proxy being uploaded in the case of CC we made later removed (CR). The HTML was also preserved. ProxyCCFinish Field The date the Proxy embedding of CC finished. PBRCC Field The date of last upload of proxy embedded with CC and the CC transcript to the Programs by Request (PBR) website. Logout (Guest) Media Automation Menu Main Menu