Стабильная версия · v1.0.0> windows / управление музыкальной коллекцией
Управление локальной музыкальной библиотекой относительно коллекции Яндекс Музыки: сопоставление, поиск отсутствующих треков, версии записей, метаданные, загрузки и контролируемая синхронизация.
MusicArk разделяет идентичность трека, версию записи и покрытие коллекции вместо того, чтобы считать совпадение названий достаточным. Flutter-интерфейс работает с Python-бэкендом, локальной SQLite-базой, кешем провайдера и явными границами для записи файлов и действий в Яндекс Музыке.
> контекст
MusicArk работает с разницей между музыкой, которую пользователь хочет хранить, и файлами, которые реально находятся на диске. Неопределённость показывается явно, а похожие метаданные сами по себе не считаются доказательством совпадения.
Разные релизы могут иметь почти одинаковые название и исполнителя, оригинальная и цензурированная версии — схожие метаданные, а устаревшее состояние провайдера способно породить ложные совпадения. Разрушительная синхронизация на такой базе была бы опасна.
MusicArk сначала строит кеш провайдера и индекс локальной библиотеки, затем выполняет консервативный Identity Matching, отдельно анализирует Variant, выводит Coverage из авторитетного состояния и только после этого предлагает загрузки, работу с метаданными, upload/recovery или Controlled Sync.
> возможности
v1.0.0 содержит полный desktop MVP для Windows x64 и не требует отдельной установки Python.
Вход по пользовательскому токену и cache-first просмотр любимых треков, плейлистов и альбомов.
Индексирование нескольких папок без изменения файлов при обычном Scan; технические поля и метаданные сохраняются в SQLite.
Консервативное сопоставление, где точность важнее полноты. Результат остаётся MATCHED, CONFLICT или UNMATCHED без принудительных догадок.
Анализ различий записи отдельно от идентичности и пользовательские метки ORIGINAL / CENSORED с ручной проверкой сомнительных случаев.
Состояния covered / missing / needs_review / not_analyzed выводятся из актуального Matching и пользовательского triage, без второго движка сопоставления.
Сохраняемая очередь с Wanted, retry, cancel, remove и массовыми действиями; долгоживущий worker не пересоздаёт provider client для каждого трека.
Явная запись MP3/ID3, обложки, переименование и сравнение с Яндекс Музыкой через временную копию, проверку и атомарную замену.
Неизменяемый план, проверка устаревания, подтверждение, повторная валидация перед Apply и постановка только актуальных загрузок.
Воспроизведение локальных и подготовленных треков, ручная загрузка собственных/разрешённых MP3 в Яндекс Музыку и recovery-сценарии.
> интерфейс
Актуальные скриншоты MusicArk из репозитория проекта. Изображения отображаются в исходных пропорциях и открываются в полном размере.
$ поток данных
Желаемая коллекция, реальные файлы, идентичность и признаки версии записи остаются разными сущностями. Coverage формируется только после анализа соответствий.
$ архитектура
Интерфейс и бэкенд разделены явными границами. Токены провайдера и защищённые media URL остаются на Python-стороне и не передаются во Flutter.
Постоянная оболочка приложения, Яндекс Музыка, Local Library, Matching/Coverage, Downloads, Sync, Metadata, Settings/Help/About и RU/EN интерфейс.
Интеграция с провайдером, локальный индекс, matching, variant analysis, coverage, downloads, metadata, sync planning, updates и feedback bridges.
Кеш коллекций Яндекс Музыки, индекс локальной библиотеки, matching state, variant results, coverage triage, downloads, settings и sync history.
Явные JSON/process boundaries соединяют Flutter с Python-сервисами. Бинарные обложки и credentials не проходят через metadata bridge.
Токен Яндекс Музыки хранится в системном хранилище через keyring; временные signed URLs и auth/cookie данные не сохраняются в task payload.
Flutter-приложение и замороженный Python runtime входят и в installer, и в portable; пользовательские данные отдельно хранятся в %LOCALAPPDATA%\MusicArk.
> инженерные решения
MusicArk предпочитает консервативные переходы состояния и явное подтверждение: ошибка управления коллекцией дороже, чем дополнительная ручная проверка сомнительного трека.
Ложный auto-match способен испортить последующие решения Coverage и Sync, поэтому сомнительные кандидаты остаются conflict или unmatched.
Missing появляется только для актуального авторитетного UNMATCHED. Stale, conflict и unanalyzed остаются отдельными состояниями.
Scan, Matching, Variant, Coverage и просмотр Sync-plan не меняют аудиофайлы. Изменение MP3 происходит только после действия пользователя в редакторе.
MusicArk не удаляет, не переименовывает, не перемещает и не перезаписывает существующие треки автоматически ради совпадения с Яндекс Музыкой.
Apply отказывается от устаревшего плана и повторно проверяет Coverage и очередь перед постановкой загрузок.
Ошибки внешних API или загрузок ограничиваются соответствующей функцией и не должны блокировать работу с кешем и локальной коллекцией.
> технологии
> безопасность
ЯВНЫЕ ГРАНИЦЫMusicArk консервативно работает с локальными файлами, credentials и обновлениями. Обычная аналитика read-only, секреты провайдера остаются вне Flutter, а запуск installer возможен только после проверки manifest, размера, SHA-256 и подтверждения пользователя.
$ стабильный_релиз
v1.0.0 — первый стабильный публичный релиз для Windows. Installer и portable включают Flutter-приложение и замороженный Python backend runtime; отдельно устанавливать Python не требуется.
A94F53F01BE23033405A6BAB2909436CC4CC1B1E99B19F57DD3A1307869BD3B8105E440C266B8EF3E9DDF2E40479FD4BEDF3ADF7253DD7A15D45127D51135D0E> ссылки проекта
GitHub остаётся источником истины для release notes, архитектуры, границ исходного кода, сторонних лицензий и задач.