Свій плеєр для улюбленої музики: що створив Myron 2402
Пісня вже грає, але текст запізнюється. Японський приспів хочеться підспівати, а прочитати його складно. Переклад є, та рядки не збігаються з оригіналом. LRC Open Player об’єднує рішення цих задач в одному музичному плеєрі — і його автор є учасником нашої спільноти.
Автор, про якого розповідає його проєкт
У Telegram автор представляється як Myron 2402 (@myron2402), а на GitHub працює під ніком Myron4iktop. Він поділився LRC Open Player у нашому чаті. У репозиторії є код Windows-плеєра, Android-застосунку LRC Companion, інструкції зі збирання та перелік використаних бібліотек.
Це розбір опублікованого проєкту, а не інтерв’ю. Ми не знаємо, скільки часу зайняла розробка, яким був попередній досвід автора і чи допомагав йому конкретний AI-асистент. Тому «як зроблено» тут означає архітектуру, яку можна побачити в коді. Приписувати автору історію про «один вечір із Claude» без його слів було б неправильно.
Навіщо ще один музичний плеєр?
Найцікавіше тут — вузький фокус. LRC Open Player працює з власними аудіофайлами й ставить у центр текст пісні: знайти, прочитати, синхронізувати, доповнити перекладом. Це не підписка на музичний каталог.
LRC — це текст із позначками часу. Наприклад, запис [00:42.50] означає момент 42,5 секунди. Плеєр зіставляє такі позначки з позицією відтворення та виділяє потрібний рядок. Виходить знайомий ефект караоке, але поверх вашої локальної колекції.
У проєкті передбачено кілька джерел тексту: окремий файл .lrc поруч із піснею, дані всередині аудіофайлу та пошук через LRCLIB. Якщо синхронізації немає, її можна створити: увімкнути пісню й натискати Enter на початку кожного рядка.
Окрема особливість — японські тексти. Програма може показати їх латинкою, тобто ромадзі, а нижче — переклад. Це допомагає стежити за звучанням; сама транслітерація не є перекладом і не гарантує ідеальної вимови.
Як це влаштовано: два застосунки з різними ролями
Windows: слухати й синхронізувати
Python і PyQt6 формують інтерфейс. Qt Multimedia відповідає за відтворення, Mutagen — за метадані, Cutlet та японський словник — за ромадзі. Інтеграція з Windows додає мультимедійні клавіші та керування на екрані блокування.
Android: підготувати колекцію
Kotlin і Jetpack Compose — основа LRC Companion. Застосунок редагує назви, виконавців, обкладинки й тексти, шукає збіги в LRCLIB та зберігає LRC. Для японського тексту використовується Kuromoji.
Зв’язок між цими частинами простий: звичайні музичні файли, їхні метадані та LRC. У README немає обіцянки автоматичної хмарної синхронізації між телефоном і ПК. Перенесення файлів залишається окремою дією користувача.
Автор не писав аудіодекодер або японський словник з нуля. Він поєднав готові відкриті бібліотеки навколо конкретного сценарію. Для власного невеликого продукту це практичний підхід: основну увагу можна приділити тому, як людина користується програмою.
ШІ тут виконує маленьку, але доречну роботу
Уявімо: в оригіналі два короткі рядки, а перекладач об’єднав їх в одне речення. Просте зіставлення «перший із першим, другий із другим» уже не працює.
Необов’язковий AI-режим допомагає визначити, які рядки перекладу відповідають рядкам оригіналу. За описом і логікою проєкту модель має зіставляти їхні номери, а не вигадувати новий переклад. Перед збереженням людина переглядає результат.
- Локальний варіант: сервер із сумісним з OpenAI API, наприклад LM Studio, Ollama або llama.cpp. Модель і сервер потрібно налаштувати окремо.
- Хмарний варіант: OpenRouter із власним API-ключем. Використання оплачується за умовами обраного сервісу й моделі.
- Без ШІ: ручне зіставлення залишається доступним; AI-функція не є умовою прослуховування музики.
Це показовий приклад обмеженої ролі ШІ в продукті: одна задача, зрозумілі вхідні дані й перевірка людиною. Більше про різницю між локальною програмою та локальною моделлю — у нашому FAQ про локальний ШІ.
Що в коді цікавіше за список можливостей
Редагування через копію. Windows-функція запису текстів у метадані спочатку створює копію аудіофайлу, змінює її та перевіряє, чи бібліотека може прочитати результат. Лише після цього підміняє оригінал. Це зменшує ризик часткового запису, хоча не замінює резервної копії колекції й не перевіряє звучання всього треку.
Робота у фоні. У настільному коді є окремі задачі для мережевих запитів і тривалих операцій. Передбачено й перевірку запізнілої відповіді пошуку тексту: результат старої пісні не має підмінити текст уже нового треку.
Доступ до обраної папки на Android. LRC Companion використовує системний механізм вибору файлів і папок. Це відповідає його задачі: працювати з колекцією, яку відкрив користувач.
Чи це вірус? Чесна відповідь після статичної перевірки
Назвати програму «точно безпечною» за одним читанням коду не можна. Ми провели статичну перевірку відкритої версії d2f98b0: переглянули README, головний Python-файл, Android Manifest, Gradle-конфігурацію та перелік залежностей. Готовий EXE чи APK не запускали, мережевий трафік не перехоплювали, усі бібліотеки й ланцюг збирання не аудіювали.
| Що перевірено | Що видно у коді | Практичний висновок |
|---|---|---|
| Мережа | Windows-код звертається до LRCLIB для пошуку текстів. AI-режим окремо може звертатися до вибраного локального OpenAI-сумісного сервера або OpenRouter. У головному Python-файлі ми не знайшли викликів subprocess, os.system чи eval. | Плеєр не повністю офлайн, коли ввімкнено пошук текстів або хмарний AI. Це не підтвердження всієї фактичної мережевої поведінки залежностей. |
| Дозволи Android | Manifest оголошує лише INTERNET. Камера, мікрофон, контакти й широкий доступ до сховища не запитуються; папку користувач обирає через системний механізм. | Набір явних дозволів вузький, але сам по собі не гарантує відсутності помилок або ризиків у коді. |
| API-ключ | У Windows передбачено захист через DPAPI для поточного користувача. Якщо шифрування недоступне, код може зберегти сумісне старе значення відкритим текстом. | Починайте без ключа; для OpenRouter використовуйте окремий ключ із мінімальним лімітом і не переносіть файл налаштувань іншим людям. |
| Залежності й збірка | Лише PyQt6 має мінімальну версію; частина Python-пакетів не зафіксована точно. Android release-конфігурація підписується debug-ключем. | Відтворюваність збірки ще треба посилити: зафіксувати версії та налаштувати окремий release-підпис. |
| Готові файли | На момент перевірки у GitHub Releases не було опублікованого релізу, хешів EXE/APK або підписаних артефактів. | Неможливо підтвердити походження стороннього інсталятора. Найпрозоріший шлях зараз — збирати саме зафіксований код. |
Як спробувати безпечніше й кому це буде цікаво
Проєкт вартий уваги, якщо ви зберігаєте музику локально, любите підспівувати японським пісням або хочете самі виправляти тексти й таймінги. Якщо потрібен лише каталог стримінгового сервісу, він вирішує іншу задачу.
За README, для запуску настільної версії потрібні Windows і Python 3.11 або новіший. Після завантаження вихідного коду й переходу в папку проєкту:
cd desktop
pip install -r requirements.txt
python lrcplayer.py- Завантажте зафіксовану версію. Для повторення нашої перевірки використовуйте commit
d2f98b0, а не випадковий архів із чату чи файлового обмінника. - Створіть окреме середовище. Встановлюйте Python-залежності у
venv; перед установленням перегляньтеrequirements.txt. - Візьміть тестові копії. Перший запис метаданих і LRC перевіряйте не на єдиній музичній колекції, а на копіях кількох файлів.
- Почніть без API-ключа. Прослуховування й ручна синхронізація не потребують хмарного AI. OpenRouter підключайте лише після ознайомлення з його умовами й витратами.
- Перевірте мережу й артефакт. За потреби контролюйте з’єднання системним брандмауером. Якщо з’явиться готовий реліз — звіряйте джерело, підпис і опублікований автором хеш.
Android-частина збирається в Android Studio; детальні кроки є в інструкції за перевіреним commit. Поки окремого підписаного релізу немає, збірка з вихідного коду прозоріша за невідомий APK.
Код опубліковано під GPLv3. Автор дозволяє вивчати й змінювати програму; поширення похідних версій має відповідати умовам ліцензії. Для власного відгалуження README просить використовувати іншу назву та іконку.
Чому цей проєкт доречний у нашій спільноті
У LRC Open Player є конкретний сценарій, який легко пояснити без великих обіцянок: увімкнути власну пісню, побачити слова й привести переклад до ладу. Від цього сценарію простежується шлях до бібліотек, файлових форматів, інтерфейсу й окремої AI-функції.
Для тих, хто планує свій перший застосунок, тут корисний принцип: оберіть невелику незручність і доведіть її рішення до зрозумілого користувачеві результату. А відкритий код дозволяє подивитися не тільки на задум, а й на те, як він реалізований.
Джерела й авторство
Матеріал підготувала редакція Вайб-Кодингу за відкритим репозиторієм. Автор програмного проєкту — Myron 2402 (Myron4iktop на GitHub). Технічні твердження прив’язані до переглянутої версії; актуальний код може змінюватися.
Ще один проєкт нашої спільноти — Origami Notes від BaraniukConnection: Android-нотатник із папками, списками та віджетами.
Створюєш щось своє? Покажи спільноті
Ділися проєктом, розповідай, яку задачу він вирішує, і збирай предметний зворотний зв’язок. Інші роботи учасників — у каталозі матеріалів.
До українського чату →