I was doing an "odd" translation this week - *backwards*, from Obsession 5.1 to Obsession 4.4.2 . I thought it would be easier than usual, but I found what looks like a tracking bug in Obsession Off-Line 5.2's ASCII output.
I haven't tested this with EOS Offline, so I suppose it's possible that EOS's ASCII-in interprets the extra keyword $$CUEBLOCK (see below) in a way that eliminates the erronious output. But it seems to me that even the augmented keyword-set output is technically wrong. I'm posting my observation to see if anyone else has had a similar experience. If you have time, please try to reproduce the error as I outline it below.
Rather than post a show file that might have questionable integrity, this is quickly reproducible: After freshly instantiating OOL 5.2, I reduced the channel count to 10 and created two cues, which in tracking look kind of like this:
Ch 01 02 03 04 05 06 07 08 09 10
Q1 50
Q2 00 00 00 00 00 00 00 00 00 00
Then, when you output ASCII, if you exclude the augmented keywords, you get:
! Cues
CUE 1
UP 5
DOWN 5
CHAN 4@50
CUE 2
UP 5
DOWN 5
CHAN 4@50
!Error above this line
If you include the full keyword output, you get:
CUE 1
UP 5
DOWN 5
CHAN 4@50
$$CHANMOVES 4@50
CUE 2
UP 5
DOWN 5
CHAN 4@50
!Error above this line
$$CUEBLOCK 2
Naturally , I first found this error in a real Obsn II 5.1 show (1000 channels). I discovered the problem when I was doing a "reasonableness" check of some of the translated cues, and found more than one level had tracked into a blocked zero. Although I'd been looking forward to using that great new output feature, I was still able to translate the show by using my code that parses a printout file. This produced correct ASCII for the blocked channels.
(Subject line edited to include full version number 1/5/2007 T.H.B.)
[edited by: tbuchman at 4:24 PM (GMT -6) on Sat, Jan 05 2008] Added proper software version number
