Взлом музыки для демократизации производного контента

Отказ от ответственности: вся интеллектуальная собственность, проекты и методы, описанные в этой статье, раскрыты в патентах US10014002B2 и US9842609B2.

Вот бы вернуться в 1965 год, постучать в парадную дверь студии «Эбби-Роуд» с пропуском, зайти внутрь — и услышать настоящие голоса Леннона и Маккартни… Что ж, давайте попробуем. Входные данные: MP3 среднего качества песни «Битлз» We Can Work it Out. Верхняя дорожка — входной микс, нижняя дорожка — изолированный вокал, который выделила наша нейросеть.

Привет, Хабр! В данной статье представлена простая реализация Reflective Shadow Maps (алгоритм описан в предыдущей статье). Далее я объясню, как я это сделал и какие подводные камни были. Также будут рассмотрены некоторые возможные оптимизации.


Рисунок 1: Слева направо: без RSM, с RSM, разница

Horizon Zero Dawn находится в списке одних из лучших эксклюзивов для Playstation 4. В роли охотницы Элой игроки путешествуют по постапокалиптическим ландшафтам будущего, чтобы раскрыть тайны её прошлого и узнать о причинах разрушения мира. Упадок человечества привёл к расцвету «машин» — роботов разных форм и размеров, свободно живущих повсюду. Эти животные-роботы умны, скоординированы и смертельно опасны: чтобы выжить, нужно быстро думать, чтобы уничтожить их — тщательно готовиться и планировать.


В этой части статьи я расскажу о геймплее и системах принятия решений, которые делают этих существ живыми и обеспечивают основы игрового процесса. Я буду говорить не только о том, как они принимают решения о разных действиях (собирание ресурсов, охота, выживание), но и как координируются в обширном мире, индивидуально и в группах. Кроме того, я расскажу о том, как игра создаёт экосистему машин, которая сбалансирована и управляема на всех территориях и во всех областях нового мира.

Предупреждение: в статье присутствуют спойлеры сюжета Horizon Zero Dawn.

Продолжаем изучение методов многомерной оптимизации, и следующий на очереди — метод роя частиц осуществляющий поиск глобального минимума.

Больше не всегда значит лучше. Этой фразой можно четко описать соотношение умственных способностей существа с размером его мозга. Рекордсменом в мире животных является кашалот, чей мозг весит порядка 9 кг. Среди сухопутных существ этот титул заслужил индийский слон с 5 кг мозгов в своем распоряжении. Мозг страуса меньше его глазного яблока и весит 26 грамм. А вот мозг одного из самых интеллектуальных видов пернатых — серых попугаев — весит примерно 118 грамм, то есть около 22 % от общего веса тела. У человека же мозг в среднем весит 1.3 кг, при этом именно человек является венцом эволюции. Эти цифры наглядно демонстрируют, что дело не в количестве, а в качестве, так сказать.

Но что, если мозг существа весит всего лишь около 0.065 грамм и состоит из 950 000 нейронов (для сравнения, у человека их порядка 100 миллиардов)? Сможет ли такое существо показать интеллектуальные способности, способные удивить ученых? Еще как сможет, и этим существом является медоносная пчела, которая дружит с арифметикой. Сегодня мы с вами ознакомимся с исследованием математических способностей пчел, открывающее новые сведения для понимания их индивидуального, а не коллективного интеллекта. Помимо этого ученые стали лучше понимать соотношения веса и структуры мозга с уровнем интеллекта. Как ученые заставили пчел считать без калькулятора, как хорошо справились пчелы с поставленной задачей, и что ученым удалось выяснить? Ответы найдем в докладе исследовательской группы. Поехали.

Привет, Хабр! Представляю вашему вниманию перевод статьи «Dynamic Local Exposure» автора John Chapman.


В данной статье я представлю пару идей о динамической локальной экспозиции в HDR рендеринге. У Барта Вронски уже есть отличная статья на эту тему и я очень рекомендую ее прочитать прямо сейчас, если вы еще этого не сделали; идеи здесь, в большей степени, основаны на его статье. В конце я включил несколько других замечательных ссылок.

Low/High Dynamic Range

В старые добрые времена (1990-е) игры рендерились непосредственно в отображаемом LDR (узкий динамический диапазон) формате (гамма пространство, 8 бит). Это было просто и дешево, но, с другой стороны, значительно мешало созданию действительно фотореалистичной картинки.

В настоящее время, особенно с появлением PBR (physically-based rendering), игры рендерятся с гигантским динамическим диапазоном в линейном пространстве с более высокой точностью. С таким движением к фотореализму приходит реальная проблема: как мы можем отобразить HDR изображение в LDR?

Привет, Хабр!

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

Как устроен баркод, и что закодировано на этой картинке?



Попробуем разобраться, заодно напишем декодер таких кодов.

Привет, Хабр! Представляю вашему вниманию перевод статьи «Pseudo Lens Flare» автора John Chapman.



Lens flare (блики на линзах) ― это фотографический артефакт, возникающий при рассеивании и преломлении света в системе линз. Хотя он является артефактом, существует множество поводов использовать lens flare в компьютерной графике:

• он увеличивает воспринимаемую яркость и видимый динамический диапазон изображения.
• lens flare часто встречается на фотографиях, поэтому его отсутствие может бросаться в глаза
• он может играть важную роль в стилистике или драматизме, или может быть частью геймплея в играх (представьте блики, ослепляющие игрока)

Традиционно lens flare в realtime реализовывался с помощью технологий, основанных на спрайтах. Хотя спрайты дают легко контролируемые и очень реалистичные результаты, они должны быть размещены явно и требуют данные окклюзии для корректного отображения. Здесь я опишу простой и относительно дешевый screen space эффект, который создает псевдо lens flare из входного color buffer. Он не основан на физике, поэтому результат немного отличается от фотореалистичного, но его можно использовать в комбинации с (или как замену) традиционными sprite-based эффектами.

Введение

На Habr математическое описание работы фильтра Калмана и особенности его применения рассматривались в следующих публикациях [1÷10]. В публикации [2] в простой и доходчивой форме рассмотрен алгоритм работы фильтра Калмана (ФК) в модели «пространства состояний», Следует отметить, что исследование систем контроля и управления во временной области с помощью переменных состояния широко используется в последнее время благодаря простоте проведения анализа [11].

Публикация [8] представляет значительный интерес именно для обучения. Очень эффективен методический приём автора, который начал свою статью с рассмотрения распределения случайной погрешности Гаусса, рассмотрел алгоритм ФК и закончил простой итерационной формулой для подбора коэффициента усиления ФК. Автор ограничился рассмотрением распределения Гаусса мотивируя это тем, что при достаточно больших $$ (многократных измерений) закон распределения суммы случайных величин стремится к распределению Гаусса.

Теоретически такое утверждение, безусловно, справедливо, однако на практике число измерений в каждой точке диапазона не может быть очень большим. Сам R. E. Kalman получил результаты о минимуме ковариации фильтра на базе ортогональных проекций, без предположения о гауссовости ошибок измерений [12].

Целью настоящей публикации является исследование возможностей фильтра Калмана для минимизации энтропийного значения случайной погрешности с не Гауссовым распределением.
Для оценки эффективности фильтра Калмана при идентификации закона распределения или суперпозицией законов по экспериментальным данным воспользуемся информационная теорией измерений основанной на теории информации К. Шеннона, согласно которой информация, подобно физической величине, может быть измерена и оценена.

Анализатор: Slither
Описание: Open-source static analysis framework for Solidity
githib: https://github.com/trailofbits/slither

Это статический анализатор кода, написанный на python. Он умеет следить за переменными, вызовами, и детектирует вот такой список уязвимостей. У каждой уязвимости есть ссылка с описанием, и, если вы новичок в Solidity, вам имеет смысл ознакомиться со всеми.

Slither может работать, как модуль python и предоставлять программисту интерфейс, для аудита по собственному плану. Простой и показательный пример того, что умеет делать slither можно увидеть тут.

Мы еще вернемся к сценариям анализа в конце статьи, а пока запустим Slither:

Введение

Наша компания занимается аудитом безопасности смарт-контрактов, и вопрос использования автоматических средств стоит очень остро. Насколько сильно они могут помочь в определении подозрительных мест, какие стоит их использовать, что они умеют делать и какова специфика работы в этой области? Эти и сопутствующие вопросы — тема данной статьи. А материалом будут попытки поработать с реальными контрактами с помощью наиболее интересных представителей и рецепты по запуску этого крайне разношерстного и дико интересного софта. Сначала хотелось сделать одну статью, но после некоторого времени объем информации стал слишком большим, поэтому было решено сделать цикл статей, по одной на каждый автоанализатор. Список, из которого мы будем брать инструменты представлен, например, здесь, но, если за время написания попадутся другие интересные инструменты, я с удовольствием их опишу и протестирую.

GDPR (или «Регламент») содержит несколько оснований для обработки персональных данных. Эти основания можно условно разделить на две большие группы. Это обработка на основании личного согласия носителя (владельца) персональных данных, и обработка на иных основаниях. В данной статье рассматриваются условия правильного оформления согласия на обработку персональных данных, и не затрагиваются особенности обработки по иным основаниям.

Статья представляет собой краткую выжимку и мою интерпретацию Руководства по согласию в соответствии с Регламентом 2016/679 (Guidelines on consent under Regulation 2016/679) («Руководство») и некоторых документов, на которые есть ссылки в Руководстве.

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

Этот документ разделён на пять частей:

1. Как звук влияет на производительность
2. Разбираемся с параметрами импорта
3. Рекомендуемые мной параметры для PC и консолей
4. Рекомендуемые мной параметры для мобильных платформ
5. Предостережения и замечания

Оптимизация параметров импорта звука Unity — один из простейших способов оптимизации. В случае небольшого проекта у вас может уйти меньше часа для достижения значительных улучшений во времени загрузки, занятой ОЗУ и других аспектах производительности. Надеюсь, это руководство окажется полезным для вас. Информация актуальна для Unity версии 2018.3

Буду краток, причина оказалась в непостоянстве частоты GPU (больше), и CPU(меньше). Используя MSI Afterburner, HWiNFO64, и RivaTuner экспериментальным путем я выяснил что пропуски кадров происходят из-за достижения powerlimit в gpu и pl4 limit в cpu. Лимиты есть и всегда будут. Даже если убрать лимиты для мощности и тока, упремся в температурный лимит, который ещё более наглый чем предыдущие, тк изменяет частоту более резкими скачками. Но есть решение. Прошу под кат.

От переводчика:

Это продолжение серии переводов туториалов от Twinklebear, в оригинале доступных тут. Перевод отчасти вольный и может содержать незначительные поправки или дополнения от переводчика. Перевод первых двух уроков — за авторством InvalidPointer, 5 и 6 перевёл AndrewChe. Рисунки из оригинальной статьи локализованы с максимальным сохранением стиля автора.

_{На фото — первый летающий четырёхколёсный велосипед. Источник.}

Сегодня, благодаря доступности нужных сервисов, размещение видео в сети не является сложной задачей. Однако материалов по внутреннему устройству подобных систем не так уж и много, особенно в русскоязычном сегменте.

Я в течение некоторого времени занимался проектированием и разработкой качественной видео-платформы. В этой статье я хочу описать те моменты, которые сам бы хотел знать в начале разработки.

Статья не претендует на статус руководства, в ней я постараюсь описать только интересные или неочевидные моменты, затрагивающие обработку и доставку видео-контента на базе HTML5.
Материал рассчитан на тех, кто уже в теме, либо готов искать расшифровку аббревиатур, терминов и понятий.

Вторая часть.

^{Одно из изданий этой механики}

Есть колода из 100 карт с натуральными числами от 1 до 100, каждого по одному. Вы и второй игрок берёте по 3 карты из этой колоды. Задача — одну за одной выложить их на стол в порядке возрастания. Но нельзя меняться информацией между собой и показывать карту до момента, пока она не будет положена на стол. То есть нельзя говорить, стучать по столу, подмигивать и так далее — ничего нельзя.

Если в конце игры 6 карт выложены правильно, оба игрока выигрывают. В момент, когда первая же карта ложится неправильно — оба игрока проигрывают.

Ваша задача — выиграть в этой игре. С вами играет человек, которого вы до этого не видели. Возможно, он даже не говорит на известных вам языках. Но он точно землянин. И он с большой вероятностью уже пробовал играть в эту игру с другими людьми сегодня. Какова ваша стратегия?

Не спешите под кат, сначала подумайте чуть-чуть, пожалуйста.

Этот рассказ стоит начать с одной интересной истории…

У некой маленькой фирмы был совсем небольшой офис, состоящий из коридора, кухни с кофемашиной, переговорной, кабинета директора и открытого рабочего пространства (open space).

Сотрудники в качестве рабочего компьютера получали корпоративные ноутбуки. И был замечен тот странный факт, что люди, которые приходили на работу вовремя, имели перебои со связью, а те, кто опаздывал, таких проблем не замечали. Прямо мистика какая-то.

В один прекрасный момент, в ходе разработки игры, я столкнулся с вопросом производительности на современных ПК. У нашего моделлера достаточно мощный современный компьютер красной сборки. Но у него наш проект жутко тормозил, загружая одно ядро процессора.

Причина проста — в новых процессорах много ядер, но по факту они менее производительны в однопоточных приложениях. На тот момент, у меня был рендер в один поток. Но на самом деле причины была не столько в этом. И в процессе поиска проблемы, я решил посчитать сколько полигонов присутствует в сцене:



На средней игровой карте, при максимальном отдалении и при большом скоплении пальм — 15 824 756 треугольников! Почти 16 миллионов! Огромная цифра.

Поскольку праздники кончились, предлагаю вашему вниманию субъективную подборку ржавых новостей за декабрь. В этой подборке: безумие с растом, страшен ли раст, волна пророчеств, Rust 2018, Rust Analyzer.

Rust 1.31 & Rust 2018

Самое важное событие декабря — выпуск Rust 1.31 и Rust 2018, конечно. Туда очень много всего вошло:

редакция 2018, нелексические времена жизни, изменения системы модулей, дополнительные правила вывода времен жизни, const fn, новые инструменты, инструментальные проверки качества кода, документация, новый веб-сайт, улучшения в cargo.

Изменений так много, что обзор всех не получилось запихнуть в один пост, так что через несколько дней были опубликованы вспомогательные заметки:

• Procedural Macros in Rust 2018 (обсуждение) — о процедурных макросах;
• Tools in the 2018 edition (обсуждение) — о расширении инструментария;

Также, имеет смысл полистать мозиловский хорошо структурированный обзор/ликбез 2018й редакции языка: Rust 2018 is here… but what is it? (перевод, обсуждение).