In order for the generic log to be properly executed by the host audio system, certain guidelines need to be followed in constructing and/or exporting the log. This topic provides basic guidelines intended to ensure that the generic log executes properly on the host system.
The original specification published by Computer Concepts Corporation, Lenexa, KS, did not include log construction guidelines. This content is provided to minimize pitfalls that might be encountered in constructing and/or exporting a generic log for use by the host audio system. |
The first record in the generic log file must be an informational record (ID Record) in order to be considered valid. If the ID Record is not present, the log will not be processed by the host audio system.
When loading the generic log, the host audio system uses non-audio log records as anchor points for the the audio items. Typically, a Directive record type is used, but Program Title and Log Note records can also be used. The host system groups the audio items following the anchor as a sequence based on the anchor item's time value. Consider the following fragment of a generic log file:
...
D0020LR00400 Load Required Brk <== "Anchor Point"
C0020:01T118Get Well Games 00059CM
C0020:02T120DENTYNE/reg or sugarfree 00029CM
D0100LR00300 Load Required Brk <== "Anchor Point"
C0100:01T004DIET COKE/Q:Diet Coke! 00059CM
C0100:02T010VERNE & BUBBA'S DONUT 00049CM
C0100:03T110DoubleTree 00058CM
...
As you can see in the fragment, a Directive is scheduled at 00:20 (12:20 AM). The following audio items (commercials in this case) have the same starting times in terms of hour and minute (12:20 AM) and contain a seconds value. The two commercials in the example are "anchored" to the Directive. The next grouping is at 01:00 (1:00 AM). The host system typically creates "spacing" so the visual representation of the log appears similar to an original paper log document.
This concept of anchoring is particularly important if the host system is running satellite automation. The Directive "anchors" have the effect of grouping the breaks (stopsets) for playback when the programming service signals a local breakaway.
In live programming segments, using one of the record types that serves as a content anchor assists in making the log visualization on the host system easier to use.
While it may be counterintuitive, audio items following an anchor item in the generic log need to be incremented by one second for each item following the Directive, Program Title or Log Note. The main reason for this requirement is to maximize the number of elements a log contains.
Since the generic log structure uses the time values as unique record identifiers, incrementing by one second increases the number of records that can be contained within the generic log substantially. Review the generic log file fragment to see how this construction appears in the file:
...
D0020LR00400 Load Required Brk <== "Anchor Point"
C0020:01T118Get Well Games 00059CM <== Item incremented 1 second
C0020:02T120DENTYNE/reg or sugarfree 00029CM <== Item incremented 1 second
C0020:03T010VERNE & BUBBA'S DONUT 00049CM... <== Item incremented 1 second
...
Simply passing a traffic or music scheduling system "log time" through to the generic log file is the most common pitfall encountered when constructing and/or exporting a log. If the log times are not adjusted and properly incremented, the results on the host audio system are unpredictable.
XStudio compensates for this problem when opening a log by automatically adjusting the times to meet the log file specification. If there is a problem making the adjustments, XStudio will warn the end-user of the problems.