История изменений

А ты добавь к своим идеям совместимость и интеграцию с осями, в том числе с мобильными

базу в sqlite хранить и ее синхронизировать простым копированием файла. сами приложения не сложнее любого существующего плеера где можно делать плейлисты и прикреплять рейтинги к песням.

в самой музыке надо много чего учесть, как быть в том случае, как быть в другом случае,

например?

а если удалить чего-нибудь откуда-нибудь

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

а как быть с бэкапами всей этой экосистемы

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

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

если начать это разрабатывать, то всплывет еще больше.

да, могут возникнуть проблемы с тем как единообразно хранить дискографии разных стилей выпусков (например релизы современной музыки альбомами и классической музыки где для одного произведения могут быть несколько исполнителей и т.п., а также разные версии одной песни и всякие там каверы) но это вопрос хорошего первичного дизайна схемы БД.

А ты добавь к своим идеям совместимость и интеграцию с осями, в том числе с мобильными

базу в sqlite хранить и ее синхронизировать простым копированием файла. сами приложения не сложнее любого существующего плеера где можно делать плейлисты и прикреплять рейтинги к песням.

в самой музыке надо много чего учесть, как быть в том случае, как быть в другом случае,

например?

а если удалить чего-нибудь откуда-нибудь

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

а как быть с бэкапами всей этой экосистемы

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

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

если начать это разрабатывать, то всплывет еще больше.

да, могут возникнуть проблемы с тем как единообразно хранить дискографии разных стилей выпусков (например релизы современной музыки альбомами и классической мызыки где для одного произведения могут быть несколько исполнителей и т.п., а также разные версии одной песни и всякие там каверы) но это вопрос хорошего первичного дизайна схемы БД.