29 ноября 04 года


          Напоминаю, что в связи с катастрофической нерегулярностью выпусков - интересующиеся могут подписаться. Адрес е-почты - внизу странички, форма - произвольная (мало у меня читателей, автоматику заводить дороже чем руками обрабатывать).
          Существуют педофилы, некрофилы, некро-педо-зоофилы ("...мертвых маленьких зверюшек он с собою приносил"), и - аудиофилы. Последние - самые страшные, ибо то, в какой позе они имеют звук - смотреть иногда страшно, не то что слушать. (В скобках замечу - себе я сейчас собрал "5.0 систему" на основе M-audio revolution, самодельного усилка на TDA7294, двух S90 (фронта), двух 50АС-104 (тылы), двух (одна над другой:-)) самодельных колоночек на 25-ГДШ-не_помню и двух "пищалках"... сижу - тащусь, хоть и не хай-энд далеко).
          Так вот, читать - интересно. Особенно когда в поисках чего-нибудь практически полезного - набредаешь вдруг на их гнездо [http://www.audioworld.ru] :-)
          Доработка К40-У9 [http://www.audioworld.ru/DIY/Dop/k40u9.html]. О - думаю - какой-нибудь усилок дорабатывают, раз "У9". Или колонки советские. Счас почитаю, думаю.
          Доработка конденсатора. Металлопленочного, кажется. Правда, автор пока не смог придумать куда бы его такой доработанный засунуть, и результатов прослушивания нет, но - это только начало! Впереди - доработка до лучшего звучания индикаторных светодиодов и ручек регулировки тембра! Если по пути кому-нибудь не стукнет в голову светлая идея доработки микросхем интегральных УМЗЧ путем отрезания у них ног. А что - чем короче ноги, тем меньше потери и реактивная составляющая, глядишь - для хай-энда и потянет.
          Какие болванки [http://www.audioworld.ru/FAQ/Silicon/cd_08.html] использовать для аудио-CD. Форум. Оййййй... "не бери такие-то, частотка ни к черту, на верхах нелинейные, скрипки в кашу... бери такие-то, там более-менее... писалка - лучше внешняя, чтобы от шумов компьютера избавиться... плексторы, вся система только скази, иначе грязный звук"... мама!!!
          Но!!! Как выяснилось - не всё из этого является абсолютным бредом. Есть и объективные, измеряемые вещи - побитно одинаково читающиеся диски могут звучать по разному - тот, что "похуже" звучать будет похуже. Причем - измеряемо хуже. Выдернуто из ссылки выше:


From: gnat
[...] Рид-Соломон, ***когда*** он срабатывает, таки восстанавливает исходный сигнал СТОПРОЦЕНТНО КОРРЕКТНО. В ЦД-ДА избыточность 14:8, упрощенно говоря, РЕАЛЬНО НУЖНЫЕ 8 бит записываются в 14 и если из 14 бит 6 считаны неудачно, все-таки можно восстановить исходные 8. Глюки начинаются, когда упрощенно говоря не считаны 7 и больше из 14 бит, тогда включается интерполяция. Ну там еще тонкость - собссно декодер Рида-Соломона есть ФИЗИЧЕСКОЕ устройство и соответственно когда он ФИЗИЧЕСКИ работает, при недостаточно грамотной ФИЗИЧЕСКОЙ его реализации может влиять на звук. Кажется, как раз с этим был связан продемонстирированный на позапрошлогодней iirc конференции AES забавный казус объективной разницы в звучании двух дисков с одной и той же записью, причем считывавшихся без интерполяции, то есть побитно одинаково. Там вроде бы при работе Р-С декодера помехи по питанию проникали в БП и дальше получалась слышимое в слепых тестах (и измеримое само собой) изменение звучания. Ну, один из дисков был в лучшем состоянии и декодер на нем не активизировался, а на другом соответственно пахал вовсю...



          То есть - эффект есть, и "плохой" диск таки может звучать хуже. Хорошо, что мне пофиг - последний раз CD не через компьютер я играл уже и не вспомню когда :-)
          Вот такое [issue291104/CRW_5550v2.jpg] можно получить при помощи скромного по сегодняшним меркам canon G5 (5 мпикс, 4х зум), объектива "гелиос-44" от зенита (150р в комиссионке, при желании можнонайти и за 50р), объектива Юпитер-21М (покупался за 600р), телеконвертора (покупался за 150р), удлиннительных колец, штатива, "скотча и жвачки" (в смысле, ткани и эпоксидки).
          Если кому интересны детали конструкции - пишите заявку на е-почту, а я поборю свою лень и расскажу как такое делается :-)
          Языки программирования бывают разные. "Структурный ассемблер" Си - можно всё, но если что - сам виноват. "Скриптовые" - очень удобно очень быстро и очень компактно решить некий круг задач, при этом о сложных проектах или эффективности речь не идет. "Строго типизованные и контролирующие" - паскалеобразные, в которых программисту нужно постараться чтобы допустить семантическую ошибку, незамеченную компилятором. "Объектно-озабоченные" - с надетой поверх скриптового, ассемблерного или строгого языка объектной нашлепкой вида "есть груда объектов и можно дёргать их за свойства и методы". "Объектно-ориентированные" - где язык сам строится под объектной идеей (язык в результате обычно достаточно строг и типизован)...
          Общее направление развития сейчас - сделать так, чтобы программист просто не мог допустить ошибку. То есть, чтобы конструкции языка, потенциально приводящие к ошибкам, были либо строго не допустимы, либо требовали бы явных и хитрых манипуляций ключевыми словами и буквами. В этом смысле Си например - поощряет опасные конструкции, Паскаль - в большинстве реализаций допускает, но после определенных заклинаний, а скриптовые языки - не имеют подобных конструкций в принципе. При этом вполне достаточным оказалось отнять у пользователя возможность "тыкать" в память произвольным указателем (пусть использует массивы) и ввести либо строгую типизацию (Паскаль), либо убрать типизацию вообще ("всё есть строка, которая при необходимости по разному интерпретируется").
          Но есть ещё одна, неучтенная, возможность допускать ошибки. Которая возможность используется у нас, например, на полную :-) Это - ошибки в формулах: тут забыли константу, тут умножили а не поделили, тут - перепутали степень... "Это ошибки алгоритма, компилятор не может их ловить!" - скажете вы, и будете не совсем правы.
          Ещё в школе нас учили проверять формулы используя "размерность". Паскаль (не язык, а мера давления) - это ньютон на метр квадратный. Ньютон - выражается через массу и ускорение. Ускорение - через метры и секунды... и так далее. И если размерность формулы не сошлась - формула скорее всего неверна.
          Ничто не мешает создать язык с не просто "типизованными", но с "размерными" типами данных. Программист задает размерности переменных, правила преобразования размерностей (F=m*a и тому подобное), а компилятор при компиляции выдает диагностику "вот тут потерялась напряженность электрического поля" или "вольты и киловольты различаются в 1000 раз". И наступила бы ещё одна ступень программистского счастья - особенно учитывая, что на скорость работы программы это никак не влияло бы.

          Я таких языков не знаю. Размышления на тему "можно ли сделать такое в каком-то из существующих языков" привели к выводу "так чтобы работало - нельзя, хотя кое-как, с большими неудобствами, наверное можно". Интересно - можно ли? Или - может быть - уже есть такое, просто я не знаю?...
          Берем фотографию размером N мегапикселей... ой, не так.
          Берем нейронную сеть побольше. И базу фотографий - хороших фотографий, с высоким качеством вообще и разрешением в частности. Показываем всю базу нейронной сети - пусть учится. Учится распознавать в первую очередь локальные, маломасштабные детали фотографий - текстуру/фактуру, мелкие закорючки/неровности объектов, и подобное.
          А вот теперь - берем фотографию размером N мегапикселей, и показываем её нейронной сети. "Опознала? Классно! Теперь давай, рисуй мне что там между пикселями - ты же отличишь фактуру волос от фактуры ковра, вот и придумывай пиксели так, чтобы было похоже на то, что ты видела раньше".
          Должно получиться интересно. Обычное растяжение, с любого рода "шарпенами" - не добавляет деталей, поскольку не может их "придумать". Пробованные мной алгоритмы "фрактальной интерполяции" - работают долго, и детали таки придумывают (под то и писаны, чтобы видимую детализацию поднимать), но поскольку они не знают (то есть вообще не знают) "что на фотке", и работают фактически придумывая "от балды" какую-то фигурку, вписывающуся в имеющиеся пиксели - артефактов такое дает не меньше, чем похожих на правду деталей. Здесь же, когда алгоритм сможет распознать "общую структуру" восстанавливаемой части изображения (а, к примеру, волосы и ткань имеют совсем разную и четко различимую структуру) - артефактов должно быть на порядок меньше, и качество восстановления соответственно - на порядок лучше. В том смысле, что можно будет растянуть довольно сильно, при этом не получивши эффект "синтетичности" картинки.
          ...разумеется, такой метод не будет идеален даже при идеальной реализации. Если текстура изначально "съедена" низким разрешением - алгоритм не сможет её восстановить. Возможны ошибки распознавания - поэтому не удивляйтесь портрету с волосами имеющими текстуру джинсовой ткани - "он художник, он так видит"(с)анекдот. Но - на это можно добавить "ручной режим": выделяем зону, нажимаем пипку "неправильно!" (пипка запрещает использование текстуры, распознанной нейронкой как "наиболее похожая"), волосы перестают быть похожими на джинсы. Или - выделяем зону, нажимаем пипку "ну распознай хоть что-нибудь" - и алгоритм пытается наложить хоть какую-то, похожую на то что надо, текстуру. Ну, и так далее :-)
          ...ну, и разумеется - я не знаю такой программы в сколь либо "готовом" виде. Поэтому "нейронка" в этом тексте - не более чем ярлычок, это вполне может быть какой-нибудь "множественный локальный корреляционный анализ" или ещё какая умная штуковина. Просто "нейронка" - красивше звучит :-)
          Ну, и никто не запрещает использовать тот же метод (даже более простой технически - ибо одномерный и с заранее известным, в отличие от фотографии, "масштабом") для "подчистки" искаженных музыкальных записей. Даже в искаженной - "тсыкающей", скрипучей - записи мы с легкостью распознаем отдельные инструменты, и "отделяем" их от искажений. Далее - то же самое: обучаем "нейронку" (коррелятор, ещё чего) неискаженному и искаженным звучаниям инструментов, а дальше - пусть распознает искаженное звучание, вычитает искаженное (вместе с искажениями - для чего нейронка и должна знать искаженное звучание!), вставляет неискаженное. Нераспознанное - остается как есть, благо такого нераспознанного в общем случае будет немного - ведь, к примеру, голос - это тоже инструмент, и голос тоже можно "зашить" в такую программу. А шум - инструмент с характерным "ровным" спектром, неискаженная версия которого звучит никак :-)
          И - обязательный бегунок "глубина подавления глюков". Чтобы в качественной записи, которую нужно "прилизать" для доведения до "хай энд" уровня - не пыталось заменить драм-машиной неровности попадания по барабанам живим барабанщиком :-)
          Опять же - реализаций мне неизвестно. Подавление шума и очень грубое снижение "слышимости" нелинейных искажений - реализовано в adobe audition, но всё это - ну слишком уж "на коленке" по сравнению с подобным методом.
          Никто не возмется, а? ;-)
          По мотивам одного трида в RU.OS.CMP.
          Есть такая забавная задача. Организовать доступ к данным с возможностью быстрого их уничтожения (или возможности сделать вид что "не было тут никаких данных"). И, желательно, с возможностью восстановления - но опять же так, чтобы любому человеку "со стороны" казалось, что данных либо не было вообще, либо они уничтожены и бэкапа не существует.
          Пример - "теневая бухгалтерия" небольшой фирмы, которая должна быть уничтожена "одним движением" при появлении "маски-шоу", при этом у "масок" не должно возникать мысли, что информация - восстановима (иначе, применяя методы, родственные ректотермальному криптоанализу, данные будут восстановлены). Можно развивать ситуацию дальше - до уровня "государственной тайны" - тогда внешние связи офиса могут предварительно прослушиваться, проглядываться, и мониториться на провайдере (а значит, бэкап не сольешь по сети на другой конец страны или на сайт на народ.ру). Методы уничтожения... от иконки на рабочем столе, запускающей удаление (наихудший метод - иконку можно не успеть кликнуть, а физическое удаление происходит небыстро) до обученного охранника, стреляющего в "ключевой момент" в нарисованную на боку сервера "мишень", чтобы разнести жесткий диск. Метод неплохой - но что в этом случае делать с бэкапом?
          "Шифрованные диски" не катят - пароль на диск будет получен всё тем же ректотермальным методом. Шифрованный диск с двумя паролями, самоуничтожающийся при вводе второго пароля - не катит, ибо "пустышку" заметят, процесс уничтожения тоже, а уничтожить-то он себя и не сможет: правильные эксперты предварительно снимут копию жесткого диска. Работать по сети - "на соседний комп" плохо, найдут на соседнем компе, "вдаль" - либо отследят на уровне провайдера, либо найдут ссылки/ярлыки на удаленный комп (хотя бы в documents history), и... далее всё тот же ректотермальный метод. Что делать?!
          ""Современный уровень технологий позволяет замуровать в стенке WiFi точку доступа на пару с системником и хранить всё там, организовав VPN до туда, а в случае чего просто рубать питание этого сегмента, что-б Wi-Fi не светился..."(c)Vadim Priluzkiy"
          С дополнениями. Если сделать ровно так - то во-первых на рабочих компьютерах сохранятся "следы" работы с этим "сервером" - а далее... ну, вы помните. Во-вторых (будем параноиками и забудем про бухгалтерию - пусть у нас задачи уровня Государственной Тайны!) - WiFi оно в эфире светится, и при желании легко составить табличку компьютеров в этой комнате. И если по данным прослушивания их пять, а конфисковано четыре, то... понятно.
          Поэтому делаем чуть сложнее. Во-первых, перед сервером ставим (по питанию) "пускатель" - хреновину, требующую после подачи питания Главным Рубильником - нажать кнопочку для собственно включения. После этого включение питания не приведет к включению (жужжанию/пиканию и выходу в эфир) сервера - пока кто-то не найдет и не нажмет (хитро спрятанную) кнопочку. А во-вторых - ставим под стол :-) обычный десктоп с такой же WiFi-карточкой, только перепрошитой так, чтобы с точки зрения "эфира" (что там у них как идентификатор не знаю) - она выглядела в точности как та, что в "сервере". На десктоп - ставим ту же ОС с тем же VPN что у сервера... в-общем, создаем "точную копию" сервера - но нормально выключенную. На диск набиваем киношек-порнушек-мпегов, фотки с позапрошлогоднего нового года и прочего стандартного хлама, и - оставляем выключенным.
          В "случае чего" - даже делать особо ничего не надо, разве что питание дернуть. Можно во всем офисе сразу - "сервер" всё равно сам после включения общего рубильника не поднимется. И всё - информация есть, но информации об информации - нет: все "сохраненные ссылки" ведут на поддельный сервер... и даже повода применять ректотермальный криптоанализ - как бы нет.
          ...а уж кому и зачем оно реально понадобится - я не знаю и ответственности не несу :-)
         

- RU.PHOTO.DIGITAL
From : Alex Tutubalin, Sat 27 Nov 04 22:22
Subj : О производительности Photoshop
Привет.

Если сделать в Windows ramdisk - и туда положить свап, то производительность может и не вырастет. А вот если сделать рамдиск и положить туда скратч-файлы фотошопа (все равно он больше 2Gb использовать не может), то производительность растет кардинально.

Цифры тут: http://www.lexa.ru/articles/photoshop.html#pscs [http://www.lexa.ru/articles/photoshop.html#pscs]

Старые данные, очевидно, можно выкинуть.

--
Алексей Тутубалин
lexa@lexa.ru
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)

          Рецензия на научную статью (черновик). Не скажу кто автор (не я). Но некоторые места - мне нравятся.
          "Авторам удалось получить интересные (зачеркнуто), оригинальные (зачеркнуто)... результаты [issue291104/PICT0009.jpg]"...
          "Отсутутвуют также ссылки на литературу (учебник (зачеркнуто)) [issue291104/PICT0010.jpg]..."
          "Опнакелю" - это "проблема" на опхберском. Опнакелю бывают разные, и особенно часто встречаются в интернет. Но такого опнакелю - в софте, шедшем вместе с (предустановленном на) ноутбук Тошиба - не ожидал.
Опнакелю

         
scsi
чё сказать хотело - я не понял. Дешевая скази-карточка "от сканера"...



Оригинал страницы находится на http://dibr.nnov.ru/issue291104.html.(с) DiBR
При перепечатке ссылка обязательна. <<  *  >>