Media Check comparison to other offered log check products.

October 2006

Functionality

Power-Link's Media-Check

DCS-Maestro
Log-Merge

Scott Studios
 Merge 32

Audio-Vault's AVScheduler

ENCO's Log Check

Power-Link's
Power-Merge

Missing Copy Yes Yes Yes Yes Yes Yes
Copy Out Of Date Yes Yes Yes Yes Yes Yes
Incorrect or dissimilar Spot Descriptions Yes No No No No Yes
Incorrect Durations from Traffic Yes No No No No Yes
Incorrect ISCI Codes in Automation Yes No No No No Yes
User Adjustable Tolerances for dissimilar Titles Yes No No No No No
User Adjustable Tolerances for duration warnings Yes No No No No Yes
Immediate Notification Via Email to unlimited specified recipients Yes No No No No No
Immediate posting to intra-station website Yes No No No No No
Allows any User without workstation license to quickly view Inventory Yes No No No No Yes
Ability to specify different policies for different type events (EG: Spots vs ID's) Yes No No No No No
Allows User to put ISCI code in Title field (along with title) if ISCI field is not available Yes No No No No No
Allows user to specify certain cart numbers not to be tested Yes No No No No Yes
Produces Audit Trail of Accountability and Supervisor's Report Yes No No No No No

 






Information on DCS's Log Merge

Below is a quote from http://www.dcstools.com/_Products/dcsTools_Price_List.pdf#search=%22dcs%20maestro%20log%20merge%22
( the writer's website )

LogMerge is the original traffic and music log merge utility for DCS and Maestro. A DCS or Maestro inventory (if available at merge time) is used to validate the log for missing or out-of-date audio. LogMerge checks for items on the traffic log that did not make it to the finished log, and time-corrects logged elements, producing a list of unresolvable errors for operator attention. LogMerge supports most popular music scheduling and traffic systems. Base software includes support for 2 stations. Additional stations are $50.00 each.  $595.00 LogMerge
 

Return To Top
 


 


 




 


 

Below are Excerpts from the manual on the above mentioned subjects, many of which are found on this configuration screen

The complete Media Check Manual in PDF file format

 





  1. Checking Automation Start / Kill dates
    . This refers to checking that the start date in automation is before or equal to the log date, and likewise that the kill date in automation is later then the log date. Either one or both of these discrepancy types can be ignored globally. This is the only setting for which there is no equivalent setting for each event type. 
     

     

     

     


    Return To Top

     




    Return To Top


     

  2. Comparing Description Fields Description matching is a very interesting challenge. Consider that you have several different people entering orders into the sales order system, copy instructions into the traffic system, and cart descriptions into the automation system. Maybe some stations have data entry standards, which dictate exactly how each advertiser; spot title and ISCI code are to be spelled and formatted when entered into all of these different systems, but in practice this is highly unlikely. In order to deal with all of the various ways descriptions may be entered, Media-Check uses what is referred to as “fuzzy logic” when attempting to identify matches between descriptions on the log and those in the automation system. Fine-tuning the percent tolerance values, as well as utilization of the “Advanced Matching Options” that Media-Check offers can have a dramatic effect on the accuracy of description matching results (“Advanced Matching Options” will be discussed in a later section). In some cases where these descriptions are being entered in wildly different ways, it may be necessary to establish a policy to enforce a somewhat standardized way things are entered into all of the different systems. However, it is our intent at Power-Link to provide a wide range of options that should allow the great majority of our clients ways to setup tolerances and specify matching techniques such that Media-Check will adapt to their way of doing business, rather than the other way around.
    Another interesting situation that makes description matching even more fascinating is that typically traffic logs have several description fields, such as: Advertiser, Product, Spot Title, and ISCI, while most automation systems have just a single, short field for the cart description. Some automation systems do have a separate field for “Agency” (a.k.a. “ISCI” codes) but we have found that in practice, this field is seldom used.  The way Media-Check addresses this gray area is to give you as many options as we can, and then leave it up to you to experiment and see what works best in your situation.
    Be aware that the description matching issue cuts both ways like a double-edged sword. If tolerances are too tight, many carts that are really ok are going to show-up as discrepant—that’s a distraction, but the opposite problem is much worse. If tolerances are set too wide, false positives become a big problem. They are hard to catch, because carts that pass the media-check don’t show up on reports. It completely defeats the purpose using of Media-Check when a cart that was WRONG passes through unnoticed and is aired in place of the correct one. A lot of work goes into this stage of the process, but it is time well spent when you finally find the correct combination of settings that works for your station.


     
    Return To Top
     


    User Adjustable Tolerances

     

      1. Another thing that Media-Check does by default when matching descriptions, is base the percentage match it finds on the length of the shorter of the two fields being compared. This option allows you to override the default behavior and to always base the percentage match on the length of the inventory field, even if it’s longer than the log fields.
        Perhaps an explanation of part of Media-Check’s description matching technique will make this more clear: When looking for a match between the log and automation, Media-Check takes all of the description fields from the log, excluding ISCI if we are looking for it in the automation system’s dedicated ISCI field, and joins them into one
        monolithic field. We take all of the fields from the log because there’s no way of telling which of these fields, or which parts of these fields, will end up being a part of the description field entered into the automation system. Next Media-Check removes all those bad non-alphanumeric characters (except for your good ones) from both the log and automation fields. Now one big nonsensical field from the log is compared to the automation description field using our aforementioned fuzzy logic methods. Sometimes a certain number of sets of unique consecutive matching characters are found. In most cases, the automation field is the shorter field and we use it as the basis for computing the percentage match ([number of matching characters found, divided by the length of the automation field] x 100 = percentage match).
        But in a few extremely rare circumstances the log fields, even when combined, are still shorter than the description field in automation.
        As an example: the log says “XBC” and the inventory description says “XBC Sunday Night Movie.” Three is the maximum number of matching characters that we could find, because the log just has 3 characters in it’s description field: “XBC”, however the inventory description is 20 chars long. This is the reason the default behavior is to use the shortest field length. In this case the match would be 100%. However if you use this option to force the inventory field length to always be used, the match drops to 15%. If this is the way you want to do it, this option is for you!



        Return To Top





     


     



    Return To Top

  3. Duration Warnings by Comparing Cart Lengths



    Comparing Cart Lengths
    . This is one of the items that does appear on the events tab, so there could be values specified there that pertain only to certain event types which would override any value entered here for events of that type.
    There are two methods of evaluating the length of carts in the automation system as compared to an event length from the log:
    1. Method A. This method, “% +/- Variance Log vs. Automation Length,” is the easiest to specify. A percentage value is simply entered which applies to all events regardless of their length. For instance, if the tolerance is set at 10%, an event on the log that is 60 seconds long is allowed to use carts that are within 54-66 seconds in length. At first glance, this seems like a very good setting.  Events that are 10 seconds long can accept lengths of 9-11 seconds. That is starting to look like a very strict rule. How more so for a 5-second spot? Only copy that is 4.5-5.5 seconds long will be acceptable. This would be a very difficult, if not impossible, standard to meet for 5-second spots.  But even with the exaggerated effect percentage tolerances have on short events, this method is the simplest to specify, and in many cases works just fine. Please note that when a cart falls outside of these percentage tolerance ranges, discrepancy reports will express the allowable tolerance in terms of a range of allowable length values, consistent with the way acceptable ranges of cart lengths are defined using Method B, below.
    2. Method B.Specify Range for Each Cart Length” was designed to provide the opportunity to have a much finer grained control of the range of cart lengths in the automation system that are acceptable to use for an event of a given length on the log.  Using this method, you first enter an event length that would appear on the log. Then enter the shortest possible length of a cart in the automation system that would be acceptable for this length event and likewise the longest length cart that would be acceptable.  Enter as many data points as you like. However, traffic logs often contain a small set of standard event lengths, so long lists of ranges may not be necessary. A very common set of event lengths on a log might be :05, :10, :20, :30, and 1:00 These are the default lengths used by the configuration editor, but it is possible to use as many or as few as you like. The finer grained control you need, the more data points that should be entered. The mechanics of setting range values will be discussed shortly.
      When the “Set Ranges” button on the Global tab page is pressed, this window is displayed.

      Return To Top



       



      Return To Top




  4. Comparing ISCI
    – Matching ISCI codes is a whole different ballgame as compared to descriptions. ISCI codes have very definite values; they are meant to be a unique combination of letters and numbers that unequivocally identify a particular piece of copy for a specific advertiser. However, given the aforementioned notoriously short automation description field lengths, ISCIs often get “abbreviated” or truncated when squeezed into an automation description field along with product name, advertiser, etc.
    So when doing ISCI matching, Media-Check assumes that if the whole ISCI is not there, fully intact; that the portion of it that is there will be made up of continuous characters from the original. It may have some characters chopped off the front or back end, but it won’t be scrambled up with bits and pieces all over the place. So ISCI matching is quite strict as compared to the “fuzzy logic” methods used to match the other description fields. There are ways of dealing with this, which will be discussed in the following paragraphs.

     


    Return To Top

     

     

     



     





  5. Here you can specify one range of carts to always ignore. The only rules in specifying these ranges are that the range low and high must be matching in kind. In other words C1-C999 is ok C1-G4, NOT ok. - C100-4300, NOT ok. Also backward ranges, like L200-L1, NOT ok. You will not be allowed to save an incorrectly formed cart number range.
    1. By entering any number of single “cart number specifications” to this list you are telling Media-Check to always ignore cart numbers matching the specifications. The word “specification” is used because in addition to simply entering explicit cart numbers to ignore like L1 or C22 you can use “wildcard” characters in your specifications. By using wildcards in a cart number specification, a single specification could potentially match an unlimited number of different cart numbers. You are probably already familiar with the two standard wildcard characters used by DOS and Windows for specifying file names: “ * ” and “ ? ” (the splat, and question mark).
      Things like: “ N* ” would match any cart numbers starting with “N.” Or “ C3?? ” Would match any cart beginning with C 3 followed by exactly 2 more characters of any type.

      That’s nice but not good enough for Power-Link. We have gone a few steps further and taken pattern matching to a entirely new level with the addition of the “ # ” and “ @ ” wildcard characters.

       

    *

    Matches zero to an unlimited number of any characters

    ?

    Matches Exactly One of any type of character

    #

    Matches Exactly One numeric digit

    @

    Matches Exactly One alphabetical character


    Now you can specify wildcard matches that were not possible before.
    For instance: “
    X@1## would match a cart number that was exactly 5 characters long, starting with “X” followed by exactly on letter, followed by a “1” and then exactly two digits. You can also use the old wildcards in combination with the new ones: “ @5*A# “ would match a cart number of at least 4 characters in length starting with any single letter then a “5” followed by zero or more of any character except “A.” Then an “A” followed by any single digit. You probably don’t use weird cart numbers like this, but if you do, Media-Check can handle it.
    This makes for some very specialized and accurate pattern matching, but you’ve got to keep a few things in mind.

    When you see something like this  “ *# ” in this case the splat can represent zero to an infinite number of non-numeric characters because the first numeric it encounters ends the splat’s run.

    Likewise “ @*@ “ means that the splat can only contain non-alpha characters.

    Interesting stuff, but you’ve just got to be extra careful that you know exactly what you’re asking for when using these new wild wildcards in your cart number specifications.

    Return To Top


     



    Return To Top
     

  6. General Email Recipient Options

    1.              “Only Send Report if Discrepancies Exist.” This option is handy for those on your distribution list that don’t want to be bothered unless there is s problem that needs attention. The only caution with this option is that there should be SOMEONE on the recipient list who is getting reports every day, even if there are no discrepancies. This person will get used to receiving their report by a certain time every day and if a report does not show up in their mailbox, can look into the matter to assure that there is not a problem preventing Media-Check from sending email. It may be that Traffic is just a little behind schedule finalizing the log and the report will be a little late, but if there is a technical glitch causing the problem, the appropriate people need to be made aware of the situation so that it can be resolved. Otherwise the person using this option may be lulled into thinking everything is ok, when there actually may be some un-reported discrepancies.

    2.              “Send Report as HTML.” Checking this option tells Media-Check to send email in the much richer HTML format. Leaving it unchecked will result in email reports being sent as plain text. Note that this option is only meaningful if email is being sent via the SMTP email method. Simple MAPI email does not support HTML content, so if this is checked it will have no effect. Email will always be sent as plain text for stations using MAPI. There will be more to follow regarding the different email methods in the “Email Options” section.

    3.              Use for Daily Archive,” “Use as Web/Show Me Report.” & “Use for Printed Report” These checkboxes allow you to tell Media-Check which report format it should use for archiving, web reporting, displaying an instant report with the SHOWME feature of Run Media-Check, and printing. These checkboxes can be checked for any report that is being sent to a particular email recipient, or may be used with a report that is not being sent to anyone. If you want to use a report that is not being emailed to someone for either of these purposes, simply create a report format and check or more of these checkboxes. At that point you can add the report to the list even though the email address and name edit boxes are empty. Any of these options may only be assigned to one report format. So if you have one report tagged for one of these options and you subsequently set it for another report in the list, the report that originally had the checkbox checked will have it removed.
    If one of these checkboxes is not checked for any of the reports in the list, a default report format will be used for that type of output.

    Return To Top




     




    Return To Top

  7. Web Reports

    1.  This feature allows you to create a web page containing a discrepancy report. You can choose any report format you design, or use the default format. You can give the page a name, tell Media-Check where to place the web page within your local or network file system, change the background color, use a background image, and place a banner image at the top of the page, aligned left, right or center.

    This feature could be used to post a discrepancy report on an INTERNAL web server, where interested people could surf over to see what’s up with the log vs. the automation system.

    You can choose to use the background colors, background image and banner image specified here for HTML emails if you like. The only consideration when using the images in emails is that they need to be available at a URL on the Internet or your internal intranet where an email client program can find them.


    Return To Top



     



    Return To Top

  8. Get Up to Date Inventory


     

    “Get Up to Date Inventory” will cause the INVRead program to run and translate the automation inventory files for the selected stations prior to calling Media-Check. This way Media-Check will be using the freshest, most up-to-date inventory when checking against the log.
    This option has no effect when running INVRead by itself, since it always gets the latest inventory.
     

     


    Return To Top


     


     



    Return To Top

  9. Global Matching Criteria Tab

     

    This tab looks very much like the “Global Matching Criteria” tab; in fact it is almost identical. The purpose of this tab is to allow all of the configurability available on a global level to be broken out by event type. So that, for instance: different tolerances could be used for PSAs or Announcements than those that were set up globally for all other event types. It also allows you to completely ignore all events of a certain event type by checking the checkbox just above the little red circle in upper left corner of screen, underlined in yellow.

    You can also declare that a particular event type is “Commercial” by checking the checkbox that is circled in the top left-hand part of the screen. This event type attribute is used in conjunction with the setting on the Global tab’s “Advanced Settings,” which lets you tell Media-Check to “Only compare ISCI on Commercial events.” It is also used when defining Preformatted Report Styles-on the “Discrepancy Notifications” tab. You can create a report template that applies only to these “Commercial” event types or the opposite of that, only “Non-Commercial” event types.

     

    Return To Top

     




    Return To Top



  10.  

    Often ISCI code is embed somewhere inside of the automation description field. Sometimes it’s at the beginning, sometimes at the end. It could be anywhere. The point is, it is usually there someplace and he wanted us to specifically try to identify the embedded ISCI code wherever we could find it. But once we find an ISCI code within the automation description field the story doesn’t stop there, we may still be looking for other log description items like product name, advertiser, or spot title in the field where we already rooted out the ISCI. In this situation, there is no point looking for the other log fields inside the portion of the automation field already identified as being the ISCI, so we remove that portion of the automation description field which contained the ISCI, recombine the remaining portions of the field, and now just search what’s left for the other log description fields.

    Return To Top

     



    Return To Top

     

  11. The Executive Report


     

    In order to allow a supervisor to keep tabs on continuity issues. this selection produces a simplified report shown below:
     

    Return To Top