Damn Small Blog: декабря 2019

Яндекс.Музыка vs Deezer

Yet another субъективный сравнительный обзор музыкальных стриминговых сервисов.

Блюдя тематику (GNU/Linux) блога сравнивались только мобильные приложения для Android и десктопные web-интерфейсы.

В сравнении не участвует Spotify из-за своей скорости принятия корпоративных решений, потому что он уже более пяти лет скоро-скоро запустится в России. Также не участвуют сервисы Google из-за вечного бардака. Не понятно, на какой сервис можно положиться (Google Play Music/YouTube Music), какой выживет, а какой будет закопан, как были закопаны Picasa, Блокнот, Google Reader и так далее.

Параметр для сравнения	Яндекс.Музыка	Deezer
Синхронизация текущего списка воспроизведения	Главный провал Яндекса: перейдя с одного устройства на другое, приходится заново искать то, что только что играло UPD от февраля 2020 г.: Яндекс выкатил таки функцию под названием «Музыка продолжается»	В Deezer действительно можно прийти домой и одним кликом запустить на ПК то, что только играло в наушниках на телефоне. Причем возможность эта отключается в настройках.
Поиск	Поиск у Яндекса лучше, даже по иностранной музыке	Поиск уступает Яндексу
Присутствие альбомов	Явно больше альбомов русских исполнителей. Из зарубежных исполнителей по сравнению с Deezer не удалось найти (понятно, что выборка очень субъективна) только пару альбомов каверов.	Немного меньше русской музыки. Что хуже: иногда неправильно проставлены даты выходов альбомов русских исполнителей, кажется вместо дат выходов указаны даты добавления в каталог (лейбла/самого Deezerа/...)
Гибкость рекомендаций	У Яндекса всегда под рукой радио по исполнителю, альбому (чего у Deezer нет), треку, субъективно разнообразней тематические подборки	Миксы только по исполнителю и отдельному треку
Качество	Mp3 320 kb/s	Mp3 320 kb/s на обычных подписках и flac на подписке HiFi за отдельную плату
Интерфейс Андроид-приложения	Отличный	Субъективно приложение для Андроид выглядит неаккуратным
Web-интерфейс	Не идеальный, очередь воспроизведения не под рукой	Отличный в целом, явно указывается качество в kb/s
Запуск/остановка воспроизведения медиаклавишей клавиатуры	~~Запуск воспроизведения работает раз через три~~ UPD от марта 2020 г.: Яндекс таки починил прошлогодний баг — теперь все ОК	Просто работает
Дополнительные плюшки подписки	Скидки на различные сервисы Яндекса	Доп. плюшек нет
Семейная подписка	Дороже (299 руб.), меньшее количество человек (4)	Дешевле (255 руб.), большее количество человек (6), но есть и минус — на семью единый аккаунт с единым логином-паролем с шестью профилями, т.е. подписку получится делить лишь между людьми, которым вы полностью доверяете (действительно подписка именно семейная)
Цена индивидуальной версии	169₽/месяц, 1690₽/год, но есть акционные варианты за 99₽/месяц и 990₽/год	169₽/месяц, 1690₽/год

Экспресс-разбор данных от input-устройства клавиатуры

0 коммент.

Устройство клавиатуры можно найти по имени в каталоге "/dev/input/by-id/". Возможно, нужно будет сменить владельца на текущего пользователя:

sudo chown user:user /dev/input/by-id/usb-Logitech_USB_Keyboard-event-kbd

Далее для снятия дампа в hex-виде предлагаю такую замысловатую команду:

sleep 1 ; hexdump -e '24/1 " %02X" "\n"' /dev/input/by-id/usb-Logitech_USB_Keyboard-event-kbd /dev/input/by-id/usb-Logitech_USB_Keyboard-event-kbd & sleep 5 ; pkill hexdump

Здесь через 1 секунду (sleep 1, чтобы нажатие Enter не попало в дамп) начнется захват данных с клавиатуры, будет выводиться по 24 байта на строку (24/1), еще через 5 секунд (sleep 5) захват будет остановлен (pkill hexdump, чтобы мы смогли вновь пользоваться клавиатурой после снятия дампа).

Пример вывода, где пару раз была нажата кнопка F1:

sleep 1 ; hexdump -e '24/1 " %02X" "\n"' /dev/input/by-id/usb-Logitech_USB_Keyboard-event-kbd /dev/input/by-id/usb-Logitech_USB_Keyboard-event-kbd & sleep 5 ; pkill hexdump
[1] 14693
 15 87 FC 5D 00 00 00 00 40 CA 07 00 00 00 00 00 04 00 04 00 3A 00 07 00
 15 87 FC 5D 00 00 00 00 40 CA 07 00 00 00 00 00 01 00 3B 00 01 00 00 00
 15 87 FC 5D 00 00 00 00 40 CA 07 00 00 00 00 00 00 00 00 00 00 00 00 00
 15 87 FC 5D 00 00 00 00 3E C4 08 00 00 00 00 00 04 00 04 00 3A 00 07 00
 15 87 FC 5D 00 00 00 00 3E C4 08 00 00 00 00 00 01 00 3B 00 00 00 00 00
 15 87 FC 5D 00 00 00 00 3E C4 08 00 00 00 00 00 00 00 00 00 00 00 00 00
 16 87 FC 5D 00 00 00 00 37 C4 08 00 00 00 00 00 04 00 04 00 3A 00 07 00
 16 87 FC 5D 00 00 00 00 37 C4 08 00 00 00 00 00 01 00 3B 00 01 00 00 00
 16 87 FC 5D 00 00 00 00 37 C4 08 00 00 00 00 00 00 00 00 00 00 00 00 00
 16 87 FC 5D 00 00 00 00 75 60 09 00 00 00 00 00 04 00 04 00 3A 00 07 00
 16 87 FC 5D 00 00 00 00 75 60 09 00 00 00 00 00 01 00 3B 00 00 00 00 00
 16 87 FC 5D 00 00 00 00 75 60 09 00 00 00 00 00 00 00 00 00 00 00 00 00

Input-устройства выдают данные пакетами. Каждый пакет — структура input_event:

struct input_event {
 struct timeval time;
 __u16 type;
 __u16 code;
 __s32 value;
};

Структура имеет размер 24 байта (на 64-битной системе), именно поэтому выше мы выводили дамп по 24 байта на строку.

Первое поле структуры input_event — также структура, timeval. Использовалась 64-битная система, поэтому timeval состояла из двух 64-битных (по 8 байт) целых чисел — значения секунд и микросекунд. По первым 8 байтам каждой строки дампа видно, как меняется значение секунд (почти не меняется, только первый байт поменялся с 15 на 16, когда секунда "тикнула"). Следующие 8 байт каждой строки отвечают за микросекунды, а потому меняются хаотично (нажатие/отпускание кнопки F1 приходилось на произвольную долю секунд).

А самое интересное происходит в последних восьми байтах каждой строки дампа. Сначала идет двухбайтное поле type — его значение менялось с 4 (EV_MSC — некая дополнительная информация, разбирать ее не будем) на 1 (EV_KEY — непосредственно событие кнопки клавиатуры) и 0 (EV_SYN — разделитель).

Разберем события EV_KEY, их было всего 4:

 15 87 FC 5D 00 00 00 00 40 CA 07 00 00 00 00 00 01 00 3B 00 01 00 00 00
 15 87 FC 5D 00 00 00 00 3E C4 08 00 00 00 00 00 01 00 3B 00 00 00 00 00
 16 87 FC 5D 00 00 00 00 37 C4 08 00 00 00 00 00 01 00 3B 00 01 00 00 00
 16 87 FC 5D 00 00 00 00 75 60 09 00 00 00 00 00 01 00 3B 00 00 00 00 00

За полем event следует также двухбайтное поле code — код клавиши. В нашем случае — 3B в hex или 59 в десятичном виде. Смотрим файл input-event-codes.h. Действительно, 59 — это код клавиши F1.

И, наконец, последнее поле — четырехбайтное value. Здесь все просто: значение 1 соответствовало нажатию клавиши F1, значение 0 — отпусканию.

Главная страница