Pull to refresh
350
0
Коробов Михаил @kmike

Пользователь

Send message
С недавнего времени все эти платформы нормализуют не по пикам, а по LUFS, в том-то все и дело.
Компрессию при мастеринге использовали, чтоб поднять воспринимаемую громкость трека, по отношению к другим трекам. Ну грубо говоря — динамический диапазон сужаешь, тихие звуки становятся громче, трек вцелом воспринимается громче. См. еще en.wikipedia.org/wiki/Loudness_war

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

Понятное дело, компрессор все еще используют, как средство художественной выразительности, в основном при сведении (т.е. жмут отдельные инструменты, а не трек целиком). В этом ничего плохого нет.
За последние десятилетия в звукозаписи стали очень часто использовать простой и очень эффективный прием ー усиление громкости с помощью компрессии, то есть снижения разницы между самыми громкими и самыми тихими звуками. Этот метод позволяет дольше удержать внимание слушателя, но всю композицию делает менее выразительной. Барабанные партии меньше выделяются, а разница тембров сглаживается.

Это немного мимо. Тренд на такую компрессию появился в 80х с CD дисками, и недавно умер из-за развития стриминговых платформ.

Сейчас музыкальная индустрия ориентируется почти полностью на Spotify, Apple Music, Youtube и т.д. — и там в подобной компрессии нет никакого смысла, т.к. эти сервисы выравнивают громкость песен сами, чтоб воспринимаемая громкость треков не скакала между песнями, и делают это не просто по пиковой громкости трека. Поэтому компрессия при мастеринге больше не делает трек громче.

См. www.youtube.com/watch?v=EiRMYoqU3ys.
А глазами ошибки-противоречия между разными подходами не смотрели? Просто cld2 — библиотека от гугла, и размеченные данные — автоматическая разметка от гугла. Даже если там подходы разные, тренировочные данные могут быть похожие, какие-то решения могут быть похожие и т.д., короче, смещение можно словить, одинаковые ошибки.
Это зависит от алгоритма. В Perl, Python, Ruby, Java и т.д. регекс вида (term1|term2|term3|...term4) работает как раз за O(N) от количества термов, т.к. там NFA строится. Чтоб это работало за O(1) от количества термов, нужно строить DFA — например, это делает библиотека re2 (можно и из питона использовать), и дефолтные движки регэкспов в Go и Rust.
Насчет решения с CRF на github.com/kmike/dialog2017 — это такой скучный baseline, что сабмитить-то стыдно было) Берем все теги, извлекаем кое-какие фичи, пихаем в CRF. Я изначально хотел другой подход попробовать (через какой-нибудь DAGGER, чтоб структура тегов учитывалась — не просто 300 one-hot закодированных было, + назад больше 1 шага смотреть можно, красиво можно сделать), но в итоге времени не нашел — пару бейзлайнов сделал, чтоб было, с чем сравнивать, потом на преобразование тегов между форматами кучу времени потратил, а потом уже приоритеты поменялись.
Насколько знаю, внутри portia — библиотечка https://github.com/scrapy/scrapely. Ну т.е. там еще куча всего есть, но вроде дефолтное извлечение выполняется именно через scrapely. Это и есть алгоритм парсинга.
У меня тоже так бывает, сообщение это вылезает. Адблокер включен, да. Но я при этом еще и в яндекс аккаунт залогинен, т.е. по-хорошему меня уже определили.
pep-505 не факт, что примут, Гвидо не решил ничего)
А как тестируете? Вижу пару тест-кейсов тут ( github.com/lexborisov/myhtml/tree/master/test/html ) — это все или еще что-то есть? Страшно как-то парсер почти без тестов использовать :) html5ever и gumbo, например, github.com/html5lib/html5lib-tests используют.
В tqdm поддержку IPython тоже добавят, думаю — см. github.com/tqdm/tqdm/pull/92. Идеи черпают из github.com/aplavin/ipy-progressbar и github.com/flying-sheep/smart-progress.
Backpropogation — это алгоритм вычисления производной. Причем, если не ошибаюсь, в Tensorflow (как и в Theano) он не используется, т.к. производные вычисляются символьно, а не численно. Производные (градиенты) нужны алгоритмам оптимизации — градиентному спуску, например. Обычный градиентный спуск почти не используется, применяют обычно SGD, всякие его модификации с моментами, отдельными learning rate для каждого параметра и т.д.
Небольшое замечание: AUC — это «Area under curve», сама по себе это не метрика, т.к. «curve» бывают разные. Популярные варианты — ROC-AUC и PR-AUC. Хотя по примеру и так все ясно, все равно лучше явно указывать, какая метрика используется.
В gensim своя реализация word2vec, там не используется код из оригинальной библиотеки. Поэтому, чтоб не плодить велосипеды и не реализовывать еще и k-means, кластеризации в gensim нет. Она там и не нужна, раз можно взять готовую проверенную реализацию из scikit-learn.
Ну недостаток в том, что если у функции 0 аргументов, то не понятно, результат — это вызов функции или сама функция как объект.

Другой недостаток: если один из аргументов — вычисляемый («sin x»), то нужно думать о приоритете операций + непонятно, мы передаем два значения (объект функции sin и переменную x) или результат вызова sin(x).

Т.е. разрешать этот синтаксис разумно только в каких-то особых случаях (1 аргумент, аргументами не могут быть объекты функций?) — но все эти «если .., то код значит вот то, но если .., то код значит вот это» усложняют язык. Проще уж использовать скобки. Ну по крайней мере с точки зрения сектанта-питонщика.
А зачем было EXIF записывать к превьюшке? Я так понял, на это ушло 90% времени, и про это ничего в ТЗ не было.
А какой алгоритм парсинга используется, какие грамматики поддерживаются — LL(?), LR(?), любые контекстно-свободные, ...? Есть ли какие-то «хорошие» ограничения на сложность разбора — например, O(N) для некоторых однозначных и не больше чем O(N^3) для любых (хотя из-за атрибутов это может быть сложно..)? Можно ли парсить «снизу вверх», а не «сверху вниз», не требуя обязательного сопоставления стартовому символу, извлекая все поддеревья за один проход?

Ну и интересно, какая скорость морф. анализа по словарю получилась :)

Насчет упаковки данных в автомат есть простой способ — автомат строить библиотекой code.google.com/p/dawgdic (для кого-то может быть проще использовать питонью обертку github.com/kmike/DAWG), а потом написать читалку для полученного формата на Go. Там алгоритм построения автомата сложный, а вот сама читалка — довольно простая, портировать на Go должно быть нетрудно.
Видимо, git окончательно победил mercurial. Баг был обнаружен сначала в mercurial, потом авторы mercurial нашли этот баг в git. Теперь в новостях везде «баг в git»; тут, например, даже упоминания hg нет.
Если коротко, то имея огромную кучу текстов, можно прикинуть с какой вероятностью каждое слово употребляется с другим словом. Это очень грубое объяснение, но оно, как мне кажется, точно отражает суть. В результате получается строить более-менее приличные переводы (привет Google Translate). Этот подход не приближает нас к пониманию текста, а лишь пытается найти похожие предложения и на их базе построить перевод.

Языковые модели не могут провести семантический анализ текста. Они избегают понимания текста на этапе синтаксического анализа. Модель языка может помочь разбить текст на предложения, провести извлечение сущностей (NER), feeling extraction. Тем не менее модель не может определить смысл текста, к примеру, не сможет составить приемлемое резюме текста.


Определение языковой модели было правильное: это P(words) и ничего более — даешь на вход набор токенов, получаешь его вероятность в данном языке. А вот дальше какая-то каша начинается. Перевод с помощью одних только языковых моделей не сделаешь (языковые модели там используются, чтобы выбирать более-менее человеческие предложения); не встречал, чтобы для задач NER или анализа тональности как-то языковые модели применялись, да и для токенизации тоже. Неправильно все статистические методы «языковой моделью» называть.

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

Вы, по сути, решаете другую задачу — не задачу разбиения текста на предложения, а задачу нахождения символов, которые могут использоваться для разбиения текста на предложения в данном наборе текстов. Т.е. вы можете найти, что "¸" выполняет функцию точки, но не можете определить, является ли этот символ концом предложения в данном конкретном случае — например, «Бондаренко Н. В.» — первая точка — не разделитель, вторая — возможно, разделитель. Так? Все делилки текста на предложения решают именно эту задачу, а не вашу. Это не значит, что они плохие. Это также не значит, что то, что вы делаете — бессмысленно (иногда задача определения набора разделителей и правда может стоять). Но это другая задача. «Традиционная» задача сегментации выглядит сложнее и полезнее.

Есть методы языко-независимого построения делилок текста на предложения — см., например, Punkt; реализация в NLTK, например, доступна. Идея Punkt в том, чтоб по набору «сырых» текстов определить аббривеатуры / сокращения, характерные для языка, т.к. для большинства практических задач именно это является главной сложностью, а не то, что набор возможных разделителей неизвестен. Правда, не сказал бы, что работает очень уж хорошо.

привязанность к кодировке

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

А это значит, что для понимания сообщения на каком-либо языке нам не нужно ничего, кроме самого сообщения. При условии, что это сообщение достаточно большое. Именно эта идея и положена в основу библиотеки под названием AIF. За деталями прошу пожаловать под кат.

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

Дальше субъективно, обратная связь, как AIF2 выглядит со стороны. Сразу скажу — я не знаю, соответствует ли впечатление тому, что на самом деле. Но все же. Звучит «понимание» больно уж рекламно, причем рекламность рассчитана на людей, не имеющих знаний в области NLP. Библиотека, как я понял, пока умеет только находить возможные разделители слов и предложений для данного набора текстов по какому-то неописанному алгоритму (совет — в документации и вики описывать алгоритмы, а не детали установки java-пакетов). Что в некоторых синтетических специально подобранных примерах позволяет разбить текст на предложения лучше, чем это делают существующие делилки текста на предложения. Авторы используют термин «языковая модель» странным образом и не ссылаются на существующие unsupervised алгоритмы разбиения текста на предложения (обычно это знак того, что о них и не знают). Куча громких слов про семантику и понимание текста, про то, как все сейчас плохо, но никаких результатов, одни намерения. Ну и вербовка под все это дело новичков в NLP (которые под сомнение подходы ставить не будут?). Еще раз повторюсь — я без понятия, так ли все это на самом деле; код я не читал, в деталях не разбирался, но просто так это выглядит.

Information

Rating
Does not participate
Location
Екатеринбург, Свердловская обл., Россия
Works in
Date of birth
Registered
Activity