Баг в Finale 2006 (перепечатка)

[boris]

В ЖЖ Петра Трубинова онаружил только что пост и, хоть сам нотным набором не занимаюсь и ничего в этом не понимаю, решил на всякий случай бросить сюда. Вдруг кому полезно будет.

Оригинал


Известно, что Finale хранит названия групп нотоносцев в формате текстовых блоков — точно таких же, как и номера страниц, название произведения и так далее. В текстовом формате эти тексты следуют за тэгами ^block и имеют сквозную нумерацию.

Известно так же, что после оптимизации все названия групп получают независимость: их можно редактировать в каждой системе нотоносцев отдельно, и эти изменения не отразятся на названиях тех же групп в других системах. Что это значит? Это значит, что для каждой системы создаётся дополнительный комплект текстовых блоков, дублирующий основной комплект.
Допустим, у вас в партитуре имеется 25 именованных групп нотоносцев. (К примеру, партия виолончелей делится на две, вы записываете их на двух нотоносцах, объединяете акколадой и у этой акколады подписываете «Виолоночели» — и точно так же с остальными инструментами.) После того, как вы набрали ноты и перешли в режим вёрстки, у вас получилось, к примеру, 300 систем (речь идёт об объёмном произведении). Вы запускаете оптимизацию, пустые нотоносцы исчезают, оставшиеся получают независимость. Теперь внимание: программа создала 300 дополнительных комплектов по 25 названий групп. Это значит, что в файле появилось 7500 лишних текстовых блоков, всего навсего дублирующих предыдущие.
Теперь, допустим, вы отредактировали первые несколько страниц, изменили вёрстку, помеяли количество тактов в системах, и теперь заново оптимизируете документ. Finale снова создаёт 7500 дополнительных текстовых блоков. Почему она не использует уже существовавшие до этого? Потому что она знает, что при оптимизации, нужно скопировать названия групп из основного комплекта. Тем фактом, что оптимизация до этого уже проводилась, и копия комплекта для каждой системы создана, она пренебрегает. Вернее, она считает, что предыдущая копия уже не нужна, и удаляет её. Таким образом, размер файла при последующих оптимизациях не увеличивается так же, как в первый раз. Просто 7500 текстовых блоков встают на место предыдущих 7500. Однако номера новых блоков следуют за удалёнными, а не замещают их.
Таким образом мы имеем:
Блоки 1–25 — основной комплект,
блоки 26–7525 — пропуск; блоков с этими номерами не существует,
блоки 7526–15026 — копии блоков с названиями групп для каждой системы после второй оптимизации.

Если вы привыкли работать страница за страницей, то при размере партитуры в 300 систем (это может быть от 100 до 300 страниц), вы захотите проделать оптимизацию ещё очень много раз. Возможно, все 300. И наверняка вы будете оптимизировать не только ту систему, с которой сейчас работаете, но и все последующие. Однако уже после четвёртой оптимизации нумерация текстовых блоков в файле достигнет 30000, а пятой оптимизации... может не быть. Дело в том, что на хранение номера текстового блока Finale выделяет два байта, и почему-то хранит его как значение со знаком. Это означает, что максимальное значение номера может быть 32767. При попытке создать ещё один новый блок, ему присваивается отрицательный номер -32768, и программа сходит с ума: все тексты в партитуре вдруг пропадают, а после отмены и восстановления последней операции при попытке сохранить файл, программа виснет, дойдя до 99%, старый файл оказывается стёрт, а новый не записан. Все ваши 300 страниц партитуры идут коту под хвост.

Что я сделал. Во-первых, я сохранял копию своей работы каждый день, а когда заметил, что с программой что-то неладное, то стал сохранять копию через каждые несколько операций. Таким образом, вероломное поведение программы не вызвало потери данных. Однако оно приостановило работу, поскольку без оптимизации работать с симфонической партитурой невозможно, а до того момента, когда оптимизация приводит Finale до исступления, я уже дошёл на 20-й странице (впереди ещё около 150).
Во-вторых. После того, как начались трудности, я проанализировал файл, выявил всё, что написано выше и написал программу на Jave, которая отыскивает пропуски в нумерации текстовых блоков в файле, и перекидывает на пропущенные номера блоки с большими номерами, а затем исправляет ссылки на эти блоки из других элементов партитуры. Дополнительная загвоздка возникла из-за того, что начиная с версии 2004 в Finale текстовые обозначения (Text expressions) стали храниться примерно так же, как и текстовые блоки, но с параллельной нумерацией. Однако удалось найти флажок, который показывал, на что ссылается элемент — на блок или на обозначение, и исправлять только нужные ссылки.
Таким образом, сейчас номер последнего текстового блока в моём файле — около 4500. Однако этого хватит всего на несколько оптимизаций, а потом снова придётся пропускать файл через мясорубку моей исправительной программы. Не очень весело, но работать можно.
Если кто-то столкнулся с похожей проблемой, то обращайтесь — приведу программу в товарный вид и поделюсь.

[DJ Хруст]

Спасибо большое, Борис, за информацию.

[Дмитрий А.]

Спасибо. Еще один фактор против работы в F2006. Слышал о глючности этой версии.
Сижу на 2005, 10 лет занимаюсь симфоническими партитурами. Попадаются 150-страничные вокальные клавиры, когда при работе с Lyrics включаются тормоза, от которых клиент, сидящий рядом, зеленеет и ежеминутно охаивает то программу, то компьютер. Бывает, виснет, но потеря работы, утрата файла - ни разу, тьфу-тьфу.

[Ортодокс]

Сижу на 2005

А зачем? 2004 в общем-то такая же, но у меня за много лет не висла ни с того, ни с сего. Тормоза - да, но не глюки. Стараюсь файлы поменьше делать.
Несколько лет назад набирал в 2005-й оперный клавир, там в lyrics через какое-то количество страниц просто исчезали все слоговые разделители. С концами. Командой руками дорисовывали. Последний акт делал уже в 2004-й.
От 2006 пока впечатления приличные.