Личный музыкальный архив без потери оригиналов

Это руководство выросло из простой бытовой задачи: я хотел слушать накопленные за годы редкие DJ-миксы, личные записи и обычную музыку так же удобно, как музыку из стриминга. Коллекция лежала в разных местах, а часть файлов имела неполные теги, повторяющиеся версии и повреждённые названия.

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

Начало этой истории описано в статье «Я хотел просто слушать редкие DJ-миксы, а построил личный музыкальный архив». Продолжение — в материале «Как один музыкальный архив превратился в домашнюю медиасистему». Отдельный пример переноса большого облачного архива есть в статье «Как мы перегоняем терабайт с Яндекс.Диска на Synology под присмотром Codex». Короткая версия результата собрана в кейсе «Как редкие DJ-миксы стали личным музыкальным архивом».

Ни MEGA, ни Synology, ни Navidrome не являются обязательными частями метода. На их месте могут быть Яндекс.Диск, Google Drive, Dropbox, папка с завершёнными торрент-загрузками, внешний диск, другой NAS, домашний сервер или обычный компьютер. Главный принцип остаётся прежним: источник сохраняется, все исправления выполняются в отдельной копии, а результат принимает человек в своём реальном сценарии прослушивания.

Какие музыкальные архивы подходят

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

• Облачные диски: MEGA, Яндекс.Диск, Google Drive, Dropbox и другие хранилища с возможностью выгрузки файлов.
• Завершённые торрент-загрузки: релизы, которые уже скачаны и продолжают раздаваться из исходной папки. Используйте только файлы, которыми вы вправе распоряжаться.
• Старые компьютеры, внешние диски, USB-накопители и предыдущие NAS.
• Покупки без DRM, оцифрованные диски, собственные записи, DJ-сеты и рабочие музыкальные материалы.
• Уже существующая медиатека Plex, Jellyfin, Apple Music или другого приложения, если исходные аудиофайлы доступны отдельно.

Если вы ещё выбираете сервер для собственной музыки, посмотрите сравнение «Своя музыка вместо стримингов: Plex и пять альтернатив для Synology». Метод из этого руководства работает до выбора конкретного плеера и не зависит от него.

Целевая архитектура архива

Чеклист быстрой проверки

• Все загружаемые источники и зафиксированный исходный архив доступны рабочему процессу только для чтения.
• Импорт использует одностороннее копирование и не переносит удаления или переименования обратно в источник.
• До обработки сохранён реестр (manifest): путь, размер, формат, длительность, техническое состояние, теги и контрольная сумма.
• Для каждого файла есть итоговая классификация: библиотека, карантин, HOLD, неподдерживаемый формат или уже присутствующая запись.
• Точные и вероятные дубликаты разделены; автоматического удаления нет.
• Метаданные восстанавливаются только в производных копиях и сопровождаются причиной изменения.
• Повреждённые и неоднозначные файлы исключаются из публикации, но сохраняются в источнике.
• Новая библиотека собирается рядом с активной и получает уникальную версию.
• Медиасервер видит только подготовленную версию; если платформа позволяет, библиотека подключена только для чтения.
• Для подключения новой версии сохранены предыдущая библиотека, конфигурация и данные каталога.
• Индексирование или полное сканирование завершено и подтверждено счётчиками, логами или интерфейсом выбранного сервера.
• Статус ACCEPTED ставится только после проверки в реальном клиенте владельца: например, Amperfy, Arpeggi, веб-плеере или другом приложении.

Загрузка из любого источника без обратного воздействия

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

Практика для разных облаков уже описана на сайте: для Яндекс.Диска — в статье о прямом переносе на Synology, для MEGA — в отдельном руководстве по MEGAcmd и надёжности Pro-аккаунта. В обоих случаях целевой архив должен быть отделён от механизма синхронизации.

1. Сначала получите полный список объектов источника без изменения файлов.
2. До скачивания проверьте конфликт пути и переносимые коллизии имён.
3. Скачивайте во временный файл, проверяйте размер и только затем выполняйте атомарное переименование.
4. Если файл назначения уже существует, сохраните его и зафиксируйте конфликт.
5. Гонки и неоднозначные совпадения отправляйте в карантин.

В нашем проходе с MEGA 200 новых объектов были добавлены в локальный исходный слой без изменения уже существующих файлов. Повторный запуск не скопировал ничего заново. Это хороший минимальный тест идемпотентности импортера, но сам метод не зависит от MEGA. Для торрент-папки тем же тестом будет неизменность раздаваемых файлов, для внешнего диска — совпадение количества, размеров и контрольных сумм после копирования.

Реестр и классификация до сборки

Папка и имя файла помогают ориентироваться, но не доказывают артиста, релиз или дубликат. Решение принимается по совокупности данных: контрольной сумме, техническому состоянию, тегам, длительности, версии записи и подтверждённому происхождению.

В одном из проходов реестр распределил 826 файлов в библиотеку «Музыка», 449 в «Моё», 285 оставил в HOLD, выделил 10 точных и 146 вероятных дубликатов. Источник при этом получил ноль записей.

Как разбирать дубликаты

• Одинаковая контрольная сумма доказывает одинаковые байты, но ещё не выбирает каноническое имя или расположение.
• Близкая длительность и одинаковое название создают вероятную пару, которую нужно прослушать.
• FLAC и MP3 одного релиза могут выполнять разные задачи. Решение о каноническом формате фиксируется явно.
• Повреждённый файл не превращается автоматически в задачу на перекодирование. Сначала сохраняются контрольная сумма исходника и ошибка декодера.

Практический пример: пять пересекающихся релизов были оставлены в FLAC, их MP3-альтернативы ушли в карантин, а релизы только в MP3 сохранились в библиотеке. Один повреждённый трек остался в HOLD и не попал в Navidrome.

Восстановление метаданных только в производных копиях

Большинство музыкальных серверов и плееров строят каталог прежде всего по тегам, а не по названиям папок. В Navidrome это особенно заметно. Минимально полезны название (`Title`), исполнитель (`Artist`), альбом (`Album`), исполнитель альбома (`Album Artist`) и номер трека (`Track Number`); для многодисковых релизов нужен номер диска (`Disc Number`). Исправления должны быть консервативными и воспроизводимыми.

1. Сохраните исходные теги и предполагаемые новые значения в реестре.
2. Автоматически применяйте только правила с точным условием: например, canonical mapping для конкретного исходного значения.
3. Контекст папки используйте как подсказку, а не как единственное доказательство.
4. Нечитаемую кодировку исправляйте только обратимым преобразованием с проверкой результата.
5. Нетегируемые файлы сохраняйте побайтно неизменными; обложку при необходимости размещайте рядом как отдельный файл (sidecar).

В проходе восстановления артистов число пустых `Artist` уменьшилось с 328 до 65, при этом существующие непустые значения не менялись. В отдельном проходе 34 строки с повреждённой кодировкой (mojibake) были исправлены, а 807 строк остались побайтно неизменными.

Версионная сборка перед подключением к плееру

Активную производную библиотеку не редактируют на месте. Новый кандидат собирается рядом, полностью проверяется и только затем подключается к выбранному серверу или плееру вместо предыдущей версии. Старый принятый каталог остаётся готовым к возврату.

Пример подключения к Navidrome

services:
  navidrome:
    image: deluan/navidrome:<PINNED_VERSION>
    user: "<UID>:<GID>"
    environment:
      ND_SCANNER_SCANONSTARTUP: "false"
    volumes:
      - /srv/navidrome/data:/data
      - /srv/music/candidates/listener-v8:/music:ro

Navidrome официально допускает музыкальную папку только для чтения. Каталог `/data` остаётся доступным на запись, потому что там находятся база и служебные данные. Для нескольких библиотек используйте отдельные корневые каталоги без пересечения.

Проверка каталога без ложного успеха

Любой каталогизатор должен доказать не только свою доступность, но и полноту индекса, корректность метаданных, поиск, обложки и воспроизведение. В Navidrome HTTP 200 от `/ping` подтверждает лишь доступность сервиса. Для новой полной библиотеки нужны явное полное сканирование и отдельная повторная проверка.

navidrome scan --full

# Для одной области в конфигурации с несколькими библиотеками:
navidrome scan --target <LIBRARY_ID>:<RELATIVE_FOLDER>

В контейнере команда может выглядеть как `/app/navidrome scan -f -c /data/navidrome.toml`. Засчитывайте результат, когда команда завершилась с кодом 0, лог содержит `fullScan=true` и `Finished full rescan`, база проходит `quick_check`, а активные счётчики совпадают с реестром.

Один реальный запуск пришлось откатить: сканирование при запуске началось одновременно с целевым сканированием, счётчики стали устаревшими, база закрылась. После восстановления предыдущего состояния публикация была повторена с временным `ND_SCANNER_SCANONSTARTUP=false`.

Переход PUBLISHED → ACCEPTED

Для приёмки откройте библиотеку в том приложении, которым действительно пользуется владелец: это может быть web-интерфейс, мобильный клиент, настольный плеер, Amperfy или Arpeggi. Затем пройдите один и тот же заранее зафиксированный набор проверок:

1. Найдите новый репрезентативный релиз и один старый контрольный трек.
2. Проверьте библиотеку, исполнителя, альбом, название и обложку.
3. Запустите воспроизведение минимум на 10 секунд и перемотайте трек.
4. Повторите воспроизведение через используемый удалённый маршрут.
5. Убедитесь, что HOLD-файл отсутствует, а старый контрольный трек по-прежнему работает.

В нашей конфигурации Navidrome проверялся через Amperfy и Arpeggi. Amperfy работает с Subsonic-сервером и поддерживает автономный режим, CarPlay и воспроизведение без пауз между треками. Arpeggi указан в каталоге клиентов Navidrome как OpenSubsonic-клиент для iOS и iPadOS; на дату проверки 24 августа 2026 года он распространяется через TestFlight. Выбор клиента не меняет правило: финальная приёмка принадлежит владельцу библиотеки.

В одном проходе серверная публикация осталась PUBLISHED_PENDING_QA, потому что проверки в Amperfy не было. В другом Сергей обновил библиотеку, подтвердил воспроизведение в приложениях, и состояние перешло PUBLISHED → ACCEPTED. Отдельное исправление метаданных стало ACCEPTED только после проверки примеров в Arpeggi.

Эталонный шаблон доказательств

job:
  source_snapshot: <manifest-sha256>
  source_writes: 0
  candidate: listener-v8
  dispositions:
    library: <count>
    quarantine_duplicate: <count>
    hold_source_damage: <count>
  verification:
    selected_pass: <count>
    selected_fail: 0
    source_or_mount_read_only: true
    full_index: true
    catalog_check: ok
  publication:
    state: PUBLISHED_PENDING_QA
    rollback_bundle: <path>
  consumer_qa:
    client: <actual-owner-client>
    checks: [refresh, find, metadata, cover, play, seek, remote-route, hold-absent]
    owner_confirmed: false

Как откатывать публикацию

1. Остановите текущий медиасервер, каталогизатор или публикационный процесс.
2. Верните предыдущую конфигурацию или подключение на сохранённый принятый каталог.
3. При необходимости восстановите базу каталога только на остановленном сервисе. Для Navidrome это его база и служебные данные из `/data`.
4. Запустите контролируемое сканирование и повторите короткую серверную проверку.
5. Проверьте старый контрольный трек в клиенте.

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

Типичные ошибки

• Использовать двусторонний sync для источника, который должен оставаться неизменяемым.
• Менять теги и имена прямо в исходном слое или активной библиотеке.
• Считать папку, basename или один размер доказательством артиста и дубликата.
• Автоматически перекодировать повреждённый файл и объявлять его восстановленным.
• Запускать два конкурирующих процесса индексации. Для Navidrome типичный пример — сканирование при старте одновременно с ручным полным сканированием.
• Удалять старую производную библиотеку сразу после серверной публикации.
• Считать `container healthy`, код завершения 0 или `/ping` 200 пользовательской приёмкой.

Официальные источники

• MEGAcmd: User Guide
• Navidrome: Installing with Docker
• Navidrome: Tagging Guidelines
• Navidrome: Command-Line Interface
• Navidrome: Multi-Library Support
• Amperfy: официальный репозиторий
• Navidrome: приложения-клиенты, включая Arpeggi

Следующий шаг

Navidrome на Synology: домашняя музыкальная медиатека с Amperfy

Связанные материалы

Статья: Как один музыкальный архив превратился в домашнюю медиасистему

Блог: Что делать с Synology после настройки: фото, музыка и архив

База знаний: MEGA: полное руководство по надёжности, MEGAcmd и сценариям для Pro-аккаунта

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov