I share the skepticism towards the value of ETF as an archiving format, as compared with something like MusicXML.
ETF is nothing more than a text representation of the binary .mus file. The only sense in which it is "open" is in the fact that it is text. The short document that Makemusic released describes the general layout, but it contains no specifics about each record. It contains no list of record types, and anyway the list and contents of each record potentially changes with each version number. But the fundamental problem is, an ETF by itself does not contain enough information from which to reproduce many important formatting details. The information that determines the result we see on paper is in fact embodied in the default behavior of the Finale program rather than any data it reads. In many cases, the data in the ETF simply specify offsets from Finale's default behavor. Without knowing Finale's default behavior, for example, it is impossible to determine the stem lengths under a beam. If one were trying to reconstruct a score from an ETF 100 years hence, and no working Finale version were available, it would be effectively be impossible. A great example of what I'm talking about is Tuplets. Everything in the tuplet dialog box specifies a modification to an underlying default behavior. The only way to know where the tuplet actually is is to figure out the default behavior and then apply all the mods from the tuplet settings. (The tuplet settings you see on the dialog box are stored directly in the ETF, but nothing about the default postion is.) When Makemusic introduced "Engraver" tuplets, effectively what they did is develop a completely new default behavior. You activate the new behavior with the "Engraver" checkbox. For me to have supported engraver tuplets in Tuplet Mover, I would have had to completely reverse-engineer the new default behavior, which is far more complicated than the old default behavior. Nevertheless, the only difference in the data stored in the ETF is exactly one bit. (You can prove this for yourself. Create a file containing a non-engraver tuplet. Save that as ETF. Then change the tuplet to be an engraver tuplet and save that as another ETF. When you compare the two, you will see that they differ by exactly one bit. However, when you compare the screen results, you will see the difference is far more than could possibly be captured by one bit. The rest of the information is encoded in Finale's program behavior.) I suspect even now that MusicXML would be a far better choice for archiving than ETF. I particularly hope that MusicXML will continue to add more formatting information, with the ultimate goal that a rendering program would not have to have *any* default behavior. The data would embody everything about the score. If MusicXML ever gets there, it will have truly arrived. _______________________________________________ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
